OpenVPN Client Question

Here is route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface | | | UG | 0 0 0 | enp2s0 | | | UG | 0 0 0 | tun0 | | | UH | 0 0 0 | tun0 | | | U | 0 0 0 | enp2s0 | | | U | 1002 0 0 | enp2s0 | | | U | 1003 0 0 | enp0s20u4 | | | UG | 0 0 0 | tun0 | | | U | 0 0 0 | enp0s20u4

I did a tcpdump with the ICMP option to show echo requests and here is the result.

14:54:41.491814 IP > ICMP echo request, id 1, seq 16454, length 40

It does that 4 times (from the cmd line on a Windows computer) with no reply.

Currently my setup is:

internet (Public WAN IP) → red interface → NS → green interface → → - Home computer.

Honestly I don’t have any further ideas…probably something is missing somewhere but I can’t reproduce right now.

Any one has any idea?

In the OpenVPN logs, is this correct? Should it be routing the gateway through the wan gateway? Or the tun0 gateway (

Does anyone use their NethServer as a VPN client?

Hi, i think that everything with vpn is ok. what happens when You ping from Home computer >remote vpn ? What reply form NS? Routes looks fine but with this routing table NS is using local conection to the internet not the remote vpn internet connection.
So answer to:

Should it be routing the gateway through the wan gateway?

yes if You want

Also, are You sure shorewall is not blocking the traffic?
I have also problem with shorewall blocking traffic even from NS or green to established vpn connection and no solution till now, no solution (maybe i’m missing something/ misconfigure shorewall, dontn’t know).

Home computer ( -> remote vpn (, no response.
Home computer -> NS vpn ip address ( responds perfectly
NS (via SSH) -> remote vpn responds perfectly

So either shorewall is blocking access to the vpn from the green interface, or the routes are not working. But I don’t know enough about configuring shorewall or routes to know where the issue is. :frowning:

Check firewall.log then You have answer for at least one question, 2 ways to achive this:
send desired ping and check:
-GUI log viever firewall.log
-watch "tail /var/log/firewall.log"
from console one NS

I was actually able to figure it out. It’s not the firewall, it’s iptables. It’s not routing green packets to the vpn interface. I did some research online and found what looks like an answer.

I ran these iptables commands in an SSH session and am now able to ping the remote network from computers on my LAN.

iptables -A FORWARD -i enp0s20u4 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o enp0s20u4 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE <– edit: this is all I needed to run

Where enp0s20u4 is my green interface and tun0 is my openvpn tunnel.

And now it works! I haven’t tested it to see if it persists through reboots yet, but this is a big improvement from where I was.

Shouldn’t NS should be adding these routes to iptables when the vpn client is setup though?

1 Like

So, it’s not persistent through a reboot, but I figured out that all I needed to do was run this command:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

And then all is good. I just need to figure out how to make it persist through reboots now.

There were no Shorewall:forward reject/drop in log?
ok if only nat rule is needed, I assume were no drops in log

As I wrote in my post Shorewall is blocking ping but accept rule is created, why?

i (also) have similar problem but with OUTPUT:REJECT: and don’t know if this possible to accept this in GUI (to have rules in one place) because from bash this should work.
I thought I it should work from GUI but it’s not - something is missing in Gui rule creation (just like here) or I’m making something wrong.

I went back and removed the static routes, and all firewall rules to see if the firewall would otherwise be blocking the packets. I then rebooted my NS and ran the iptables command, and it still works!

So it looks like NS needs to add this iptables command when setting up an OpenVPN client.

Hey @giacomo, I was able to fix it with this iptables command:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Is this something that should be added to NS when creating OpenVPN clients?

The only other issue I have is active FTP. :sweat_smile:

Active FTP is required for a medical program I use and doesn’t work through the VPN.

Luckily I found the issue was with the way my IP address appeared to the FTP server and enabling nf_nat_ftp seems to fix the issue. So in case anyone else is having a hard time with active ftp through an OpenVPN client, go into an SSH session and run this command to load the NAT ftp module:

modprobe nf_nat_ftp

You can then create a [filename].conf file (i.e. natftp.conf) in /etc/modules-load.d/ that simply states nf_nat_ftp so that the module gets loaded at startup.

Again, this is just in case anyone has an issue with active FTP downloads through a VPN tunnel. In general you should always use passive FTP (or avoid FTP all together if possible), but sometimes you can’t get around it like in my case with a proprietary program I use for work.

Otherwise, this post can be marked solved!!


Really good job Keith.

I never had to add the masquerade to the tun0.
If you want to make the modification permanent do this:

mkdir -p /etc/e-smith/templates/custom/etc/shorewall/masq
echo tun0 >>  /etc/e-smith/templates/custom/etc/shorewall/masq/90tun
signal-event firewall-adjust

Hiding LAN IP addresses through a VPN is usually not desired, because you loose the source of access to resources.
But if @Keith_Haines sceanario is a common one we could file an issue for an improvement.


I tried following your instructions, but it doesn’t persist through reboots.

Is there another way to make the iptables command persist through reboots?

I think that really should have been:

mkdir -p /etc/e-smith/templates-custom/etc/shorewall/masq
echo tun0 >>  /etc/e-smith/templates-custom/etc/shorewall/masq/90tun
signal-event firewall-adjust



That makes a lot more sense, I just tried it and it works great! Thanks!

I just wanted to add that using the custom templates didn’t actually work. I ended up adding the iptables command to the /etc/shorewall/started file to get it to persist through reboots.