Can internally routed network access internet via VPN?

[jrhjr]

Hey I'm new - go easy on me!

I've got an RT-AC86U running Merlin 384.18. It is connected to NordVPN via OpenVPN with strict policy rules making it so my whole network goes through the VPN - sorta... And therein lies the problem.

My main network is 192.168.1.0/24 and everything in that network works great and goes over the VPN (except a few devices that can't go over VPN for incoming port forwarding purposes). I have a policy rule directing 192.168.1.0/24 through the VPN then exception IP addresses pointed through the WAN.

I'm trying to segment my network to secure my network from some IoT devices.

I have a Linksys Velop system (which is garbage but alas I've got it) providing Wi-Fi to my house and recently switched from bridged to routed mode. The Velop internal network is 10.150.1.0/24 and the internet is actually plugged into my main network. I put the static routing rules in place to let it communicate with my whole network - it works great and it has internet access.

The problem is that if I direct Merlin to direct the Velop network (10.150.1.0) to use the VPN it can't - it loses all internet connectivity. If I remove the rule directing the device IP to VPN (and thus back out the WAN interface) - everything is fine again though the traffic isn't going out via VPN.

BTW, I also tried resubnetting 10.150.1.0/24 to 192.168.2.0/24 with the same results.

So my question is, is this even supported? Can I have an internally routed network access the Internet through a VPN connection with Merlin?

Help?

 

[eibgrad]

There's something here I'm not getting (realize I have no familiarity w/ this device at all). But it could just be me.

You claim you changed it from bridged mode to routed. But based on your description, it sounds like just the opposite. Because in routed mode, I would assume it behaves like a router; its WAN has an IP assigned from the primary router, and its clients are NAT'd over that WAN. Thus, the primary router (and by extension, the VPN) never see the network (10.150.1.0/24) behind the Velop. All they ever see is the IP assigned on its WAN. And PBR (policy based routing) should work normally (although you won't be able to distinguish specific wireless clients from one another).

But that's NOT what I'm hearing. It *sounds* like the Velop is bridged, but using a different network from the primary, so it gets exposed directly to the other network, thus the need for the static route.

If that's the case, then why not just place the Velop on the same network as the primary?

If that's because you're trying to isolate that network, then it seems the wrong approach since both networks share the same ethernet segment. That is NOT the proper way to isolate two networks from each other. Such networks are only incidentally isolated, and via reconfiguration of the client, could just as easily get themselves established on each other's network. Something not possible in a routed config.

Anyway, until I understand the configuration, I can't really explain the issue w/ the VPN and PBR.

 

[jrhjr]

Thank you for the response.

On my Velop router I did turn bridge mode off and then, so that Merlin would see the individual IPs on the opposite side of the Velop (the 10 side) - I turned NAT off on the Velop so it's actually truly routed (versus using NAT). So in theory Merlin should see the individual IPs on the 10 network. Now Merlin is still routing and NAT'ing all traffic out to the Internet, including the individual 10 IP addresses, it just falls apart when I try to force Merlin to send the 10 traffic out the VPN interface. BTW in order to achieve this config I had to add one static route to both Merlin and Velop to help them route the traffic.

This config should be secure (unless I mistakenly put devices on the LAN side of Merlin (the 192.168.1.0 network) - but I will not be putting devices there.

Basically my config is <internal house stuff> - - >Velop - - - > Merlin - - - > Internet. At some point I'll complicate it further with a guest wifi network on both the Velop and Merlin routers but I didn't want to complicate this discussion with those details because if I can't get the 10 traffic through the VPN then I am scrapping everything and going back to the drawing board.

Hopefully that helps.

 

[eibgrad]

Ok, then it *is* pretty much as I suspected. You essentially have two different IP networks sharing the same ethernet segment.

Again, this is NOT secure. Not by my definition of security. It's closer to "security through obscurity" than anything else. As I said, it's entirely possible for a client on one network to reconfigure itself for the other. Or at the very least *snoop* the ethernet traffic of the other.

Now I realize in a home environment, the use of the term "security" may not be as stringent as in a business environment, and that ppl will take license and claim this type of setup is "secure". But again, it isn't. I'd be fired from my job if I ever proposed such a thing to my boss!

But I don't want to beat a dead horse. Do what you want.

The way PBR (policy based routing) is typically implemented is by creating an alternate routing table that has the VPN as its default gateway. Of course, the primary/main routing has the WAN/ISP as its default gateway. When you create your policy rules, the router will then choose which of those routing tables to use based on whether a client needs to be directed to the VPN or WAN.

One of the problems that can creep into a configuration like this is if the router is *unaware* of some particular network and fails to add it to the VPN's routing table. It will surely be in the primary/main routing table, or else it wouldn't work at all. But sometimes the developer who implemented PBR fails to copy the static routes into the VPN's routing table (or perhaps some timing issue is causing them to be missed). And when that happens, then obviously anything in that network that's been told to use the VPN by PBR can't be routed back to the client! The effect from the client's perspective is a loss of connectivity.

Now do I know for sure this is what's happening? No. But it sure sounds like it. And the fact I've seen this kind of mistake made many times before w/ other firmware at least makes me suspicious it is.

One way to know for sure is to locate the actual routing table used by the VPN and just see if it contains your static route. Assuming you're using the first OpenVPN client ...

ip route show table ovpnc1

Compare that to the primary/main routing table (again, which has to have that static route if it works at all).

ip route show table main

If it turns out the static route *is* there in both tables, at least we can take that possibility off the table (no pun intended).

 

[jrhjr]

My apologies for not explaining the routing architecture well enough. The Velop router/firewall acts as a physical separator for the 10 / 192 networks. More specifically - the Velop firewall will drop inbound traffic from the 192 network were any devices actually on it. There is physical separation - all my devices are connected to the Velop AP and / or switch and the Velop is then the only thing connected to Merlin. A Wireshark trace would never be able to see both the 10 & 192 traffic on the same physical network because there is physical separation (not at the switch level - at the router/firewall level). The wireless and wired clients all connect into the internal Velop 10 network and none of those devices are plugged into any shared equipment with the Merlin 192 network. The only way for 10/192 to cross is through the Velop router/firewall. With this config the 192 Merlin network is, in a weird way, part of the Internet from my perspective and none of my devices live there.

Now I believe I understand your point - all my devices are on the 10 network - so what's the point of my architecture? You're right - all my devices are on it - now - I'm still testing it before I move all my 50+ devices over to this new architecture. The point of the test is to see if Velop & Merlin can provide the security I need. I briefly mentioned that I plan to turn on guest networks on both Velop and Merlin - actually I've already turned it on / off to see how it works. These guest networks will be where the IoT devices lives and Velop & Merlin will prevent the IoT devices from accessing both the 10 and 192 networks I've mentioned so far (actually IoT devices on the Velop guest network could get to devices on the 192 Merlin network which is why I won't be putting any non-IoT devices there).

There may also be a question of - why bother with the Velop - well the Velop is a mesh system I bought before I was wise to Asus/Merlin and I've got too much money invested in it to throw it away. I've got four Velop APs blanketing my house with Wifi and there's just no way my one Asus router can do that. One day I'll abandon the Velop system but not until WiFi6 is more mainstream and not until I've gotten more use out of the Velop.

Now you may be wondering why I need the Velop in Router mode - Bridge mode should suffice - but this is where the Velop falls down. When Velop is in Bridge mode the guest network protections do not exist and the guest network can access my main network - this is a documented bug in Velop and one of the reasons I hate it. The only way for Velop to properly prevent the guest network from accessing my main network is by putting it in Router mode. I should be able to put it in Router mode and accomplish everything I want and so far I can - except for this 10 network going out the VPN interface of Merlin. Sure it's a lot more complicated but I don't mind.

Now more to the point - I SSH'd into Merlin and can see the static route is in both routing tables.

Here's the thing - I don't think Merlin is dropping the traffic because it doesn't have a route back in the way you described; I think it's blocking the return traffic from the Internet at the firewall level because it doesn't recognize the conversation. I feel like maybe the outbound traffic is going out the VPN interface with the public IP and maybe coming back through the WAN interface which is unexpected and thus dropped. I have to prove this yet and it is probably time to ...

Thanks.

 

[eibgrad]

I turned NAT off on the Velop so it's actually truly routed (versus using NAT).

Now the above statement you made makes more sense. So in fact it is routed, and even firewalled (essentially a WAN), it's just NOT NAT'd. Btw, whether it's NAT'd or NOT, it's still routed. NAT only determines if the 192.168.1.0/24 network sees the 10.150.1.0/24 network on its own network (no NAT), or whether the 192.168.1.0/24 network only sees the Velop's WAN ip (NAT'd).

Sorry for being a stickler w/ terms, but it's so difficult to debug these things when all you have is this forum. I find precision often makes the difference.

It sounded from your initial description like the two networks were bridged. But now I realize it's just that the (routed) Velop is no longer NAT'd as packets move from its network and up to Merlin, and hence the need for the static route.

As far as RPF (reverse-path filtering), which is when the firewall prevents packets, from the same logical connection, from coming into and leaving out of the network via different gateways, you see this most often wrt remote access, where the incoming traffic over the WAN has its replies sent over the VPN, because the target of that remote access is bound to the VPN. Those packets are usually just dropped (at least when you have a *stateful* firewall).

In this case, I don't see that happening. Wrt any given network and its firewall, the point of egress and ingress of any particular logical connection would *appear* to always be through the same gateway. That's why I didn't both bother going down that path.

All in all, everything appears to be correct. It really doesn't sound any different in terms of architecture than the case of any ol' router being daisy chained to the primary router, WAN to LAN respectively. The only real decision to be made is whether or not to NAT. And regardless, that should NOT affect whether PBR does or doesn't work. Just so long as the primary router knows how to route to the 10.150.1.0/24 network (when NOT NAT'd), which it does thanks to the static route.

 

[ColinTaylor]

@jrhjr Presumably this works if you enable NAT on the Velop?

My firmware is slightly different than yours but I suspect your problem is with the way the Asus masquerades the VPN client traffic. Check the NAT table. In my firmware the rule only masquerades the local subnet, which would be a problem for your non-local (10.150.1.0/24) traffic.

# iptables-save -t nat | grep tun
-A POSTROUTING -s 192.168.1.0/24 -o tun11 -j MASQUERADE

 

[eibgrad]

@jrhjr Presumably this works if you enable NAT on the Velop?

My firmware is slightly different than yours but I suspect your problem is with the way the Asus masquerades the VPN client traffic. Check the NAT table. In my firmware the rule only masquerades the local subnet, which would be a problem for your non-local (10.150.1.0/24) traffic.

# iptables-save -t nat | grep tun
-A POSTROUTING -s 192.168.1.0/24 -o tun11 -j MASQUERADE

Gee, I'm surprised if that's the case. Most implementations on other routers (at least w/ third-party firmware) masquerades *all* traffic, just to avoid this type of problem. I had assumed that was the case /w Merlin as well.

If you're correct, it makes me wonder if he does the same w/ the WAN (something dd-wrt started doing years ago, and caused it own share of similar headaches).

EDIT: Just verified on a lab router running Merlin (384.17), and that appears to be the problem (ugg).

Chain POSTROUTING (policy ACCEPT 8 packets, 929 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      tun11   192.168.1.0/24       0.0.0.0/0

I don't understand that decision by Merlin. THAT is a maintenance headache in the making.

 

[ColinTaylor]

I don't understand that decision by Merlin. THAT is a maintenance headache in the making.

I don't know whether this was a conscious decision by Merlin or Asus or not. I can see an argument for assuming non-local traffic is not trusted and should therefore not be allowed through a VPN. But to be fair this firmware was never designed for this kind of multi-subnet setup. Merlin even says as much:

The primary goals of this project are to fix bugs, add a few basic features and tweaks to the original firmware. This firmware will try to remain as close as possible to the original firmware. If you are looking for a slew of advanced features, then this project is not for you. Look at TomatoUSB or DD-WRT, two excellent products that might suit your needs better.

In all the years this project has been running this is the first time that I can recall of someone wanting to do this. Even then Merlin's firmware allows it to be worked around with custom scripts. So I think it is unfair to criticise it for something it wasn't designed to do.

 

[eibgrad]

I don't know whether this was a conscious decision by Merlin or Asus or not. I can see an argument for assuming non-local traffic is not trusted and should therefore not be allowed through a VPN. But to be fair this firmware was never designed for this kind of multi-subnet setup. Merlin even says as much:


In all the years this project has been running this is the first time that I can recall of someone wanting to do this. Even then Merlin's firmware allows it to be worked around with custom scripts. So I think it is unfair to criticise it for something it wasn't designed to do.

Fair enough. But realize in this situation, those packets are *still* getting to the remote network. It's just that the replies can't get back because the remote network doesn't know how to route them. IMO, that's not a good design, even given Merlin's assumed intent. The proper way to deal w/ the situation is to *firewall* any traffic you do not explicitly intend to allow across the VPN. As currently implemented, it's basically relying on a mis-configuration (for lack of a better term) to deal w/ the issue (again, if we're correct about the intent).

Assuming that is the intent, it's also inconsistent w/ the treatment of the WAN. At least based on my lab router, it masquerades *all* WAN traffic.

admin@merlin-lab1:/tmp/home/root# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 3 packets, 236 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      tun11   192.168.1.0/24       0.0.0.0/0
2286  181K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 MASQUERADE  all  --  *      eth0   !192.168.63.106       0.0.0.0/0
    0     0 MASQUERADE  all  --  *      br0     192.168.1.0/24       192.168.1.0/24

Note, eth0 is my WAN.

Regardless, as when dd-wrt did the same thing years ago w/ the WAN, it was nothing but a headache. I lost count of how many users ran into this issue. As soon as you're dealing w/ other networks downstream (and imo, it's not safe to assume this won't be the case), things now break. In the case of dd-wrt, it was even worse. Even adding a virtual wireless network on the router itself, it didn't automatically masquerade it over the WAN. Strangely (assuming it was done w/ the same intent), it masqueraded *all* traffic over the VPN! Such inconsistency can drive ya nuts.

Bottomline, imo, all traffic should be masqueraded across the VPN, just like the WAN (what's good for the goose, is good for gander).

 

[octopus]

Maby you can use the "new" vpn-route instead?

 

[eibgrad]

If it is the lack of NAT'ing, you can add it w/ a simple nat-start script.

iptables -t nat -I POSTROUTING -s 10.150.1.0/24 -o tun11 -j MASQUERADE

Might want to first try it from a shell (ssh) to prove it.

 

[RMerlin]

Maby you can use the "new" vpn-route instead?
View attachment 25681

This is only for L2TP.

 

[octopus]

This is only for L2TP.

Ok i thougt it was for vpn.

 

[RMerlin]

Ok i thougt it was for vpn.

L2TP is a VPN.

Yes, this new feature is very confusing the way the webui is implemented, since it only applies to the older VPN client technologies (PPTP and L2TP), but it was added by themiron for some usage scenarios, and neither of us could come up with a better web implementation.

 

[jrhjr]

If it is the lack of NAT'ing, you can add it w/ a simple nat-start script.

iptables -t nat -I POSTROUTING -s 10.150.1.0/24 -o tun11 -j MASQUERADE

Might want to first try it from a shell (ssh) to prove it.

This worked for me, although my VPN client is on tun15 so I had to adjust accordingly. I was also pleasantly surprised that with this rule in place and VPN then disconnected - that it then sent the 10 traffic out the WAN successfully instead. I was concerned because when VPN drops the 192 NAT VPN rule disappears from the iptables -nat -L list. BTW, in my case, if the VPN is down it is OK to 'fail open' so this is the preferred behavior.

Based on your comment I'm thinking this command won't stick after a reboot - how do I get it to stick after a reboot? Is there a way in the web GUI to like paste this command to be run on boot or do I have to SSH in and do it that way?

Thanks for everyone's input on this one - it looks like a workable solution is at hand.

BTW - I got another one of these weird one's coming soon relating to DNS over VPN - I just have to figure out how to explain it - it is a bit more complicated and convoluted.

 

[eibgrad]

Paste the following script into a shell (ssh) and it will automatically create and configure the necessary nat-start script. Then reboot.

mkdir -p /jffs/scripts
cat << "EOF" > /jffs/scripts/nat-start
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.150.1.0/24 -o tun15 -j MASQUERADE
EOF
chmod +x /jffs/scripts/nat-start

Also, make sure you have enabled JFFS custom scripts on the Administration->System page!

 

[chadster766]

Hey I'm new - go easy on me!

I've got an RT-AC86U running Merlin 384.18. It is connected to NordVPN via OpenVPN with strict policy rules making it so my whole network goes through the VPN - sorta... And therein lies the problem.

My main network is 192.168.1.0/24 and everything in that network works great and goes over the VPN (except a few devices that can't go over VPN for incoming port forwarding purposes). I have a policy rule directing 192.168.1.0/24 through the VPN then exception IP addresses pointed through the WAN.

I'm trying to segment my network to secure my network from some IoT devices.

I have a Linksys Velop system (which is garbage but alas I've got it) providing Wi-Fi to my house and recently switched from bridged to routed mode. The Velop internal network is 10.150.1.0/24 and the internet is actually plugged into my main network. I put the static routing rules in place to let it communicate with my whole network - it works great and it has internet access.

The problem is that if I direct Merlin to direct the Velop network (10.150.1.0) to use the VPN it can't - it loses all internet connectivity. If I remove the rule directing the device IP to VPN (and thus back out the WAN interface) - everything is fine again though the traffic isn't going out via VPN.

BTW, I also tried resubnetting 10.150.1.0/24 to 192.168.2.0/24 with the same results.

So my question is, is this even supported? Can I have an internally routed network access the Internet through a VPN connection with Merlin?

Help?

Below are some of my standard Velop setup recommendations:

• 5Ghz doesn't pass through building materials very well so I wouldn't worry about a strong outside 5Ghz interference too much.
• According to my previous Velop testing Bridge Mode will provide the most performance since the Velop won't be doing NAT and firewalling.
• Use your sysinfo.cgi bh_report to maximize your coverage by keeping the AP\STA signal strengths to approx -70 between nodes. This will also help your wireless client roaming between nodes.
• Disable Prioritization, Node and Client Steering.
• Set Prioritization speeds manually to 1024mbps for both download and upload even though it's disabled
• Have separate SSIDs for 2.4Ghz and 5Ghz.
• Try to get a hub and spoke topology instead of a daisy chain.

Instructions to get the Velop sysinfo.cgi report:

1. Linksys App => Velop Administration => Click on first node in list
2. LAN => IP Address
3. Use the LAN IP Address of the node in the below URL
4. http://<your node ip address>/sysinfo.cgi
5. Login using your Velop system password and username of "admin"
6. The report will display in browser, search for "bh_report" to find the backhaul report section

The output should look like this:

Code:
bh_report
Node (MAC) NODE IP PARENT IP Intf. Chan. RSSI(AP/STA) Speed State Timestamp
------------ --------------- --------------- ----- ----- ------------ --------- ----- ------------
149182854304 192.168.200.107 192.168.200.131 5GH 161 -70/-59 155.89500 up 1581717301
If you have wired nodes disconnect the Ethernet cable, wait 5 minutes and re-run the report to make sure those nodes are placed properly as well.

 

[chadster766]

A another option is to have your Merlin router as your main router and put the Velop system into Bridge Mode. This way you have one network for everything and increase the performance of the Velop system since it's no longer the firewall.