Peer ID being ignored on IPSEC vpns

[ForgetItNet]

Hi all,

I've not used Peer id's in the past but I have 2 IPSEC tunnels for dial in users and they both listen on the same interface, the first one is TunnelA and then second one (below it in the list) is TunnelB so my understanding is that I can set PEER ID's on the tunnels and then specify the local id on the client and it will only connect to that tunnel that matches so I've got TunnelA and TunnelB and in the "Authentication" bit on the FortiGate side for both of these tunnels in the "Peer ID" section I've put TunnelA on TunnelA and TunnelB in TunnelB. I've also specified the same in the "local ID" in the Phase 1 Proposal bit on the FortiGate tunnels. Then on the FortiClient endpoint I've specified TunnelB in the "local id" under Phase1 so I thought this should then try to connect but only to TunnelB however it's not connecting but on our FortiAnalyzer it's showing the endpoint is trying to connect to TunnelA but then nothing after that ? i.e. I would've thought I would either see it try and connect to TunnelA, fail and then try TunnelB or just show as trying to connect to TunnelB straight off ?

Anything else I need to do or am missing ?

Thanks

[Yurisk]

Hi, from description of it looks like you did all correct. Just to make sure dial-up config for IKEv1 with peer id set:

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

When doing debug dia deb app ike -1 / dia deb enable you are supposed to see client only matching the IPSec tunnel with the correct peer ID, no matter how up or low in the rule base it is located, provided you only have IPSec tunnels with peer id set, no other tunnel(s) w/o peer id, as they would match ANY  peer id.

[ForgetItNet]

Thanks, I've re-done it again as per your guide but getting the same result but the debug shows this:

ike V=root:0:ca70ebe6d976ebd8/0000000000000000:604: SA proposal chosen, matched gateway TUNNELA

So it's still matching with the wrong one. I've also double checked that the PEER ID on the tunnels on the FortiGate are set to TUNNELB on the one I "want" to connect to and the other one is TUNNELA and the Peer ID on the endpoint is set correctly?

One thing I've just tested though is that I've pointed TUNNELA to a non-working port (to see if it'll bypass it) and it still fails but the debug shows:

ike V=root:0:TUNNELB: ignoring IKEv2 request, no policy configured

but the settings on the endpoint match the tunnel so I'm not sure whether this test "should" work or it's indicative of any setting I've potentially got wrong ?

[dingjerry_FTNT]

Again:

1) Did you configure both tunnels as "Aggressive mode"?

2) "ike V=root:0:TUNNELB: ignoring IKEv2 request, no policy configured"

This message indicates that you have no firewall policies configured for this tunnel.

If possible, please share your FGT config or, at least, the VPN tunnels configure (including the firewall policies).   You may remove or mask any sensitive info.

[dingjerry_FTNT]

Hi @ForgetItNet ,

1) No need to configure "local ID" for the IPSec VPN on FGT;

2) Make sure that you are using "aggressive mode" for both IPSec VPN tunnels.

If you still have the issue, please:

1) Provide your FGT config, or at least, the IPSec VPN tunnels config.  You may remove or mask any sensitive settings.

2) Collect the IKE debug on FGT:

diag debug app ike -1

diag debug enable

Then reproduce this issue again on the client.

[ForgetItNet]

So putting the config onto notepad I realised I missed a couple of things which helped so I've sorted those (including the firewall) and now the FortiAnalyzer shows the connection starting off as TUNNELA (as before) and with Phase 1 successful but then showing TUNNELA where Phase 1 fails. This is my current config and I'll put the debug logs below that in a separate reply.

FG # show vpn ipsec phase1-interface
config vpn ipsec phase1-interface

edit "TUNNELA"
set type dynamic
set interface "port20"
set ike-version 2
set peertype one
set net-device disable
set mode-cfg enable
set proposal aes256-sha256
set dpd on-idle
set dhgrp 18
set eap enable
set eap-identity send-request
set authusrgrp "SSO"
set peerid "TUNNELA"
set ipv4-start-ip 192.168.22.100
set ipv4-end-ip 192.168.22.150
set ipv4-netmask 255.255.254.0
set dns-mode auto
set ipv4-split-include "Data"
set save-password enable
set psksecret ENC A9A2+LtPoy9IFvSI+RTuMtU8OYWNLEQNpXzmt+k8EKh8Io6KoNuStSMsea5GJiKYGvXSX8F9I/VQ2N5XsS1CCM0iuJumin01Q6wBPBRPqriqQfx823db3un0Cr7nJWj0w8poIbK5SDMZ
tH3I93RiIYquYsTauiaxKZWmA+MG5zqEsIbjAGVcbsI/lXzLCid6QMVdmllmMjY3dkVA
set dpd-retryinterval 60
next
edit "TUNNELB"
set type dynamic
set interface "port20"
set ike-version 2
set peertype one
set net-device disable
set mode-cfg enable
set proposal aes256-sha256
set dpd on-idle
set dhgrp 18
set eap enable
set eap-identity send-request
set authusrgrp "LDAP"
set peerid "TUNNELB"
set ipv4-start-ip 192.168.22.160
set ipv4-end-ip 192.168.22.220
set ipv4-netmask 255.255.254.0
set dns-mode auto
set ipv4-split-include "Data"
set psksecret ENC D2GocGQRZNLqXvrqx8VvaTXwSaQS6FIsf9B3Q5flAwPb8fMag4QDRNVaaz/zd4n5NCOZzvtNQgBfOFKQy/V/VijgKFMVn9p2wkxIO4bMLIMaN4tOxumjDiF8MuDgdzVZVy9kIWp0q9d8
yffIFCeOTu2oMMihYnMp0E+7aaTqaS3ZawGddpVfhwgPWj6gy1pTKE5em1lmMjY3dkVA
set dpd-retryinterval 60
next
end
FG # show vpn ipsec phase2-interface
config vpn ipsec phase2-interface

edit "TUNNELA"
set phase1name "TUNNELA"
set proposal aes256-sha256
set dhgrp 18
next
edit "TUNNELB"
set phase1name "TUNNELB"
set proposal aes256-sha256
set dhgrp 18
next
end

[ForgetItNet]

Ok, so I've setup a new local user and amended TUNNELB to use that group and it does work fine, it also ONLY tries to connect to TUNNELB but I've got SSO and EAP on TUNNELA so it looks like this might be overriding it somehow as I had set TUNNELB to an LDAP group so it doesn't seem to be passing it through (which I think I might've seen someone else mention relating to a pre-shared key and LDAP) so I'll focus on that but at least I know then VPN itself is ok and it's something to do with the authentication... Thanks

[ForgetItNet]

Got it working but had to setup a Radius server (which is fine) and it does still show as it's connecting to TUNNELA first (with Phase1 success) and then TUNNELB at which point it connects so I'm not sure if that's normal but it's confused things for me trying to figure it out. Thanks both for the input as it's guided me to a resolution.

[dingjerry_FTNT]

Do you have to use IKEv2? 

For IKEv2, my understanding is that the FGT will try to match the tunnel from top to bottom in the IKE_SA_INIT phase. 

The Peer ID info is in the next phase, called IKE_AUTH.  

For IKEv1, the peer ID info is in the very first message. So if the phase1 settings have "aggressive mode" (available in IKEv1 only, not in IKEv2) configured, it will check the peer ID first to match the tunnel.