Ways to segregate IPSEC VPN clients with subnets

VPN
1

EDIT: Specifying the IKE Peer ID worked to get all the tunnels working on the same interface. Thanks for the advice everyone!

I am new to Fortinet and currently trialing a VM appliance before we move forward with replacing our ASA with a FortiGate. I’ve been reading a lot of resources on what our options are for client VPN and it feels like IPSEC client VPNs are the way to go for security due to all the SSL VPN vulnerabilities. It also seems like Fortinet itself is discouraging the SSL VPN in newer firmware.

Want I want to implement is a 3 tier VPN solution as follows:

  • IT VPN
    • VPN client gets IP in IT VPN subnet and has policies for effectively unrestricted internal access
    • Uses SAML auth to allow only trusted devices + user auth + 2FA
  • General Employee VPN
    • VPN client gets IP in employee VPN subnet and group-based access policies
    • Uses similar SAML auth policy as IT
  • Contractor VPN
    • VPN client gets IP in contractor subnet with policies providing bare-minimum required access
    • Also uses SAML auth, but without device verification

I have done a POC and have each VPN tier auth + policies working with IPSEC to my satisfaction with Duo as the SAML IdP, but so far I haven’t found an ideal solution to implement all 3 tunnels at once. These are my options as I understand it:

  1. Configure mutually exclusive IKEv1/2 cipher suites on each tunnel to force negotiation to the correct tunnel. (Seems clunky and not ideal)
  2. Map each IPSEC tunnel to a different VIP that NAT to external IPs. (Doable, but I’d rather not waste our limited external IPs on this)
  3. Switch to RADIUS auth and assign IPs through RADIUS response. (SAML auth is a better user experience and easier to configure so not considering this a good option)

Am I missing any better way to implement the VPN tiers we want to have? I don’t want to combine any VPN tunnels and lose the subnet segregation as it removes our ability to do any subnet based filtering/reporting downstream from the firewall.

Is there any indication Fortinet is going to implement group based IPSEC client IP address assignment down the road?

2

I think you can use peerid and localid to steer users to different IPsec dialup tunnels: Technical Tip: Use of PeerID and LocalID in IPsec ... - Fortinet Community

For example, your “IT VPN” tunnel is configured with peerid ‘IT-VPN’ on the Fortigate. The VPN client then set localid ‘IT-VPN’ to tell the Fortigate which tunnel it wants to connect to.

I see that my Forticlient VPN has the “localid” setting under “Remote Access” > hamburger icon > “Add a new connection” > “IPsec VPN” > Advanced Options > VPN Settings > Phase 1 > Local ID

I hope it can help you solve your problem.

3

Do you need the IP based differentiation? If you can drop it, you can keep SAML, merge everything into one tunnel/phase1, and authorize access to different destinations with group-based firewall policies.

4

We are in the process of adding this. Works great. Different peer id takes care of it. We have a different IP pool and the VPN becomes an interface in the policies so you can set rules right there as to where they can go.
I think the key was you have to set the Specific Peer Id as the Accept Types so that it will patch that to the right selector. Before that it was hitting another and the different PSK was failing out.

5

You can differentiate with local ids

6

Set up different IPsec tunnels with different encryption algorithms and PSKs. Then you can sign different IP addresses to the clients (I think with “mode-cfg” set to “on”).
That’s how one of my customers is set up and it works very well.
My preferred solution, if you have FortiClient, is to use FSSOMA (in conjunction with a FortiAuthenticator) and have all clients use the same IP subnet but steering access to resources via FSSO.

7

Came across this as had a client that had a need for multiple Dial Up Remote Access IPSec VPNs. Strange issue I am having is that my Windows 10 22H2 Hyper-V VM I use as my daily driver gets a weird 0.0.0.0/0 route written to the routing table after it successfully connects to either of my updated RA VPNs. However it breaks my local, internet, and vpn connections.

    IPv4 Route Table
    ===========================================================================
    Active Routes:

    Network Destination        Netmask          Gateway       Interface  Metric

    0.0.0.0          0.0.0.0     192.168.20.1    192.168.20.25     25
    (vpn) 0.0.0.0          0.0.0.0      192.168.2.8      192.168.2.7     25

However on fresh VMs of both Windows 10 and 11 this 2nd route 0.0.0.0/0 is not written and everything is working as expected. Oddly too…prior to me converting this RA IPSec VPN tunnel to custom and adding a Peer ID to the requirements, I was not having this issue.

I did recently upgrade FortiClient to 7.4.0.1658 so will just reinstall.

Edit - Uninstall, reboot, reinstall, reboot stopped the 0.0.0.0/0 from being written to the routing table erroneously. Now VPN works as intended.

8

Thanks I haven’t tried this yet. I’ll give it a shot. I thought I read somewhere the peer ID used was the username so I didn’t play around with it.

9

Yes, we have multiple systems using subnet based rules beyond the firewall so we would lose a lot of security:

  • IP based restrictions on access to web admin URLs on hosts that also have user front end on same port
  • Network traffic volume alerting based on subnet
  • IDS behavior monitoring based on subnet

I also think the firewall policies would be a lot cleaner and less prone to admin misconfiguration if each tier has a unique source interface.

10

Yep. This is a pure testing box so I am on newest 7.6.0 to get a feel for all available features, not sure if that matters. I am using IKE v1 tunnels with same ciphers and PSK, but different Peer ID. Then I configured the Local ID on the Fortinet client with the instructions Golle provided.

So far when I configured Local ID on the client side I have only ever had it match to the correct VPN tunnel with the corresponding Peer ID.

Make sure your IKE phase 1/2 ciphers and key life match between the Fortigate and Forticlient. Not sure if this is just me tinkering too much and getting used to it but I’ve had a couple times where the key life in particular didn’t match when I don’t think I had changed from defaults.

11

Thanks for saying thanks! It’s so nice to see Redditors being grateful :slight_smile:

12

Yes I am only using IKEv1 currently with SAML auth and the Peer IDs. I haven’t been able to get it working with IKEv2 for reasons I haven’t figured out yet. I thought it had to do with the lack of XAUTH from searching online initially, but I see there are IKEv2 guides for SAML auth now so I’m not sure what I’m missing to make IKEv2 work.

13

IKEv2 does not use peer ID and XAuth framework so you need to enable EAP authentication and use Radius server. EAP is CLI only config for now. You can see a guide here.