Novice Question on VLAN and VPN

[seraphim]

Hi everyone,

I am trying to get my computers within the various VLANs in my office to access a NAS on a remote site, as shown in the attached diagram. The office network is properly setup with all VLANs able to access the internet and ping each other.

Currently, I have successfully established a VPN tunnel between the OpenVPN client on our existing Asus AC88U office router and the OpenVPN server hosted on the remote NAS. NAT passthrough is enabled for all VPN traffic in the Asus router.

While the office Asus router is able to ping the NAS, none of the computers in the various VLANs are able to ping/access the NAS.

I have attempted to add static routes in my office Asus router for 10.8.0.0 and 192.168.88.0 but this results in IP conflict warning in the Asus router.

Clearly I'm not a network expert, hence I would like to know if some missing routing configuration is required (perhaps on the remote router and/or the L3 switch)?

Or is this a case of my existing hardware not being able to achieve this?

Thank you in advance for your kind advice.

 

[eibgrad]

Are you ping'ing the NAS from the ASUS router based on the NAS's IP on the remote network (192.168.88.3), or its IP on the tunnel (10.8.0.1)?

Unless this is a site-to-site tunnel (i.e., a connection can be initiated from either side of the tunnel and into the other side) (and if it is, let me know), make sure the OpenVPN client is NAT'd.

 

[seraphim]

Hi and thank you for your reply.

Are you ping'ing the NAS from the ASUS router based on the NAS's IP on the remote network (192.168.88.3), or its IP on the tunnel (10.8.0.1)?

I just ping-ed again using Network Tools from within the ASUS router and was successful in reaching both 192.168.88.3 and 10.8.0.1.

PING 192.168.88.3 (192.168.88.3): 56 data bytes
64 bytes from 192.168.88.3: seq=0 ttl=64 time=5.428 ms
64 bytes from 192.168.88.3: seq=1 ttl=64 time=4.418 ms
64 bytes from 192.168.88.3: seq=2 ttl=64 time=3.796 ms
64 bytes from 192.168.88.3: seq=3 ttl=64 time=3.680 ms
64 bytes from 192.168.88.3: seq=4 ttl=64 time=3.549 ms

PING 10.8.0.1 (10.8.0.1): 56 data bytes
64 bytes from 10.8.0.1: seq=0 ttl=64 time=4.077 ms
64 bytes from 10.8.0.1: seq=1 ttl=64 time=10.809 ms
64 bytes from 10.8.0.1: seq=2 ttl=64 time=3.733 ms
64 bytes from 10.8.0.1: seq=3 ttl=64 time=4.315 ms
64 bytes from 10.8.0.1: seq=4 ttl=64 time=3.933 ms

Unless this is a site-to-site tunnel (i.e., a connection can be initiated from either side of the tunnel and into the other side) (and if it is, let me know), make sure the OpenVPN client is NAT'd.

I'm using the OpenVPN client provided by ASUSWRT. The only option I see for NAT is enabled in the router's WAN settings. Do I need Merlin in order to set the required options?

The eventual desired outcome will be a site-to-site tunnel. But I'm testing out the connection from one direction first due to the remote site's ISP router limitation.

 

[eibgrad]

