R80.10 IPSEC with DAIP mobile routers as interop devices, problem with dynamic IP reassignment on daip devices

[Raine_Widjeskog]

Hi,

I'm having an issue where it seems that when the same ip gets assigned first to daip peer a and then afterwards to DAIP peer b, the check point still "remembers" daip peer a and gives an auth fail on the ipsec negotiation. The funny thing is that the IP-interop device connection seems to reside in some cache even if you delete all ike+ipsec SAs for the peer through vpn tu. It also seems that vpn tu is not always successful in deleting the SAs even if i command it multiple times, so I wonder if that's the issue or if someone has stumbled upon the same problem before? It kinda sucks if you need to wait for the ipsec phase 1 to timeout in order to be able to get connected again on a new device with an old IP.

Any help appreciated

[PhoneBoy]

My guess is that you will need to remove an entry from one of the table listed here: ATRG: VPN Core 

[Raine_Widjeskog]

Yes you are right, this seems to be where it is taking the infrmation from. Regardless it seems odd that it can't update the information. It takes over the old IP-to-DAG just fine and authenticates properly if i temporarily switch over to IKEv1 from IKEv2. Logs from vpnd.elg show that the [AU] process (auth user?) seems to be doing a lot more checking up if using IKEv1 and this triggers the update as it probably should be doing. On IKEv2 the [AU] process simply states the Peer certificate does not conform to matching criteria and gives up.

[PhoneBoy]

Curious how often you encounter this behavior?

[Raine_Widjeskog]

Quite often, I can replicate it easily all the time. It may have something to do with the DAIP peers getting IP addresses from two different pools too (I am stumbling upon this as I am configuring/testing connection failover on the mobile routers - alternating between conn 1 and conn 2). But pretty much on every router i configure/test I can replicate it when the next to be configured gets the old IP of the previous one. It doesn't quite always happend though (sometimes it happends on conn 1, but seemingly always on conn 2), which still puzzles me a little bit. But as mentioned, it is probably related to the DAIP peer having 2 different addresses that may change and the dynamic between the changing connections/IPs.

[Raine_Widjeskog]

Here are the relevant vpnd.elg logs from the [AU] process which i think is central to the issue, i think the key issue is that with ikev1 "ike_fetch_user" gets triggered (as it probably should?) whereas with ikev2 it does not :

With IKEv1 :

[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10][AU] CAuthCertRules::GetUsernameFromCert (0xe82f7ab0): Extracted username from cert: CN=xyz,OU=users,O=MGMT..ctwkvh
[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10] ike_fetch_user: Entering.
--snip-
[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10] fetch_user_with_sr_info: requesting au_realm_fetchuser with groups
--snip-
[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10] free_fetch_user_with_sr_info_opaque: Entering
[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10] FwIkeP1FetchDaip: entering
[vpnd 5963 4101797776]@FW1[3 Jan 15:26:10] FwIkeP1FetchDaip: Identified DAG: 'Device_10.x.x.177' <-- The correct device is found and later changed in the tables with separate functions as indicated by logs

With IKEv2 :

[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][AU] CAuthCertRules::GetUsernameFromCert (0xe82f7ab0): Extracted username from cert: CN=xxx,OU=users,O=MGMT..ctwkvh
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43] fwCert_MatchAndSortCertsForVal: Peer certificate does not conform to matching criteria
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] ikeAuthExchange_r::validateCertPayload: validateCertificates returned -2
--snip-
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] ikeAuthExchange_r::validateCertPayload: validating cert payload failed.
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] Exchange::processPayloads: problem processing payload no. 2 of type Cert payload
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] Exchange::processPayloads: processPayloads returning initial status
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] ikeAuthExchange_r::postValiadatePayloads: enter with res = -4
[vpnd 5963 4101797776]@FW1[3 Jan 16:08:43][ikev2] Exchange::setStatus: Changing status from: initial to: doomed (final).. <-- the lookups are never done and the checkpoint replies with an AUTH FAIL

[PhoneBoy]

I recommend opening a TAC case on this so we can dig into this issue further.