Routing local subnets over OpenVPN client connection

[Seth]

Greetings,

I apologize if this has been asked and answered. I have an AC87U running the latest Merlin firmware which occupies 192.168.1.0/24, connected to this I have an Ubiquity Edge Router X I have been playing with and it has an IP of 192.168.1.55 which is used as a gateway to another subnet which houses all my IOT devices, 192.168.148.0/24. I have static routes entered to enable connections between the 1 and 148 subnets and that works fine.

The problem is I have an OpenVPN client connection active with selective routing and while I can route anything directly connected to the AC87U (192.168.1.0/24) over the VPN and that works fine, when I try to route all traffic from the IOT subnet nothing can connect to the internet. I would do this by adding an entry in the selective routing for the VPN client of 192.168.148.0/24. As soon as that entry is made the IOT subnet cannot connect to the internet at all.

I have tried routing just a single device on the IOT subnet, which does not work. I have also disabled all firewalls on the ERX for testing to make sure that wasn't an issue. I also see where the AC87U is adding the routes for all the devices through the VPN in the log so I am pretty sure it is getting the entry for 192.168.148.0/24.

I don't think it should make a difference but the ERX is also connected over a media bridge (to an AC66U), but that works perfectly fine with the subnets so I didn't think it was an issue. I am also using DNSCrypt if that would cause any issues at all, it works fine with the regular VPN.

Thanks for any help in advance.

Seth

 

[Martineau]

I would do this by adding an entry in the selective routing for the VPN client of 192.168.148.0/24. As soon as that entry is made the IOT subnet cannot connect to the internet at all.

I too have been tinkering with isolation of IoT devices using VLANs/Bridges etc., but whatever technique you use, separate subnets are inevitable for success!

Did you also add the firewall rules.....assuming ovpnc1 is the target VPN Client

iptables -I FORWARD -s 192.168.148.0/24 -o tun11 -m state --state NEW -j ACCEPT
iptables -I FORWARD -d 192.168.148.0/24 -i tun11 -m state --state NEW -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.148.0/24 -o tun11 -j MASQUERADE

 

[Seth]

Hi Martineau,

Thank you for your reply, I had not added these entries and must admit I'm a bit of a novice when it comes to some of these things. Getting my feet wet with this project to more secure my IOT devices.

I added the entries using the commands you gave above and confirmed they were there with iptables -S. I then ran service firewall_restart and again verified. If I do not enable the VPN routing these rules seem to make no difference, I can access the internet with my normal WAN IP, if I enable the VPN routing for the subnet then I get the same result, no connection is possible to the internet.

If you have any other suggestions or if I can provide any more information or logs that would help please let me know.

Thanks,

Seth

P.S. I should also add I verified tun11 was the correct interface by going to the Routing Table under System Log and noting that tun21 was tied to 10.0.8.0 which is my OpenVPN server which I can connect to, and that tun11 was the other interface there, so I assumed it must be it.

 

[Martineau]

I added the entries using the commands you gave above and confirmed they were there with iptables -S. I then ran service firewall_restart and again verified.

Verified what?...that you had trashed the rules you just entered by using service restart_firewall?

 

[Seth]

Yah, haha, too much time in Windows.. make the changes then restart the service... I realized that was happening later last night as I was doing more testing, but for some reason the IP entries didn't seem to come out if I listed them right after restarting the firewall... in any case, I made sure they were there and also looked up that iptables changes happen instantly so I didn't need to restart anything...

Here is what I did:

tseth@head-router:/tmp/home/root# iptables -I FORWARD -s 192.168.148.0/24 -o tun11 -j ACCEPT
tseth@head-router:/tmp/home/root# iptables -I FORWARD -d 192.168.148.0/24 -i tun11 -j ACCEPT
tseth@head-router:/tmp/home/root# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N FUPNP
-N NSFW
-N PControls
-N SECURITY
-N iptfromlan
-N ipttolan
-N logaccept
-N logdrop
-A INPUT -i tun11 -j ACCEPT
-A INPUT -i tun21 -j ACCEPT
-A INPUT -p udp -m udp --dport 637 -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j logdrop
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j ACCEPT
-A INPUT -j logdrop
-A FORWARD -d 192.168.148.0/24 -i tun11 -j ACCEPT
-A FORWARD -s 192.168.148.0/24 -o tun11 -j ACCEPT
-A FORWARD -o br0 -j ipttolan
-A FORWARD -i br0 -j iptfromlan
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i tun11 -j ACCEPT
-A FORWARD -i tun21 -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j logdrop
-A FORWARD -i eth0 -m state --state INVALID -j logdrop
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i eth0 -j SECURITY
-A FORWARD -j NSFW
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A PControls -j ACCEPT
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A iptfromlan -o eth0 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun21 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A iptfromlan -o tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i eth0 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun21 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A ipttolan -i tun11 -m account--aaddr 192.168.1.0/255.255.255.0 --aname lan  -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
tseth@head-router:/tmp/home/root#

