Cant Access an IP Behind a VPN When I remote Into Home LAN (Policy Rules Strict)

[endtimes]

Hello everyone!

Here is my environment.

• AsusWRT-Merlin FW 380.67 on Asus RT-AC88U
  
• OpenVPN Client setup on my router using AirVPN
  
• OpenVPN Server enabled on my router with 10.8.0.0/24
• Internal home LAN with 192.168.x.x/24
• I have a FreeNAS server running multiple jails
  • 192.168.1.26 = Transmission going through the OpenVPN client out to the internet

I'm having issues accessing only the Transmission jail at 192.168.1.26 on my home internal LAN when I VPN in. Transmission in my Freenas server is going through the a VPN configured on OpenVPN Clients page. As Jack Yaz kindly pointed out, this is happening because under the 'OpenVPN Clients' tab in the router page, under 'Redirect Internet Traffic' option, I'm using 'Policy Rules Strict' setting. When I change it to just 'Policy Rules', I can ping and reach the Transmission server. Using the strict option increases security but requires a rule to be used that specifically targets the tunnel's interface to allow traffic to be forwarded. Please help em write this rule. Here is Merlin's explanation from his changelog for 380.66 (12-May-2017),

NEW: Added new Internet redirection mode to OpenVPN clients
called "Policy Rule (Strict)". The difference from the
existing "Policy Rule" mode is that in strict mode,
only rules that specifically target the tunnel's
interface will be used. This ensures that you don't
leak traffic through global or other tunnel routes,
however it also means any static route you might have
defined at the WAN level will not be copied either.​

This brings me to iptables. Here is my nat-start script. My goal is to have a semi simple script with some security while allowing me to access the Trasmission IP. You'll see from my script that I tried different lines and when they didn't work, I just commented them out.
#!/bin/sh

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
#iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
#iptables -t nat -A POSTROUTING -o tun21 -j MASQUERADE

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxxx-j DNAT --to-destination 192.168.1.26
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxxx-j DNAT --to-destination 192.168.1.26
iptables -I FORWARD -i tun11 -p udp -d 192.168.1.26 --dport xxxxx--state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.26 --dport xxxxx--state RELATED,ESTABLISHED -j ACCEPT

Any help is very much appreciated.

 

[endtimes]

Could this be a simple route issue where I need to add a static route? I'm really stumped on this.

 

[Jack Yaz]

+1, I also started a thread but no responses. I was going to start comparing what routing tables router/client and firewalls have between the two options, to see if I could spot where I can manually add something, if this is even indeed the right avenue!

 

[endtimes]

+1, I also started a thread but no responses. I was going to start comparing what routing tables router/client and firewalls have between the two options, to see if I could spot where I can manually add something, if this is even indeed the right avenue!

It has to be either a static route or iptables rule. I'll try to do the same on y end today. Let's see if we can both get somewhere with this and hopefully someone else here will be able to chime in as well.

 

[endtimes]

Well I was able to get some clarity on this straight from the source RMerlin, "(Policy Rules Strict) change is done at a lower level than iptables - right at the kernel's routing table level, so working around it might be complicated".

With this in mind, unless someone really experienced with this tries to figure a way to add a route, accessing devices using strict mode will be a problem.