ipsec vpn with UTM not passing traffic

Mast_01 This can be due to a few reasons. Best to start by checking for dropped traffic. On the UTM, you can check the firewall log for dropped traffic. On the XG, you can use "drppkt | grep <ip address>"

on the UTM there's no dropped traffic from either side of the tunnel, it's as if there's nothing there.

on the XG side, if i'm telling you that in the firewall log i see the hit of the rule, then why would there be dropped packets?.

where do i put that command?, that's not a console command

Mast_01,

can you try the method 2 from this KB?

https://community.sophos.com/kb/en-us/123334

Thanks

Luk,

following a BUG from 2015 i had to change the policy to "defaultbranchoffice" which is insanely insecure for 2017 (MD5 hashes, aes 128, not even sha1...) and it worked, i've seen threads reporting this problem since 2015... this is appallingly terrible.

Can you post the policy configuration that you HAD on the UTM and the XG and I'll test it.

David,

on the UTM side the policy is:

on the XG side:

Allow Re-keying ON, key retries 3

phase 1: group 5 (DH1536), DPD, 28800 life

re-key margin 120s, 0% randomization, 30s check peer, 120s timeout, re-initiate connection

phase 2: PFS group 2 (DH1024), 28800 life

have you managed to test it?

Hi, do you have any static routs and also make sure on XG side the LAN to VPN and VPN to LAN rules are on top

no static routes, the FW rules are on top.

besides, if it where a route or rule problem, simply changing the tunnel encryption parameters should not affect it

Yes I've tested this and saw the same behaviour that you saw. Without going into too much technical information, the issue you're seeing is caused by an algorithm mis-match. If you change the IPSEC authentication algorithm on the UTM from "SHA2-256" to "SHA2-256 (96 Bit)", that will work. Or you can also choose to drop to "SHA-1". On a side note, setting the key lifetime of phase1 and phase2 to the same value is not considered best practice. It's probably best to have the phase2 key lifetime to be shorter than that of phase1.

David,

if there's an algorithm mismatch, shouldn't the connection not establish at all?.

why isn't it a best practice?(or putting it differently: what's wrong that the two keys expire at the same time?, let's say i put phase2 shorter, it will at some point expire at the same time)

Thank you, this fixed our problem when connecting a Sophos XG to a Cyberoam.  Had to clone the default head policy and check "SHA2 with 96-bit truncation"

Thank you, this fixed our problem when connecting a Sophos XG to a Cyberoam.  Had to clone the default head policy and check "SHA2 with 96-bit truncation"