NethServer Version: 7.9.2009
Module: OpenVPN
Good morning, I would like help with the following, I have two Nethserver connected Site to Site by OpenVPN, and I need that the users who connect by OpenVPN RoadWarrior to the main server, can also navigate in the network of the other Nethserver, I thought it was just activating as the image shows.
But I see that it does not work, any other recommendation?
Thanks a lot.
Hi @jfhoyosm
I think you may need to rethink this whole concept…
It MAY work as networking…
But VoIP?
VoIP uses mainly UDP for the actual voice transfer - and not just a single port. It uses often a whole range of UDP Ports, eg like 10000-20000 (A common one…).
Not only that (UDP is not “controlled” like TCP, packets can be discarded), but all this reduces voice quality, down to a level where the quality is too low to understand (garbling).
NethServer doesn’t really have the needed options in the firewall GUI to handle VoIP to the Internet and also for VoIP over VPN. It would take quite a bit of custom templates / rules etc. to get this working well.
I can’t really help you with this, as I use OPNsense as my firewalls. I get it working there, but even then, it’s tricky if you don’t have the right infos / look up materials / whatever.
IPsec seems more stable for this kind of site2site VPN than OpenVPN, but not always possible.
Good luck!
My 2 cents
Andy
Andy, good morning, thank you very much for your recommendation, for now what I did was remove the VPN Site to Site with OPenVPN and leave it with IPSEC, and although it did not exactly solve this problem, it solved another question that I had already raised, thank you very much.
Did you try to ping the second server by IP from you VPN-Clients? It could be that it is an DNS-problem and your “Nethserver 1” can’t solve the DNS entries of “Nethserver 2”.
There is normal communication between the two, what’s more, being in either of the two sites, the connections between the two networks work normally, the problem is that when someone from home connects to one of the networks through OpenVPN Roadwarrior, they only have access to the network that connected, but not to the other network.
I think I’m going to try connecting clients via IPSec as well.
I understand, I tried to find out if it is a routing problem or a DNS problem. So if someone who connects from home can’t ping the server by IP he isn’t connected to, it is a routing problem, else it is a DNS problem.
It does not send a PIN, from my client through OpenVPN RoadWarrior to that second server, I tried changing the OpenVPN configuration from router to bridge, so that they had the same segment, but I get the following error in the client’s OpenVPN:
Tue Jan 25 04:25:23 2022 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Tue Jan 25 04:25:23 2022 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jan 25 04:25:23 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Enter Management Password:
Tue Jan 25 04:25:23 2022 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25345
Tue Jan 25 04:25:23 2022 Need hold release from management interface, waiting...
Tue Jan 25 04:25:23 2022 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25345
Tue Jan 25 04:25:23 2022 MANAGEMENT: CMD 'state on'
Tue Jan 25 04:25:23 2022 MANAGEMENT: CMD 'log all on'
Tue Jan 25 04:25:24 2022 MANAGEMENT: CMD 'echo all on'
Tue Jan 25 04:25:24 2022 MANAGEMENT: CMD 'bytecount 5'
Tue Jan 25 04:25:24 2022 MANAGEMENT: CMD 'hold off'
Tue Jan 25 04:25:24 2022 MANAGEMENT: CMD 'hold release'
Tue Jan 25 04:25:24 2022 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue Jan 25 04:25:24 2022 MANAGEMENT: >STATE:1643102724,RESOLVE,,,,,,
Tue Jan 25 04:25:24 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]"MYIPPUBLIC":1194
Tue Jan 25 04:25:24 2022 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Jan 25 04:25:24 2022 UDP link local: (not bound)
Tue Jan 25 04:25:24 2022 UDP link remote: [AF_INET]"MYIPPUBLIC":1194
Tue Jan 25 04:25:24 2022 MANAGEMENT: >STATE:1643102724,WAIT,,,,,,
Tue Jan 25 04:25:24 2022 MANAGEMENT: >STATE:1643102724,AUTH,,,,,,
Tue Jan 25 04:25:24 2022 TLS: Initial packet from [AF_INET]"MYIPPUBLIC":1194, sid=e97b7d92 901ea519
Tue Jan 25 04:25:24 2022 VERIFY OK: depth=0, CN=NethServer, O=Example Org, ST=SomeState, OU=Main, emailAddress=root@nethserver.masterkey-sa.com, C=--, L=Hometown
Tue Jan 25 04:25:24 2022 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
Tue Jan 25 04:25:24 2022 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1573'
Tue Jan 25 04:25:24 2022 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Tue Jan 25 04:25:24 2022 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Jan 25 04:25:24 2022 [NethServer] Peer Connection Initiated with [AF_INET]"MYIPPUBLIC":1194
Tue Jan 25 04:25:25 2022 MANAGEMENT: >STATE:1643102725,GET_CONFIG,,,,,,
Tue Jan 25 04:25:25 2022 SENT CONTROL [NethServer]: 'PUSH_REQUEST' (status=1)
Tue Jan 25 04:25:25 2022 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DOMAIN masterkey-sa.com,dhcp-option DNS 10.0.16.1,dhcp-option WINS 10.0.16.1,dhcp-option NBDD 10.0.16.1,dhcp-option NBT 2,route-gateway 10.0.16.1,ping 20,ping-restart 120,ifconfig 10.0.16.200 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: route-related options modified
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: peer-id set
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: adjusting link_mtu to 1624
Tue Jan 25 04:25:25 2022 OPTIONS IMPORT: data channel crypto options modified
Tue Jan 25 04:25:25 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Jan 25 04:25:25 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jan 25 04:25:25 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Jan 25 04:25:25 2022 WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Tue Jan 25 04:25:25 2022 MANAGEMENT: Client disconnected
Tue Jan 25 04:25:25 2022 There is a problem in your selection of --ifconfig endpoints [local=10.0.16.200, remote=255.255.255.0]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' option for more info.
Tue Jan 25 04:25:25 2022 Exiting due to fatal errorI think the following lines are interesting:
Jan 25 04:25:24 2022 WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
Tue Jan 25 04:25:24 2022 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1573'
Tue Jan 25 04:25:24 2022 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
```
Tue Jan 25 04:25:25 2022 There is a problem in your selection of --ifconfig endpoints [local=10.0.16.200, remote=255.255.255.0]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' option for more info.Can you post your network and VPN configuration please?
I solved it by changing the configuration in the two OpenVPN.
And adding in the IPSec the two network segments of the OpenVPN
The configuration applies to both servers.
Thanks for you help.