Is There a Way to Grant Mobile VPN Users access to other Remote IPSec Networks?
-
Hi all,
A company I'm working with is considering switching its proprietary router/firewall appliances to pfSense. So far I'm impressed with pfSense (which I had only used sporadically and for simplest setups), but I'm struggling with one use case they are not willing to give up.
They manage a good number of IPSec tunnels with a lot of business partners and they provide mobile IPSec access to a restricted set of authorised operators who need connecting to any configured remote IPSec network. To simplify the description of the use case, let's just think of a single IPSec tunnel with a Phase 2 rule entry giving allowing traffic from a local network to a remote one:
Local | Remote ---------------+------------- 192.168.0.0/24 | 10.0.0.0/24Now the problem: the appliances they are currently using allow them to offer mobile VPN clients a subset of addresses in the same subnet (192.168.0.0/24) so as to automatically allow them to use the configured remote networks (10.0.0.0/24), as if they were located in the office:
192.168.0.0/24 (e.g.: office, from .1 to .200) ------------(IPSec Tunnel)---> 10.0.0.0/24 ^ 192.168.0.0/24 (e.g.: mobile, from .201 to .250) ---|I've tried to replicate this use case with pfSense but I had no success. I bought a Gold Membership in order to have access to the pfSense Book, but it didn't help with this use case. In fact, I'm not sure it's even possible.
I guess I could add the network assigned to mobile clients as a new phase 2 entry in each IPSec tunnel (I haven't tried, though, and I'd appreciate a confirmation), but users are not happy with this idea: on the one hand, it adds management complexity in case the mobile users' network changes for any reason, and on the other hand it forces them to communicate the existence of two distinct networks to the remote party (something they're not happy with).
I'd be really glad for any suggestion on how to solve this problem, or to support this use case another way I have not considered.
Regards,
–
Enrico -
I have little experience, but could you connect the two 192.168.x.x networks together? Otherwise, you could use a /25 instead of a /24.
In theory, a subnet is a broadcast domain. Having the same subnet in two different broadcast domains is a horrible idea.
-
192.168.0.0/24 (e.g.: office, from .1 to .200) ------------(IPSec Tunnel)---> 10.0.0.0/24 ^ 192.168.0.0/24 (e.g.: mobile, from .201 to .250) ---|Do the mobile users on .201 to .250 also expect access to .1 to .200 as if they're local (meaning on the same broadcast domain) or just layer 3 access to 10.0.0.0/24 ??
-
I have little experience, but could you connect the two 192.168.x.x networks together? Otherwise, you could use a /25 instead of a /24.
In theory, a subnet is a broadcast domain. Having the same subnet in two different broadcast domains is a horrible idea.
Hi Harvy66,
Thank you very much. I tried assigning a smaller network to mobile VPN clients but it didn't work. In fact, if I remember correctly, assigning IPs in a 192.168.0.0/x network (where x is greater than 24 and making sure no IP would overlap with existing IPs in 192.168.0.0/24) resulted in the VPN tunnel establishing, but no traffic flowing (not even to the list of available network, such as 192.168.0.0/24 itself).
-
192.168.0.0/24 (e.g.: office, from .1 to .200) ------------(IPSec Tunnel)---> 10.0.0.0/24 ^ 192.168.0.0/24 (e.g.: mobile, from .201 to .250) ---|Do the mobile users on .201 to .250 also expect access to .1 to .200 as if they're local (meaning on the same broadcast domain) or just layer 3 access to 10.0.0.0/24 ??
Hi Derelict,
Sorry for the belated reply.
According to the current situation with the existing appliance, mobile users in the [.201, 250] range have access to [.1, .200]. I don't think they use it, in reality, since mobile users are interested in getting access to VPN remote networks (such as 10.0.0.0/24) but if you ask, I think they might expect it.
Thank you and regards,
–
Enrico -
I'm bumping this thread since it seems that it's quickly fallen into oblivion.
Is there anybody able to confirm the viability of this scenario?
-
This is probably a use case for our support.
There are ways to acomplish this with pfsense.
One is radius the other is not yet bundled into pfsense.On 2.2 there is a possibility to use dhcp plugin to talk to a dhcp server to seggregate this.
Or move the pool management to a DB. -
@ermal:
This is probably a use case for our support.
There are ways to acomplish this with pfsense.
One is radius the other is not yet bundled into pfsense.On 2.2 there is a possibility to use dhcp plugin to talk to a dhcp server to seggregate this.
Or move the pool management to a DB.Thanks ermal,
I'm certainly willing to do that.
Since I'm not eager to introduce RADIUS and since others here may not buy something not yet bundled into pfSense, I'd like to have a complete picture and choose the "best" solution here.
The other alternative I considered was adding the virtual network assigned to mobile users, let's say 192.168.32.0/24 and add a Phase-2 entry for this "local" network to every tunnel that I want to be reachable. Unfortunately, I couldn't get this to work either. Do you think this case, too, would need some kind of workaround or is it doable with "stock" pfSense? I'm asking this before contacting support just to make a single inquiry.
Thanks for your support guys.
-
By re-reading again your request i think this is your solution https://wiki.strongswan.org/projects/strongswan/wiki/Farpplugin.
So that plugin and the dhcp one to assign addresses.The dhcp plugin and farp are not presently bundled into pfSense but they are just libraries to add to the proper path.
-
Thank you very much ermal, it seems the farp plugin would enable both scenarios I'm considering and it would explain why phase 2 entries for the virtual network assigned to mobile clients do not work as I was expecting.
