Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 41 subscribers
  • Views 10623 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VPN IPsec site to site between Sophos and Fortigate

Boris Brunel

Hello,

I have to create several site-to-site IPsec between Fortigate Firewall and our Head Office Sophos Firewall.
All connections must go to the same subnet in our Head Office.

I've configured the Sophos as "Respond Only", the subnets are configured, and the policies are enabled.
The problem is that the IPsec only works when using the wildcard * on the remote gateway. And when I do that, I can't use a different pre-shared key for the other connections. As soon as I try to use the public static address of the Fortigate as the remote Gateway, the connection stop and don't work anymore. 

The log say : "Traffic selectors don't match. Check the configured local and remote subnets on both devices"

But the local and remote subnet are the same as when using * and should be working, right?

So far, I have tried to use the local and remote ID on both firewall, and also to use the Sophos to initiate the connection without success.
What am I missing here?

Thanks



This thread was automatically locked due to age.
  • 0

    If you need to use * then you should upgrade your Sophos to v20 which supports multiple PSKs.

    If you cannot upgrade then you will need to use something like DynDNS to prevent having to use *

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0

    Hello  ,

    Thank you for reaching out to the community, can you please share the strongswan.log, refer logs.

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to Vivek Jagad

    Hi  , are these tunnels Policy based or Route based? which version you are using on SFOS? With Policy based IPsec, while using * in the remote gateway field, you have the option to use local-id/remote-id combo to differentia the incoming connection requests from multiple branch offices with a limitation that all such * based connections need to have same PSK; With route based IPsec, you may try out with 0.0.0.0 in remote gateway field along with local-id/remote-id combo (this is a kind of work around prior to v20 release;  * notation support for route based IPsec is available from v20 release onwards. It is always recommended to keep SFOS as Responder when this is your HO. To me, traffic selectors mismatch seem to be purely config mismatch of local and remote subnets on SFOS and Fortinet side.

  • 0 in reply to Vivek Jagad

    Hello,

    Here's what I have in the strongswan.log about the connection : 


    2024-01-10 13:08:44Z 21[NET] <IPSEC_to_CW-1|758157> received packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (544 bytes)
    2024-01-10 13:08:44Z 21[ENC] <IPSEC_to_CW-1|758157> parsed CREATE_CHILD_SA request 581 [ SA No KE TSi TSr ]
    2024-01-10 13:08:44Z 21[IKE] <IPSEC_to_CW-1|758157> traffic selectors 192.168.20.205/32 192.168.20.0/24 === 192.168.0.1/32 192.168.0.0/24 inacceptable
    2024-01-10 13:08:44Z 21[DMN] <IPSEC_to_CW-1|758157> [GARNER-LOGGING] (child_alert) ALERT: Traffic selectors don't match. Check the configured local and remote subnets on both devices: 192.168.0.1/32 192.168.0.0/24 === 192.168.20.205/32 192.168.20.0/24
    2024-01-10 13:08:44Z 21[IKE] <IPSEC_to_CW-1|758157> failed to establish CHILD_SA, keeping IKE_SA
    2024-01-10 13:08:44Z 21[ENC] <IPSEC_to_CW-1|758157> generating CREATE_CHILD_SA response 581 [ N(TS_UNACCEPT) ]
    2024-01-10 13:08:44Z 21[NET] <IPSEC_to_CW-1|758157> sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (96 bytes)

    Don't really know why there is /32 IPs in here, these are not indicated in the configuration

  • 0 in reply to Boris Brunel

    it looks like peer does not accept the crypto proposal and also double check the local/remote network shared on both the sides, can you re-configure the IPsec policy on both sides again and re-enable the IPsec tunnel ?

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to Vivek Jagad

    I've reconfigured from scratch using different encryption, but the same error appears. It works fine with the wildcard and not with the static IP. It doesn't seem very logical. I managed to make it work with local/remote ID as a workaround.

    It should be ok to use different key for all the connections, and as both  and suggest, I'll update to v20 when possible.

    Thank you very much for your help. 

Unfiltered HTML