unable to reach specific LAN device when connected to OpenVPN Server

[GSpock]

Hi Folks,
I am having the following issue:
- while remotely connected to my OpenVPN Server 1, I cannot access one of my LAN device (192.168.1.30) if this device is defined as block in the time scheduling system (basically I do not want that device to access internet at all but of course want to be able to access it from LAN and/or when remotely connected to OpenVPN Server 1) .... hopefully when on the LAN there is no issue

Can this set-up work at all then ?

Thx,
GS

 

[Martineau]

Hi Folks,
I am having the following issue:
- while remotely connected to my OpenVPN Server 1, I cannot access one of my LAN device (192.168.1.30) if this device is defined as block in the time scheduling system (basically I do not want that device to access internet at all but of course want to be able to access it from LAN and/or when remotely connected to OpenVPN Server 1) .... hopefully when on the LAN there is no issue

Can this set-up work at all then ?

Thx,
GS

IIRC, you will need to pre-empt the DROP rule (created by the DENY Internet time scheduler) by inserting an ACCEPT rule to allow the device to use either of the VPN Server interfaces:

POS=$(iptables --line -t filter -nvL FORWARD |  grep -E "DROP.*br0.*xxx.xxx.xxx.xxx" | awk '{print $1}')
[ -n "$POS" ] && iptables -I FORWARD $POS -s xxx.xxx.xxx.xxx -o tun2+ -j ACCEPT

NOTE: Not sure if you also need an override rule in the 'nat PREROUTING/PCREDIRECT' chains.

 

[eibgrad]

You could also probably just NAT the inbound traffic from the tunnel before it's dropped on the private network (br0) so it appears to be coming from the router on the LAN side, thus it's treated as a bridged connection and NOT affected by the firewall.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

Of course, you need to change "10.8.0.0/24" to match your specific IP network on the tunnel.

A lot of ppl do this w/ the OpenVPN server because it solves the more general problem of having the tunnel's IP network exposed directly to the private network, resulting in problems such as yours. For example, the Windows firewall typically won't allow clients from any other private network than the one on which it's running. So an OpenVPN client of say 10.8.0.2 would be denied access to 192.168.1.100. But because that client has now been NAT'd w/ the router's LAN ip (192.168.1.1), Windows accepts it. If you don't NAT, then you have to run around to every Windows machine and change the firewall (not fun, esp. in an office setting).

IOW, NAT'ing the inbound traffic from the OpenVPN client solves a variety of problems without having to handle each on a case by case basis. On the downside, you obviously can't filter access by OpenVPN client(s) based on their assigned IP on the tunnel. But for a lot of ppl, they don't ever filter their OpenVPN client(s) anyway. So it's just easier to NAT and be done w/ it.

 

[GSpock]

IIRC, you will need to pre-empt the DROP rule (created by the DENY Internet time scheduler) by inserting an ACCEPT rule to allow the device to use either of the VPN Server interfaces:

POS=$(iptables --line -t filter -nvL FORWARD |  grep -E "DROP.*br0.*xxx.xxx.xxx.xxx" | awk '{print $1}')
[ -n "$POS" ] && iptables -I FORWARD $POS -s xxx.xxx.xxx.xxx -o tun2+ -j ACCEPT

NOTE: Not sure if you also need an override rule in the 'nat PREROUTING/PCREDIRECT' chains.

Thanks for your quick reply. I am now trying to understand what it does .... the first set of xxx refers to the MAC address of the device that is blocked and the second set is it's ip address, correct ? while $POS gives the position of the rule in the iptables ; what I am missing is on the tun2+ part, currently I am using server1 so I guess it is tun21 ?

GS

 

[GSpock]

You could also probably just NAT the inbound traffic from the tunnel before it's dropped on the private network (br0) so it appears to be coming from the router on the LAN side, thus it's treated as a bridged connection and NOT affected by the firewall.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

Of course, you need to change "10.8.0.0/24" to match your specific IP network on the tunnel.

A lot of ppl do this w/ the OpenVPN server because it solves the more general problem of having the tunnel's IP network exposed directly to the private network, resulting in problems such as yours. For example, the Windows firewall typically won't allow clients from any other private network than the one on which it's running. So an OpenVPN client of say 10.8.0.2 would be denied access to 192.168.1.100. But because that client has now been NAT'd w/ the router's LAN ip (192.168.1.1), Windows accepts it. If you don't NAT, then you have to run around to every Windows machine and change the firewall (not fun, esp. in an office setting).

