Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 8 subscribers
  • Views 1272 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

Question on how Sophos handles CIDR ranges for Remote Networks

Stephen Lynch

Hi there, 

We have a S2S VPN with a client, with a single remote network defined as 10.x.x.x/16

On occasion, the I can see in the IPSEC logs that the client is trying to establish the connection from 10.x.x.x/17

Sophos UTM 9 will not establish in this instance as there is no remote network defined as 10.x.x.x/17

The client is insisting that Sophos SHOULD accept the /17  as technically, it should be covered by the /16

Is there a setting somewhere that will allow this, or is there a reason why UTM 9 is so exacting about the CIDR range?

Thanks in advance

Steve 



This thread was automatically locked due to age.
  • +1

    Haigh Steve and welcome to the UTM Community!

    So, the client is trying to establish a connection where he has his local network as a /17, but you have him in 'Remote Networks' as a /16?  That won't work.

    The client has to decide what subnet he's using and configure his IPsec connection for that.  If he wants to be able to come from anywhere in the /16, then that's what he'll need to use.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • +1

    Both sides must offer a network and expect a network.
    These configurations MUST match the definition from the "other side"...


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0

    Thanks Bob & Dirk. 

    That's what I was thinking, but just wanted to confirm. 

  • 0

    Hi folks, 

    Sorry to revisit this, but a quick follow up question: 

    Is this standard practice across the VPN space or is this behaviour just specific to Sophos?

    i.e. that only the exact match in the remote networks will allow a connection, irrespective of whether the client subnet is technically within the CIDR range?

    I ask because with this particular client, I can add ANY IP to the IP sec remote gateways in Sophos so long as they are within in the 10.x.x.x/16 range and his side will accept the connection. 

    So I could add a new remote gateway to Sophos as 10.0.24.192/26 for example, and his side will accept, as this is within the 10.0.0.0/16 range. 

    However, Sophos doesn't allow this when it's coming the other way. 

    Hence the question: Is this standard practice across the VPN space or is this behaviour just specific to Sophos?

    I hope I'm making sense!

    Steve  

  • 0 in reply to Stephen Lynch

    ipsec "standard" is like a big shelf. Every vendor can put some features into it. Therefore, there are differences.
    So DPD is an "ad-on" with IKEv1 and vendor implementations are different.
    Some vendors accept only an exact network-match on both sides, otherwise there is completely no VPN connection.
    Some vendors allow a missing network-part at the "other" side. Then the missing part is simply not used (as I know it with Sophos).
    Other vendors allow every definition of networks within a range and send an OK every Time. (your observation)

    The "must match" is the most common requirement, and these connections mostly work.
    Connections like the ones you've observed tend to be rare and harder to understand or explain.
    The missing network match is the most common mistake, if a connection isn't established.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Unfiltered HTML