Setting up VPN client using OpenWrt as a client device

I'm trying to add an OpenWRT router (an Archer C7 v5) to an existing network to function solely as a wired and wireless VPN client / gateway with Kill Switch. I'd like to avoid setting it up as a separate subnet (if possible) so I can locally connect between VPN and non-VPN devices.

I seem to have the wired side working as desired, but the wireless side isn't going over the VPN.

Setup (via Luci) on the OpenWRT router is as follows:

  • LAN port physically connected to a LAN port on the main (internet facing) router. Nothing is connected to the WAN port (nor any of the other LAN ports).
  • Assigned a static address (192.168.1.2).
  • Gateway points to main (internet facing) router (192.168.1.1).
  • DHCP server is disabled.
  • WireGuard (wg0) is set-up (with VPN DNS servers set) and is connecting successfully.
  • Firewall zones:
    lan > wireguard = accept, accept, accept
    wireguard > reject = reject, accept, reject PLUS masquerading, mss clamping

With WiFi off, that all works perfectly. If I set the gateway on my computer to 192.168.1.2 then I get internet over the VPN, without any DNS leaks. And if I manually stop the WireGuard connection then I lose internet. Perfect!

Now I want to do the same thing with WiFi. So I did this:

  • Enable wlan0 and set it up as an access point with a unique SSID.
  • Network is set to LAN.

When I connect I get internet but it's not going over the VPN - and the connection works whether or not WireGuard is connected. So if the WiFi is on the LAN network, why is it behaving differently? And how do I force the WiFi connections over the VPN?

It's taken me 2 days to get this far and I feel I'm close, but perhaps not! Or maybe I'm trying to do the impossible? Thank you for any input and guidance!

Your problem is essentially the same as others that have been posted here in the past -- in particular see my response in this thread. In your case, when you enable wifi, it is simply bridged to the same subnet as the primary router's LAN, which means wifi clients get their DHCP leases from the main router. Those leases will specify the primary router as the gateway, so the clients do not know that there is another gateway (i.e. your VPN router) available.

There are a few ways that this can be handled as you will see in that thread. Is there a particular reason you don't want to setup a different subnet?

1 Like

Many thanks for taking the time to read and respond. I read through the post you linked to and it made perfect sense. Weirdly, this had crossed my mind earlier today and I realized that devices were being set to the .1 gateway by the DHCP server on the primary router. I had actually tried manually changing the gateway to .2 on a device connected to the VPN wifi before writing my initial post and it didn't seem to make a difference. I will try again tomorrow, but now I'm wondering if I have more than one problem.

The reason I'm trying to stay on the same subnet is to allow devices that don't need a VPN to connect to devices that do across the local network. I know you warned about not having more than one DHCP server, but what about if I prevent a small group of addresses from being served by the primary router and then restrict the OpenWRT router to only be able to serve that same small group? Does that work? If not then what's the best solution?

That is possible. Post your config files for review if it doesn't work (instructions below).

You could put everything behind the VPN router and then use VPN Policy Based Routing to control what should go through the VPN and what shouldn't.

Nope. If there are 2 DHCP servers on the same subnet, they will cause conflicts. The behavior may be unpredictable and will likely cause major headaches.

IMO, putting everything behind the same router with the VPN and then using VPN PBR. This can be done on a single subnet or on multiple subnets with the ability to route between them depending on the specifics of your network requirements.


Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like

I realize my mistake. When I changed the gateway IP in the wireless device (my phone), I didn't set the DNS - so there was actually no internet connection at all from the OpenWRT wifi - the phone was using the cellular connection. :man_facepalming: Now the gateway and DNS are set, it works as expected (and predicted by you).

I'm trying to get my head around my options. My primary router is a Unifi Dream machine which is connected to several Unifi APs around the house - it all works great so I'm reluctant to rock that boat too much if I don't have to. The VPN router is an Archer C7 which i'm assuming is older/slower.

If I go the VPN PBR route, then...

  • Could that be as simple as turning off DHCP on the primary router and turning it on on the VPN router. Then using PBR to decide, on a per device basis, what goes over the VPN?
  • I guess I then turn off wifi on the VPN router altogether and just let everything connect through the main router.
  • Can DHCP on the VPN router (.2) set wired devices to use the main router (.1) as their default gateway (unless overridden by the PBR)? Or does that actually become the exception that needs to be set for every device EXCEPT those that are using VPN?

