NS based VPN net2net and RoadWarrior connection problems

NethServer Version: 7.4.1708
Module: OpenVPN

Dear NS Community,

First of all english is not my native language.
As I have mentioned earlier in the “So, What are you working on?” welcome thread I’m building a NS based VPN solution that will allow me to connect to my office.
The main reason is that my office’s router is hidden behind T-Mobile NAT so there’s no possibility to use Openvpn + DynDNS.
I’d decided to buy a VPS server to act as the central ‚meeting’ point.
The VPS is equipped with a single NIC (DHCP) which turned out to be problematic.

So far I have done the following:

  1. Installed a NS in my office on a small dell PC (running 24/7) equipped with single NIC (not a default GW for the office network).

  2. Installed the NS on VPS, configured it as an OpenVPN net2net Master (tunnel IP 10.235.160.0/24) + OpenVPN host2net (tunnel IP 10.10.10.0/24).

  3. Configured OpenVPN net2net Client on Dell but with no success (no connection between both servers).

  4. I figured out that most probably 1 NIC in the VPS server is the reason for the net2net tunnel not working. So I added a virtual interface as a VLAN on ETH0. Then I set the ‚new’ interface as Green and then switched the main ETH0 to Red. This fixed the tunnel and now it’s up and running.

  5. Configured the VPS OpenVPN for Road Warriors (tunnel IP 10.10.10.0/24) and installed a client on my notebook. I can connect to VPS through the OpenVPN but cannot reach my office nor it’s tunnel IP adresses.

I thought adding some additional routings would help but it didn’t.
What am I missing or what have I done wrong?

I didn’t touch the firewall settings yet.

I have attached a picture made in Dia that should explain my situation.

Please note that all IP addresses are for reference and therefore different from real ones. I assumed that it would be easier to talk using specific addresses.

Any help appreciated.

Regards,
Robert

Hi Robert
Try to add in VPS trusted network our missing client network. try with ping and check /var/log/firewall.log.
first check firewall and second check route. I think that with this type of configuration some additional route is necessary on both sides.

1 Like

Look for “sfilter” in /var/log/firewall.log.
If you find lines containing sfilter and ovpn you are probably hitting a limit on nethserver openvpn tunnels configuration.
The workaround is to use ipsec to build the tunnel between the office and the vps.

I’d like to work to remove this openvpn limit, but I think it will not be easy.
Please, try the ipsec workaround.

Hi Guys,

I was on a business trip so I couldn’t try your suggestions and reply.

I did try to look for the “sfilter” and found only this two entries in the :
Mar 11 10:34:33 vpsxxxx sudo: srvmgr : TTY=unknown ; PWD=/usr/share/nethesis/nethserver-manager ; USER=root ; COMMAND=/sbin/e-smith/logviewer -q sfilter
Mar 11 10:34:38 vpsxxxx sudo: srvmgr : TTY=unknown ; PWD=/usr/share/nethesis/nethserver-manager ; USER=root ; COMMAND=/sbin/e-smith/logviewer -p sfilter
/var/log/secure

I have no idea what that means.

Hi sharpec

The VPN IP address is automatically added to the trusted networks but only for the RoadWarriors.
There’s no IP of the net2net VPN.

But I cannot add my notebook’s real address because I cannot predict it - because this changes depending on the place I will be establishing the VPN tunnel from.

I was not talking about the public ip, but about the ip assigned to you in the vpn, roadwarrior or tunnel

Hi,

Were you talking about these addresses?:

If yes, then the second one seems to be added automatically but the first one responsible for net2net is not there.

Yes, I’m talking about that network, net2net.

take a test.

I had to add them otherwise the central firewall did not pass services

Mar 14 10:30:37 fw kernel: Shorewall:sfilter1:DROP:IN=tunrw OUT=tuncfw-bck MAC= SRC=192.168.188.6 DST=192.168.1.5 LEN=78 TOS=0x00 PREC=0x00 TTL=127 ID=10840 PROTO=UDP SPT=137 DPT=137 LEN=58 
Mar 14 10:30:37 fw kernel: Shorewall:sfilter1:DROP:IN=tunrw OUT=tuncfw-bck MAC= SRC=192.168.188.6 DST=192.168.1.254 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=13136 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=284

@filippo_carletti you are always right

Can this be relevant?