I then made this entry into my VPN client routing table on the web interface

But I am still not getting a connection, if I do a tracert the packet makes it to 192.168.1.1 but that is it. There are no dropped packets being logged on the router, well either router for that matter. Everything I said above still seems to be holding true even if my initial test methods were flawed, if I take away the entry in the web interface everything connects as normal even leaving the iptables entries.

Thanks!

 

[Martineau]

...if I take away the entry in the web interface everything connects as normal even leaving the iptables entries.

I've changed and added an extra rule to my original reply...see if the three commands make a difference.

You should then check to see if there are any hits on the rules:

iptables -nvL FORWARD --line | grep tun11

iptables -nvL POSTROUTING --line -t nat

If not then you will probably need to check the status of the RPDB tables (with the GUI entry ACTIVE):

ip rule

ip route show table 111

 

[Seth]

THAT DID IT!

I can now ping the internet and trace routes to destinations from the AP on the IOT network and it is going through 10.3.17.254 which is the IP for tun11.

Now if you don't mind, I have a question about what that last command did.

I think it established nat rules for the tun11 interface for 192.168.148.0/24, but why did this not need done without the VPN?? Does the router automatically establish these rules for subnets through the normal WAN interface?

 

[Martineau]

Now if you don't mind, I have a question about what that last command did.

Does the router automatically establish these rules for subnets through the normal WAN interface?

Yes.

If you issue

iptables -nvL POSTROUTING --line -t nat

then you should see your WAN interface is already defined? - so clearly if you want to use the WAN, then obviously everything should be set up correctly.

To be honest, I'm not sure why you would want to route your IoT devices via the VPN?

I have defined 5 VLANs/subnets, and they are all isolated from each other but all go out via the WAN.
i.e. why would I need to explicitly obfuscate my IoT traffic...do I really need to keep my IoT device activities such as the Samsung TV's / LIFX lights etc. 'encrypted/secret'?

 

[Seth]

If I reset my firewall "service restart_firewall" and issue "iptables -nvL POSTROUTING --line -t nat" I get the follow, no mention of the 148 subnet:

tseth@head-router:/tmp/home/root# iptables -nvL POSTROUTING --line -t nat
Chain POSTROUTING (policy ACCEPT 3 packets, 156 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 MASQUERADE  all  --  *      tun11   192.168.1.0/24       0.0.0.0/0
2        0     0 MASQUERADE  all  --  *      eth0   !XXX.XXX.XXX.XXX         0.0.0.0/0
3        0     0 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x8000/0x8000
tseth@head-router:/tmp/home/root#

So that is what was confusing me I guess, after I add the nat then I see it:

tseth@head-router:/tmp/home/root# iptables -I FORWARD -s 192.168.148.0/24 -o tun11 -m state --state NEW -j ACCEPT
tseth@head-router:/tmp/home/root# iptables -I FORWARD -d 192.168.148.0/24 -i tun11 -m state --state NEW -j ACCEPT
tseth@head-router:/tmp/home/root# iptables -t nat -I POSTROUTING -s 192.168.148.0/24 -o tun11 -j MASQUERADE
tseth@head-router:/tmp/home/root# iptables -nvL POSTROUTING --line -t nat
Chain POSTROUTING (policy ACCEPT 8 packets, 458 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 MASQUERADE  all  --  *      tun11   192.168.148.0/24     0.0.0.0/0
2        5  4238 MASQUERADE  all  --  *      tun11   192.168.1.0/24       0.0.0.0/0
3       10   667 MASQUERADE  all  --  *      eth0   !XXX.XXX.XXX.XXX         0.0.0.0/0
4        0     0 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0            mark match 0x8000/0x8000
tseth@head-router:/tmp/home/root#

Actually, this was all a lie, I have my guest network running in the same method on 192.168.147.0/24 and I was more concerned about running that through the VPN than the IOT but when i made the post I was messing with the IOT subnet because it wouldn't disrupt anyone using my guest WIFI, hence to not confuse myself with the question went all in on the IOT subnet.

 

[Martineau]

Actually, this was all a lie,

Yeah whatever ...wouldn't be the first time someone deliberately withholds pertinent information and or "moves the goal posts"

 

[Seth]

I am in the US also, so now anything I can hide from my ISP is always a bonus!

Thanks again for all your help and explanation, it has been a good learning experience.