Is the alternative to have the VPN router on its own subnet? I'm trying to think through how that would work:

  • I guess the physical connection is from a LAN port on the main router into the WAN port on the VPN router.
  • The advantage would be that I can configure the device itself according to whether I want VPN or not - either by manually setting the IP/DNS on wired connections or connecting to the appropriate wifi network for wireless.
  • The disadvantage is that devices on each network can't see or talk to one another. So what's the way around that? Set up traffic forwarding on both routers? And at that point am I back to square one with the two DHCP servers - or do they stay confined to their subnet?

On balance, the VPN PBR sounds more elegant. And since I'm only dealing with a few devices that can't run their own VPN software natively it should be set it and forget it.

I was so pleased with how far I got, only to fall at the last hurdle! But learning is fun! :upside_down_face:

Thanks again for all your help and guidance.

Yeah, let's not mess with your Unifi setup -- done properly, that can be a really high performance network.

There are a number of ways to handle this, and each has some pros and cons, all depending on what your goals are. However, what I would do here is to make a VLAN on the UDM and a new SSID associated with that VLAN. Then, I would put the C7 on that VLAN similar to how it is currently configured (i.e. static IP and connected by the LAN port; but you will have to update the IP configuration). Finally, you'll set the DHCP server for that specific network (on the UDM) with a custom gateway -- pointing clients to use the C7 as their gateway. Anything on that SSID/network that uses DHCP will then use the C7 as the default gateway, and the C7 will then create the tunnel that egresses via your UDM.

If you wish to have the ability to communicate between devices that are on different networks, you will use VPN PBR on the OpenWrt side to enable that functionality (otherwise all egress from the OpenWrt router would be via the VPN tunnel).

Keep in mind that mdns and other auto-discovery type protocols don't typically work across subnets (think Sonos, chrome cast, airplay/airprint). So if this is a requirement, you'll also need to turn on the mdns reflector/repeater feature in the Unifi network configuration.

1 Like

As you can see, I know about enough to be dangerous so who knows if it's done properly! But I've been very happy with its performance and I guess that's all that matters. (I just wish it had better VPN capabilities.)

I can't thank you enough for taking the time to read through my posts and respond in such a detailed manner. What you wrote makes perfect sense and I shall have a go at tackling the implementation over the next day or two - so I shall report back in due course. If you knew what this was all for you'd probably think me mad - but at this point it's the challenge and joy of learning (and hopefully succeeding) that is the motivating factor.

Been there, done that.

Well... It's not going great.

I set up the VLAN on the UDM and an associated SSID. The new wireless network works great - but there's no internet on wired devices manually configured to use the VLAN. I'm wondering if this is due to my unmanaged switches?

Unmanaged switches do not play well with VLANs.

Let’s see a diagram of your physical topology.

Network topology from where I'm sitting is:
Computer > Netgear GS810EMX (managed switch) > MoCA 2.5 > MoCA 2.5 > TRENDnet TEG-S16D (unmanaged switch) > UDM

I realized the Netgear was set to "No VLANs" which obviously wasn't helpful. I changed that to "Basic 802.1Q VLAN" and set the port for the MoCA adapter to trunk.

So now I can choose whether I want my computer to be on VLAN 1 (.1.x network) or the new VLAN 2 (.2.x) network. That works - I can now connect on both.

Questions:

  • Does the fact that that works mean that the unmanaged switch in the chain isn't bothered by the VLANs?
  • Do I really have to reconfigure the computer AND the switch to hop between these two subnets? Is there any way to set the SX10 to be less bothered about what VLAN I'm connected to?

When I introduce the C7 into the mix I will connect it directly to the UDM.

  • Should the gateway setting on the C7 be set to 192.168.1.1 or to 192.168.2.1 or doesn't matter?
  • Should I be able to connect to the C7 admin panel from the 192.168.1.1 network?

I'm only slightly more confused than I was this morning. :rofl: I think it's 2 steps forward and 1 back but it might be the other way around.

Using an unmanaged switch with VLANs is never recommended because the behavior of the switch is not defined for tagged frames. Many switches just pass them to all ports and it seems to be fine. Some switches will choke on them or even strip the tags and cause havoc. There are a number of functional reasons why they aren't good -- most notably that your trunk is available on all ports and you cannot configure the VLANs on a per-port basis (nor can you assign access ports). I'd recommend replacing the unmanaged switch when you can.

Given the way you've got things setup, I think this is likely to be a reality.

but... if you set the PC on VLAN 2 and then use VPN PBR, you can get certain services to go through the tunnel and others to be passed through the VPN router without sending to the tunnel.

