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?
is:
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 (192.168.20.0/24) -> remote vpn (192.168.0.0/24), no response.
Home computer -> NS vpn ip address (10.8.0.6) 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.
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
or
-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?
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.
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.
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 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.
