VPN based on SSID?

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

NoobSaibot

New Around Here
Is it possible to have two different SSIDs that assign addresses from the same subnet, but one SSID tunnels traffic and the other doesnt?

Something like 192.168.1.0/24
SSID-VPN address pool 192.168.1.2-126
SSID-NonVPN address pool 192.168.1.129-254
Both dhcp pools would use 255.255.255.0 and gateway 0.1

Then in VPN section set tunneled traffic to be .2-126.

Figured this way I could change a client VPN status from the client but still have VPN handled by the router. Also would like to keep them on the same broadcast domain for things like Chromecast.

I’m new to Asus and my router is still in the mail so I havent even seen the interface yet but wanted to get a head start thinking about the config.

Thanks.
 

eibgrad

Very Senior Member
From the perspective of the VPN, it's possible (using Merlin) to use routing policy to have one group of clients from the same IP network (192.168.1.0/24) use the VPN, and others use the WAN, based on their assigned IP. But you can't determine from the particular IP assigned to a given client *which* SSID was used to enter the system, since they all share the same DHCP pool, and regardless of SSID, the choice of assigned IP is arbitrary (at least I've never noticed a predictable pattern). Not unless you define static leases. But then the association is MAC->IP, NOT SSID->IP.

That's the problem w/ having the private and guest networks share the same IP network. On some firmware, you can create additional SSIDs (VAPs) and associate them w/ a *new* IP network (e.g., 192.168.2.0/24). And since each SSID is bound to a particular IP network, w/ its own DHCP pool, you can draw a reliable inference from the assigned IP which SSID was used to enter the system, and use it for routing policy purposes w/ the VPN. Of course, network discovery won't work between those two networks (although you can probably overcome that using an mDNS proxy (e.g., Avahi)).

This is one of those things that has to be taken into consideration before deciding on your choice of hardware/firmware. Some are better suited to solving certain problems than others. In my own case, I use FreshTomato on my primary router for this very reason. It gives me more options for solving this kind of problem. And all from the GUI. In some cases, you might be able to "hack" a solution w/ the Merlin firmware using the CLI and scripting (users are constantly attempting such things, w/ varying levels of success). But that's a rough way to start your life w/ a brand new router. Better that it supports what you need natively.

Frankly, it might be easier to daisy-chain a second VPN-capable router to the primary router (WAN to LAN respectively), assuming you're willing to live w/ the need for two separate IP networks. At least now the choice of SSID *does* result in VPN vs. non-VPN users. And it doesn't require routing policy support either, so it will work w/ oem/stock firmware. I often have older routers lying around that come in handy for such purposes.
 

NoobSaibot

New Around Here
From the perspective of the VPN, it's possible (using Merlin) to use routing policy to have one group of clients from the same IP network (192.168.1.0/24) use the VPN, and others use the WAN, based on their assigned IP. But you can't determine from the particular IP assigned to a given client *which* SSID was used to enter the system, since they all share the same DHCP pool, and regardless of SSID, the choice of assigned IP is arbitrary (at least I've never noticed a predictable pattern). Not unless you define static leases. But then the association is MAC->IP, NOT SSID->IP.

That's the problem w/ having the private and guest networks share the same IP network. On some firmware, you can create additional SSIDs (VAPs) and associate them w/ a *new* IP network (e.g., 192.168.2.0/24). And since each SSID is bound to a particular IP network, w/ its own DHCP pool, you can draw a reliable inference from the assigned IP which SSID was used to enter the system, and use it for routing policy purposes w/ the VPN. Of course, network discovery won't work between those two networks (although you can probably overcome that using an mDNS proxy (e.g., Avahi)).

This is one of those things that has to be taken into consideration before deciding on your choice of hardware/firmware. Some are better suited to solving certain problems than others. In my own case, I use FreshTomato on my primary router for this very reason. It gives me more options for solving this kind of problem. And all from the GUI. In some cases, you might be able to "hack" a solution w/ the Merlin firmware using the CLI and scripting (users are constantly attempting such things, w/ varying levels of success). But that's a rough way to start your life w/ a brand new router. Better that it supports what you need natively.

Frankly, it might be easier to daisy-chain a second VPN-capable router to the primary router (WAN to LAN respectively), assuming you're willing to live w/ the need for two separate IP networks. At least now the choice of SSID *does* result in VPN vs. non-VPN users. And it doesn't require routing policy support either, so it will work w/ oem/stock firmware. I often have older routers lying around that come in handy for such purposes.
Gotcha thanks. Sounds like i’ll need to login to the router each time I want to change a clients vpn behavior. Not sure how often i’ll need to do this anyway. Thanks again.
 

joegreat

Very Senior Member
Last edited:

eibgrad

Very Senior Member
Take a look at YazFi - it does SSID to VPN, access control between main LAN and guests, and Chromecast etc should work as it enables the reflector function of Avahinfor mDNS

Good to know. I always keep forgetting about YazFi.

Like I said OP, there's always users working w/ the CLI and scripting to work around most limitations. Given this and all the other AddOns available, I'm sure it can be a bit overwhelming for third-party firmware newbs.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top