I'd recommend connecting the C7's LAN to VLAN 2. This VLAN will then become the VPN'd network.
Set the C7's LAN to static IP with an address in the 192.168.2.0/24 network (maybe 192.168.2.2) with a gateway of 192.168.2.1. Don't forget that you also need to define the DNS. Be sure to turn off the C7's DHCP server (set to ignore on LAN).

Then, on the UDM, set VLAN2's DHCP server to assign a gateway of 192.168.2.2 (or whatever the address of the C7). This will steer clients to use the C7 as the gateway, and the C7 will send traffic via the tunnel. As mentioned before, VPN PBR can get you selective tunneling.

Thanks once again for the response.

More MoCA adapters and multiple unmanaged switches through the house - replacing them all would be costly. My understanding (as of this afternoon) is that the most important time to use a managed switch is when more than one VLAN is connected to that switch. In my case, there will literally be two devices that will be wired to the second VLAN (and if push came to shove then I could connect them wirelessly). There are another two devices which can only be wireless - hence the need for the separate wireless SSID over VPN which is what got us here in the first place.

I'm just trying to figure out how to continue configuring the C7. Once I put it on the VLAN will I be able to see it from the default/primary network? Or do I need to put my computer on the VLAN too in order to configure it? I guess I'm about to find out.

An unmanaged switch is designed for a single (untagged) network. Anytime tagged frames are being passed through one of these switches, all bets are off (although honestly many will just pass those tagged frames).

I think there may be some easy and cost effective ways of handling the situation with the need for managed switches, but it entirely depends on the physical constraints. To that end, could you draw a diagram of your network and show where critical equipment will connect (specifically, the devices that need to be on the VPN (VLAN 2) and those that will be on VLAN 1 all the time). An actual drawn diagram will help make the physical constraints more clear.

By default, Unifi allows routing between subnets. This means that a computer sitting on 192.168.1.0/24 will be able to connect to the C7 via it's IP address (I was proposing 192.168.2.2). If you've put any firewall rules in place on the UDM to restrict inter-VLAN routing, that would obviously need to be considered.

I'm now having problems with the wifi associated with the newly created VLAN - it's no longer working. Given that my Unifi Acess Points are hard wired, do they also need to be connected to managed switches to work with the VLAN?
I think I'm close to admitting defeat.

They're supposed to be, yes.

You could have a number of different issues -- and it may or may not include the unmanaged switche as the culprit. I'd really love to see a drawing of your network so I can potentially recommend solutions. You might be able to get a $30-$50 USD managed switch and solve these issues, or maybe it is more complex/costly... it all depends on the physical topology.

It's (relatively) large and complex but basically....

  • 6 separate areas / rooms all connected by coax / MoCA adapters - let's call them #1 - #6
  • Area #1: MoCa > Unmanaged switch > UDM (with WAN directly connected) + devices
  • Area #2: MoCa > Netgear managed switch (it has 2 x 10Gb ports which allow quick backup between 2 NAS devices) > Unmanaged switch > AP + devices
  • Area #3 and #4: MoCa to Unmanaged switch > AP + devices
  • Areas #5 and #6: MoCa to Unmanaged switch > devices

By devices I mean computers, NAS, Tivo, Apple TV etc. Usual stuff.

That may all sound like a recipe for disaster - but it works like a charm. Just doesn't like the VLAN apparently.

I actually have a couple of the 5-port managed Unifi switches lying around - so possibly put those first in line after the MoCA adapter wherever there is an AP or need to wire into the VLAN?

Yes, this could help a lot, and they are pretty straight forward to configure.

Do your MoCA adapters specify if they are suitable for use with VLANs (some explicitly support 802.1q, others support it but don't say so, and some may not support it and may cause issues).

"Passes VLAN tags them but can't add them."

That's fine. Knowing this means that you can ensure that the MoCA connection between areas will not be problematic.

I'm not sure about the number of ports you are using on your UDM directly, but you can connect one port there directly to the MoCA adapter (that UDM port would be configured as a trunk). If you don't have any extra ports on that, put one of your Unifi switches (I'm guessing the USW flex mini?) between the UDM and the unmanaged switch... configure the flex-mini port that connects to the UDM as a trunk (profile all) as well as trunk to the MoCA adapter. For the port that connects to the unmanaged switch, make that profile the one for VLAN 1 -- this way the unmanaged switch only gets the single untagged network.

You'll do similar things for the rest of the network, but start with just one other area.

Pro-tip... setup the flex mini switch such that you have one of the ports port for profile VLAN 1 and another port for profile VLAN 2... then you can literally just plug in a computer into each port in succession and verify that the VLANs are getting passed through the trunks properly.