IOW, NAT'ing the inbound traffic from the OpenVPN client solves a variety of problems without having to handle each on a case by case basis. On the downside, you obviously can't filter access by OpenVPN client(s) based on their assigned IP on the tunnel. But for a lot of ppl, they don't ever filter their OpenVPN client(s) anyway. So it's just easier to NAT and be done w/ it.

Thanks for your answer ; I think I need quite some time to understand all of this ; sorry my skills are not that high and I learn slowly ...

 

[GSpock]

NOTE: Not sure if you also need an override rule in the 'nat PREROUTING/PCREDIRECT' chains.

... I guess this is needed, the other statement works OK (it inserts an accept rule) but I can't still reach the device .... I will try to guess how to code that .... thx

 

[GSpock]

... I guess this is needed, the other statement works OK (it inserts an accept rule) but I can't still reach the device .... I will try to guess how to code that .... thx

I tried this but still does not work : iptables -I FORWARD -s 192.168.1.3 -o tun2+ -j ACCEPT

 

[GSpock]

You could also probably just NAT the inbound traffic from the tunnel before it's dropped on the private network (br0) so it appears to be coming from the router on the LAN side, thus it's treated as a bridged connection and NOT affected by the firewall.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

Of course, you need to change "10.8.0.0/24" to match your specific IP network on the tunnel.

A lot of ppl do this w/ the OpenVPN server because it solves the more general problem of having the tunnel's IP network exposed directly to the private network, resulting in problems such as yours. For example, the Windows firewall typically won't allow clients from any other private network than the one on which it's running. So an OpenVPN client of say 10.8.0.2 would be denied access to 192.168.1.100. But because that client has now been NAT'd w/ the router's LAN ip (192.168.1.1), Windows accepts it. If you don't NAT, then you have to run around to every Windows machine and change the firewall (not fun, esp. in an office setting).

IOW, NAT'ing the inbound traffic from the OpenVPN client solves a variety of problems without having to handle each on a case by case basis. On the downside, you obviously can't filter access by OpenVPN client(s) based on their assigned IP on the tunnel. But for a lot of ppl, they don't ever filter their OpenVPN client(s) anyway. So it's just easier to NAT and be done w/ it.

... thanks, in my specific case, this does not work ... can't access the device :-(

 

[Martineau]

Thanks for your quick reply. I am not trying to understand what it does .... the first set of xxx refers to the MAC address of the device that is blocked and the second set is it's ip address, correct ?

Usually I use xx:xx:xx:xx:xx:xx to represent a MAC address and xxx.xxx.xxx.xxx to represent an IPv4 address (although nnn.nnn.nnn.nnn would probably be better to convey that only digits are allowed in an IPv4 address)

So both commands refer to IPv4 addresses only.

what I am missing is on the tun2+ part

tun2+ is shorthand to describe both OpenVPN Server interfaces i.e. either tun21 or tun22

currently I am using server1 so I guess it is tun21 ?

Yes

 

[Martineau]

I tried this but still does not work : iptables -I FORWARD -s 192.168.1.3 -o tun2+ -j ACCEPT

To try and identify all of the necessary rules can you try the following

iptables -I FORWARD -s 192.168.1.3 -i br0 -j ACCEPT
iptables -I FORWARD -s 192.168.1.3 -i br0 ! -o tun2+ -j DROP

See if you can access 192.168.1.3 from the inbound OpenVPN client then can you please dump the iptables to see if there are any hits

iptables --line -t filter -nvL FORWARD

 

[GSpock]

So both commands refer to IPv4 addresses only.


Yes

the command iptables --line -t filter -nvL FORWARD | grep -E "DROP.*br0.*192.168.1.3" returns no result,
while

iptables --line -t filter -nvL FORWARD | grep -E "DROP.*br0.*3C:nn:nn:nn:nn:6C"
gives

9 9445 453K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:nn:nn:nn:nn:6C
what am I missing then ?

 

[Martineau]

the command iptables --line -t filter -nvL FORWARD | grep -E "DROP.*br0.*192.168.1.3" returns no result,
while

iptables --line -t filter -nvL FORWARD | grep -E "DROP.*br0.*3C:nn:nn:nn:nn:6C"
gives

9 9445 453K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:nn:nn:nn:nn:6C
what am I missing then ?