When using third-party firmware (Merlin, FreshTomato, DD-WRT, etc.), the OpenVPN client normally provides an option to NAT the tunnel, which is required for clients behind the OpenVPN client (which is the router in this case) to access anything across the tunnel. At least when NOT configured for site-to-site. If the oem/stock firmware (which I don't use) does NOT provide the NAT option on the OpenVPN client webpage, most likely it's doing so automatically, by default. If it didn't, the VPN would pretty much be useless.

 

[eibgrad]

Maybe the problem is centered around the L3 switch. We don't know much about it. Is it acting as a router for the two IP networks behind it (172.168.1.0/24 and 172.168.1.0/24)? Is it possible to test a client on the 192.168.1.x network other than the primary router? At least if that works, we know the problem is likely at the L3 switch.

 

[seraphim]

Maybe the problem is centered around the L3 switch. We don't know much about it. Is it acting as a router for the two IP networks behind it (172.168.1.0/24 and 172.168.1.0/24)? Is it possible to test a client on the 192.168.1.x network other than the primary router? At least if that works, we know the problem is likely at the L3 switch.

Yes, the L3 switch is a Cisco SG300 which routes all the VLANs behind it (i.e. 172.16.1.0/24 and 172.16.2.0/24) as you correctly mentioned. I do have access to it and tried to ping the remote NAS (both 10.8.0.1 and 192.168.88.3) from the switch (with all access control ACLs disabled) but to no avail. So in summary, I can ping the remote NAS from the router but not from the L3 switch.

I will next try to connect a client to the 192.168.1.x network and ping from it as you suggested when I am at the office later.

 

[eibgrad]

Sure is behaving like the tunnel is NOT NAT'd.

The fact you're using oem/stock firmware makes it difficult to diagnose since you probably don't have any means to dump the firewall, or even if you could, couldn't make modifications anyway. I'm forced to make guesses. Perhaps there's something in your OpenVPN client config to blame, but I'd need to see more of the details.

One more thing you could try. Since you plan to eventually make this a site-to-site tunnel anyway, and you don't normally use NAT w/ such a tunnel, but instead add static routes to the OpenVPN server config (in the form of route directives) that point to the tunnel, you could add those now.

route 192.168.1.0 255.255.255.0
route 172.168.1.0 255.255.255.0
route 172.168.2.0 255.255.255.0

I wasn't sure if the L3 switch was NAT'ing the 172.16.x.x networks w/ its own IP on the 192.168.1.x network, so I included them as well.

So now if a packet is received by the OpenVPN server w/ any of those IP networks in its source IP, it knows to route them back over the tunnel. Normally it wouldn't know, and that's when you need to NAT the tunnel instead. But for a site-to-site tunnel to work, where clients on the OpenVPN server need access to the IP network(s) behind the OpenVPN client, you're going to need to add these routes eventually anyway. It will take a bit more to complete that site-to-site config (e.g., adding iroute directives), but for the time being, let's see if that helps w/ clients on the OpenVPN client side trying to reach the NAS.

 

[seraphim]

Hello again,

I've added your suggested routes in my OpenVPN server config file, restarted the server and immediately got an IP conflict error message in my ASUS router OpenVPN client connection.

I suspect this is due to the existing routes in my router which is necessary for my VLANs to access the internet:

172.16.1.0 255.255.255.0 192.168.1.254
172.16.2.0 255.255.255.0 192.168.1.254

Similarly, within my L3 switch is a single route for the VLANs to access the Asus Router:

0.0.0.0 192.168.1.1
... followed by rest generated entries for inter-VLAN routes

Interestingly, I discovered my L3 switch is now able to ping the remote NAS (this is after I removed openvpn server routes to resolve the conflict so there could have been an earlier error on my part - sorry).

So for now, the remote NAS can be pinged by the both the Asus router and the L3 switch but still not the VLANs.

It's getting late here (in Asia) so I test again when I am at the office hopefully tomorrow.

I really appreciate all you help and advice so far. Thank you!

Sure is behaving like the tunnel is NOT NAT'd.

The fact you're using oem/stock firmware makes it difficult to diagnose since you probably don't have any means to dump the firewall, or even if you could, couldn't make modifications anyway. I'm forced to make guesses. Perhaps there's something in your OpenVPN client config to blame, but I'd need to see more of the details.

One more thing you could try. Since you plan to eventually make this a site-to-site tunnel anyway, and you don't normally use NAT w/ such a tunnel, but instead add static routes to the OpenVPN server config (in the form of route directives) that point to the tunnel, you could add those now.

route 192.168.1.0 255.255.255.0
route 172.168.1.0 255.255.255.0
route 172.168.2.0 255.255.255.0

I wasn't sure if the L3 switch was NAT'ing the 172.16.x.x networks w/ its own IP on the 192.168.1.x network, so I included them as well.

So now if a packet is received by the OpenVPN server w/ any of those IP networks in its source IP, it knows to route them back over the tunnel. Normally it wouldn't know, and that's when you need to NAT the tunnel instead. But for a site-to-site tunnel to work, where clients on the OpenVPN server need access to the IP network(s) behind the OpenVPN client, you're going to need to add these routes eventually anyway. It will take a bit more to complete that site-to-site config (e.g., adding iroute directives), but for the time being, let's see if that helps w/ clients on the OpenVPN client side trying to reach the NAS.

 

[eibgrad]

I've added your suggested routes in my OpenVPN server config file, restarted the server and immediately got an IP conflict error message in my ASUS router OpenVPN client connection.

I suspect this is due to the existing routes in my router which is necessary for my VLANs to access the internet:

172.16.1.0 255.255.255.0 192.168.1.254
172.16.2.0 255.255.255.0 192.168.1.254

So those appear to be static routes, where 192.168.1.254 is presumably the IP address of the L3 switch on the same ethernet segment as the LAN side of the primary router. That suggests to me the L3 switch itself is NOT NAT'd. So that's good to know.

However, it makes no sense that adding route directives to the OpenVPN server would generate IP conflicts on the OpenVPN client. All those route directives do is update the OpenVPN server's routing table so that it knows to route any of those IP networks back over the tunnel. IOW, those routes are NOT being push'd to the client (at least not as I suggested them). So how can there be a conflict on the OpenVPN client side for actions being performed only on the OpenVPN server side??

Similarly, within my L3 switch is a single route for the VLANs to access the Asus Router:

0.0.0.0 192.168.1.1
... followed by rest generated entries for inter-VLAN routes

Interestingly, I discovered my L3 switch is now able to ping the remote NAS (this is after I removed openvpn server routes to resolve the conflict so there could have been an earlier error on my part - sorry).

I asked you to add three route directives to the OpenVPN server, one for 192.168.1.x, and the others for the two 172.16.x.x routes. I suspect when you had the error (for unknown reasons to me) in starting the OpenVPN server, you only removed the ones for 172.16.x.x. Leaving the 192.168.1.x now got the 192.168.1.x network able to access the NAS, for the reasons I stated. Given that, the OpenVPN client is probably NOT NAT'ing the tunnel, so the 192.168.1.x route directive is doing its job; it's telling the OpenVPN server to route replies to 192.168.1.x back over the tunnel. The same thing *should* be happening for the other two routes, had you NOT removed them.

 

[seraphim]

Hello again,

After an afternoon of tinkering, I decided to simply flash the Asus router with the latest Merlin firmware and everything magically works

From my limited understanding, it was probably down to some limitation of the stock firmware which ended up not NAT'ing the VLAN networks, like you said.

Now I can even use VPN Director to select which VLAN(s) gets access to the VPN tunnel. So easy!

Thank you so much @eibgrad for your guidance!

Sure is behaving like the tunnel is NOT NAT'd.

The fact you're using oem/stock firmware makes it difficult to diagnose since you probably don't have any means to dump the firewall, or even if you could, couldn't make modifications anyway. I'm forced to make guesses. Perhaps there's something in your OpenVPN client config to blame, but I'd need to see more of the details.

One more thing you could try. Since you plan to eventually make this a site-to-site tunnel anyway, and you don't normally use NAT w/ such a tunnel, but instead add static routes to the OpenVPN server config (in the form of route directives) that point to the tunnel, you could add those now.

route 192.168.1.0 255.255.255.0
route 172.168.1.0 255.255.255.0
route 172.168.2.0 255.255.255.0

I wasn't sure if the L3 switch was NAT'ing the 172.16.x.x networks w/ its own IP on the 192.168.1.x network, so I included them as well.

So now if a packet is received by the OpenVPN server w/ any of those IP networks in its source IP, it knows to route them back over the tunnel. Normally it wouldn't know, and that's when you need to NAT the tunnel instead. But for a site-to-site tunnel to work, where clients on the OpenVPN server need access to the IP network(s) behind the OpenVPN client, you're going to need to add these routes eventually anyway. It will take a bit more to complete that site-to-site config (e.g., adding iroute directives), but for the time being, let's see if that helps w/ clients on the OpenVPN client side trying to reach the NAS.

 

[eibgrad]

That's good to hear. However, as I said before, once you move to a site-to-site configuration, you typically do NOT NAT the tunnel. And when you reach that stage, you may be back here w/ the same problems as before. But at least for now, YES, everything points to NAT NOT being enabled w/ the prior configuration. And at least it now works.