Multiple L2TP/IPsec VPN Servers in the same WAN

[damianhlozano]

Hello team!!!

I hope you are fine!!

We have here, 2 kind of VPN users trying to access different resources on different VLANs (Behind the same Fortigate), we need, for example, the following:

* User Group 1: Can access LAN but not DMZ

* User Group 2: Can access DMZ but not LAN

We have 3 WANs, the idea is create one VPN for each WAN.

We choose L2TP/IPsec VPN, because this dont require to install FortiClient in each Client.  All the test were done with L2TP/IPsec VPN (Using the option "Windows Native" in the wizard)

What we tried in first place, is to create 2 VPNs for each WAN, one for each user group (6 VPNs), but this seems that the Fortigate, only is listenning for one VPN in each WAN.

I deleted all the VPNs and references (Including addresses)

I created again the VPNs for each WAN, just for "User Group 1"

I could connect and access the network through the VPN, everything was fine

I added the 3 VPNs for "User Group 2" (1 for each WAN)

I coud NOT connect, wrong credentials

I added the same user to "User Group 2" and I could connect (Even removing the username from "User Group 1")

When I see the Fortigate, the user was connected to the VPN for "User Group 1", but it needed credentials inside "User Group 2".

So, I am thinking another aproach

I think maybe I could set static IPs for Clients in "User Group 2", and manage permissions in Firewall Policies to choose to which LAN can access each IP range.  But I dont like to set static IPs

Do you have a better idea?

Thanks in advance.

Regards,

Damián

[sw2090]

if you have more than one ipsec/L2tp on one wan you may have to limit each tunnel to one peer id to allow the FGT to find the correct one.

[Yurisk]

Not the answer you are looking for, sorry, but if you were to switch to the Forticlient on Windows stations (it is free for VPN), the set up would be much easier and will work without head aches:

Phase 1 Dial Up IPSec:

config vpn ipsec phase1-interface
    edit "Peer2P1"
        set type dynamic
        set interface "port1"
        set mode aggressive <-- To work behind NAT, set by default on FC
        set peertype one    <-- Here I switch from any to a single peer id
        set peerid "peer2"  <-- Only users with peer id of "peer2" will match
        set net-device disable
        set mode-cfg enable
        set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 3des-md5
        set dpd on-idle
        set xauthtype auto <-- Serve as xauth server
        set authusrgrp "yurisk1grp" <-- user group for this tunnel
        set ipv4-start-ip 192.168.102.0  <-- a different pool to assign to clients via mode-cfg
        set ipv4-end-ip 192.168.102.13
        set dns-mode auto
        set ipv4-split-include "LAN" <-- LAN is object for local network
        set save-password enable
        set psksecret ENC tENRv0SYBHFggtelPP==
        set dpd-retryinterval 60
    next
end

Phase 2:
config vpn ipsec phase2-interface
    edit "Peer2P2"
        set phase1name "Peer2P1"
        set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256
    next
end

Then it is a matter of putting specific to this group ID, here it is "peer2" in the FC:

Then you create a new IPSec tunnel for the next group etc.

[damianhlozano]

Thanks to both!!

@sw2090 , One peer is not an option, but I understand your point

@Yurisk , we use 2 lines of powershell codes to create VPN and routes, this is the easier and fastest way.  I used to use ipsec in previous versions, when L2TP VPNs does not work well with Fortigate, but when L2TP/ipsec is an option, we prefer this.  Thanks anyway for your answer.

I think I will create just 1 VPN per WAN, and manage user groups in the firewall policies.

Regards,

Damián

[pminarik]

IIRC the group membership doesn't "propagate to the firewall policies", so you won't be able to use group-based authorization in policies for L2TP clients.
(feel free to correct me if I turn out to be wrong :) ) 

My personal recommendation would be to go with IKEv2 IPsec instead, modern clients support it. (including natively in Windows 10+), you'll just have to juggle the configs a bit to get something that works for everyone. :)

[damianhlozano]

Thanks!!!

We have many Fortigates in different places, syncronizing with Active Directory and we use AD Groups or local groups (With AD users) in different firewall policies, so I think this should work.

I could try IKEv2 for next deployments, now we have a lot of clients configured with L2TP, because the previous VPN Server (Router Mikrotik) had L2TP configured

Regards,

Damián

[damianhlozano]

Hello!

I think you are right!

The group membership seems that doesn´t propagate to the firewall policies!

If I select an address object and a VPN user group in the firewall policy, when I try to access from a VPN client, no policy is matched and I cant access, if I remove the user group in the firewall policy, then the policy is matched.

I used active directory groups and local groups (pointing to AD groups) in firewall policies and this worked, but for L2TP/IPsec VPNs, I think that does not work.

So, local group authentication will work with IKEv2 VPNs?

Any other idea to make it work in Windows without forticlient?

Thanks in advance.

Regards,

Damián

[pminarik]

Yeah, it should work with IKEv2. If you leave the auth-group unset, it will accept groups from relevant firewall policies, and use this membership for granting access through those policies as well.

Using the MS Store-version of FortiClient might be an interesting compromise: It integrates into the native VPN Windows settings. Not sure how well it works nowadays, however...

[damianhlozano]

Thanks a lot!!

What do you mean with "leave the auth-group unset"?

Regards,

Damián

[pminarik]

In IKEv1 and IKEv2, there's two ways to specify who can authenticate:

1: Specify it in the phase1 config ("set authusrgrp xxx")

- Only this single group can authenticate

- The group membeship/identity does not "propagate" to the firewalling rules, so you can't use the same user/group in firewall policies.

2: Leave it unset in phase1 ("set authusrgrp" is empty), set groups in firewall policies

- All groups from relevant firewall policies (srcintf = the tunnel) are bundled together

- These groups are then allowed to authenticate and connect to the tunnel

- This information is then available in firewall policies and can control who accesses what