Surely your signature firmware v384.13_10 isn't really current?

Anyway, assuming LAN device 192.168.1.3 does match 3C:xx:xx:xx:xx:6C can you insert the following rule

iptables -I FORWARD -d 192.168.1.3 -i tun2+ -o br0 -j ACCEPT

and see if there are any hits when you attempt to access the blocked device from the inbound OpenVPN server client.

 

[GSpock]

Surely your signature firmware v384.13_10 isn't really current?

Yes, it is ... RT-AC87U running 384.13_10 .... which I believe is the last version for 87U ?

why do you think not ?

here below the output of iptables --line -t filter -nvL FORWARD after trying to access the device via openvpn client .... (device still not reachable) ..

num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all -- tun2+ br0 0.0.0.0/0 192.168.1.3
2 0 0 ACCEPT udp -- tun12 * 0.0.0.0/0 192.168.1.186 udp dpt:xxx
3 6 303 ACCEPT tcp -- tun12 * 0.0.0.0/0 192.168.1.186 tcp dpt:xxxx
4 0 0 ACCEPT udp -- tun11 * 0.0.0.0/0 192.168.1.190 udp dpt:xxxx
5 2 84 ACCEPT tcp -- tun11 * 0.0.0.0/0 192.168.1.190 tcp dpt:xxxx
6 8013 481K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
7 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
8 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
9 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
10 0 0 ACCEPT all -- * tun2+ 192.168.1.3 0.0.0.0/0
11 18890 907K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:nn:nn:nn:nn:6C

Then I tried to ping it, it works, and get this:

1 79 6636 ACCEPT all -- tun2+ br0 0.0.0.0/0 192.168.1.3
2 0 0 ACCEPT udp -- tun12 * 0.0.0.0/0 192.168.1.186 udp dpt:
3 6 303 ACCEPT tcp -- tun12 * 0.0.0.0/0 192.168.1.186 tcp dpt:
4 0 0 ACCEPT udp -- tun11 * 0.0.0.0/0 192.168.1.190 udp dpt:
5 2 84 ACCEPT tcp -- tun11 * 0.0.0.0/0 192.168.1.190 tcp dpt:
6 8824 530K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
7 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
8 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
9 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
10 79 6636 ACCEPT all -- * tun2+ 192.168.1.3 0.0.0.0/0
11 22034 1058K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:xx:xx:xx:xx:6C

 

[Martineau]

Yes, it is ... RT-AC87U running 384.13_10 .... which I believe is the last version for 87U ?
View attachment 26829
why do you think not ?

here below the output of iptables --line -t filter -nvL FORWARD after trying to access the device via openvpn client .... (device still not reachable) .. but I can ping it !


num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all -- tun2+ br0 0.0.0.0/0 192.168.1.3
2 0 0 ACCEPT udp -- tun12 * 0.0.0.0/0 192.168.1.186 udp dpt:xxx
3 6 303 ACCEPT tcp -- tun12 * 0.0.0.0/0 192.168.1.186 tcp dpt:xxxx
4 0 0 ACCEPT udp -- tun11 * 0.0.0.0/0 192.168.1.190 udp dpt:xxxx
5 2 84 ACCEPT tcp -- tun11 * 0.0.0.0/0 192.168.1.190 tcp dpt:xxxx
6 8013 481K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
7 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
8 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
9 0 0 DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC nn:nn:nn:nn:nn:nn
10 0 0 ACCEPT all -- * tun2+ 192.168.1.3 0.0.0.0/0
11 18890 907K DROP all -- br0 * 0.0.0.0/0 0.0.0.0/0 MAC 3C:nn:nn:nn:nn:6C


If I got it well, there is no hit on rule 1 ....

Correct.

 

[GSpock]

@Martineau
Hi, I found that thread and applied the statement you mentioned:

Can't access LAN device from VPN when device set to block Internet access

I have a ASUS RT-AC68R with Asuswrt-Merlin on firmware 384.7_2 I have a IP cam I have blocked Internet access using the button on the Network Map page. I would like to VPN in from my phone using OpenVPN (which is set up and working) and use the IP cam app on my phone to access the IP cam. I'm...

www.snbforums.com

BUT it still does not make it ... and I really do not understand why .... frustrating !

 

[#TY]

You could also probably just NAT the inbound traffic from the tunnel before it's dropped on the private network (br0) so it appears to be coming from the router on the LAN side, thus it's treated as a bridged connection and NOT affected by the firewall.

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)

