VPN Encryption Issues with tunnel to Azure

[T_Sonnberger]

Dear CPUG,

I have a strange issue with a tunnel to Azure.

The tunnel is up and running and we have routed two networks to Azure successfully for a long time. Now I have added a third network to the encryption domain to extend the remote range.

For this new network, I can't get a working connection...

Within Smart Log, I see that it is routed into the correct VPN community and is encrypted the same way, as the working networks.

However, for SSH traffic, I do not see any drops in Smart Log and for ICPM I see:

Encryption/Decryption failure, failed to resolve SA (VPN Error code 01)

I have applied sk122532 with no success...

fw ctl zdebug + drop shows me different reasons, why it's blocked:

@;452435048;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=6 s.s.s.s:1034 -> d.d.d.d:22 dropped by fwmultik_process_f2p_cookie_inner Reason: fwmultik_f2p_cookie_outbound_and_routing failed;
@;452460291;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=1 s.s.s.s:2048 -> d.d.d.d:13732 dropped by chain_ipsec_methods_ok Reason: vpn_decrypt_methods_ok failed;

Which brought me to: sk167953 - but then I wonder, why it is working for the other two subnets in the encryption domain.

Looking on a fw monitor:

[vs_0][fw_2] eth1-01:i[44]: s.s.s.s-> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000
[vs_0][fw_2] eth1-01:I[44]: s.s.s.s -> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000
[vs_0][fw_2] eth1-01:o[44]: s.s.s.s -> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000
[vs_0][fw_2] eth1-01:O[44]: s.s.s.s -> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000
[vs_0][fw_0] eth1-01:Oe[44]: s.s.s.s -> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000
[vs_0][fw_2] eth1-03:i[44]: s.s.s.s -> d.d.d.d (TCP) len=52 id=10707
TCP: 31479 -> 22 .S.... seq=d355f30b ack=00000000

It apprears to exit the physical internet interface (eth1-03) while I do not see this, for working connections?

Do you have any ideas, what to check? Might it be a routing issue on Azures end?

Any hint would be highly appreaciated! Thanks in advance!

BR,

Thomas

[T_Sonnberger]

P.s. We are running R80.30 Take 200

Restarting the tunnel did not make any changes.

BR,

Thomas

[PhoneBoy]

No idea, but it seems like the next step would be to apply a later JHF as suggested by the SK.

[T_Sonnberger]

Just a quick update:

Applying the Hotfix did not solve the issue. After further reviewing with our Azure Team, we figured out a misconfiguration of the routing table in Azure, so the encryption domains did not match. 

After fixing this, we see at least no further drops but it's still not working. Although, I guess it's not related to our Checkpoint configuration, as no issues can be seen now.

Thanks for your support though!