Of course, you need to change "10.8.0.0/24" to match your specific IP network on the tunnel.

A lot of ppl do this w/ the OpenVPN server because it solves the more general problem of having the tunnel's IP network exposed directly to the private network, resulting in problems such as yours. For example, the Windows firewall typically won't allow clients from any other private network than the one on which it's running. So an OpenVPN client of say 10.8.0.2 would be denied access to 192.168.1.100. But because that client has now been NAT'd w/ the router's LAN ip (192.168.1.1), Windows accepts it. If you don't NAT, then you have to run around to every Windows machine and change the firewall (not fun, esp. in an office setting).

IOW, NAT'ing the inbound traffic from the OpenVPN client solves a variety of problems without having to handle each on a case by case basis. On the downside, you obviously can't filter access by OpenVPN client(s) based on their assigned IP on the tunnel. But for a lot of ppl, they don't ever filter their OpenVPN client(s) anyway. So it's just easier to NAT and be done w/ it.

Can you provide a step by step way to do this please? I think that's what Im looking for. Is this something doable from the web UI? Thank you.

 

[eibgrad]

Can you provide a step by step way to do this please? I think that's what Im looking for. Is this something doable from the web UI? Thank you.

You need to have both JFFS and JFFS scripts enabled in Administration->System, then create a file in /jffs/scripts by the name of nat-start w/ that command. As a convenience, I've created a script that you can copy/paste into the window of an ssh terminal that will create the nat-start file for you. It will NOT overwrite any existing nat-start file (if found, you'll have to manually modify the existing nat-start file to include the command). It will require a reboot to take effect.

Note as well, I changed the hardcoded "10.8.0.0/24" to variables, that by default assume OpenVPN server #1. Change as necessary for your particular OpenVPN server instance.

#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/nat-start"

mkdir -p $SCRIPTS_DIR

function create_script(){
cat << "EOF" > $SCRIPT
#!/bin/sh
iptables -t nat -I POSTROUTING -s $(nvram get vpn_server1_sn)/$(nvram get vpn_server1_nm) \
    -o br0 -j SNAT --to $(nvram get lan_ipaddr)
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi

 

[#TY]

THANK YOU SO MUCH!!!

Just to be clear I properly understand you though.

1) I will go back and change the VPN subnet to 10.8.0.0 (the default).
2) I will enable both JFFS and JFFS scripts in Administration->System
3) I will open Terminal, SSH into the router and paste your script above as is.

Is this correct?

Also, will I see anything in the UI after doing this?

 

[eibgrad]

THANK YOU SO MUCH!!!

Just to be clear I properly understand you though.

1) I will go back and change the VPN subnet to 10.8.0.0 (the default).
2) I will enable both JFFS and JFFS scripts in Administration->System
3) I will open Terminal, SSH into the router and paste your script above as is.

Is this correct?

Also, will I see anything in the UI after doing this?

1,2 & 3, all correct. NO, nothing will confirm any of this in the GUI. After a reboot, you can confirm the presence of the firewall rule by dumping the POSTROUTING chain of nat table from an ssh session.

iptables -t nat -vnL POSTROUTING

 

[#TY]

1,2 & 3, all correct. NO, nothing will confirm any of this in the GUI. After a reboot, you can confirm the presence of the firewall rule by dumping the POSTROUTING chain of nat table from an ssh session.

iptables -t nat -vnL POSTROUTING

Done. This is what I see. Can you please confirm that it's all good.

ASUSWRT-Merlin RT-AX88U 384.19_0 Fri Aug 14 19:20:07 UTC 2020


master@RT-AX88U-5920:/tmp/home/root# iptables -t nat -vnL POSTROUTING


Chain POSTROUTING (policy ACCEPT 195 packets, 25659 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * br0 10.8.0.0/24 0.0.0.0/0 to:192.168.1.1
0 0 ACCEPT all -- * * 192.168.1.0/24 0.0.0.0/0 policy match dir out pol ipsec
403 28892 PUPNP all -- * ppp0 0.0.0.0/0 0.0.0.0/0
230 17105 MASQUERADE all -- * ppp0 !70.50.248.251 0.0.0.0/0
0 0 MASQUERADE all -- * eth0 !169.254.89.118 0.0.0.0/0
41 8890 MASQUERADE all -- * br0 192.168.1.0/24 192.168.1.0/24