Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3269 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

site-to-site VPN with specific requirements and conditions

szcz7977
Good afternoon dear Sophos Wizards, 

we've been trying to configure an site2site IPSec VPN with some specific requirements but we can't figure it on our own. Lets drill down into deeper details. 

Let's summarize the basic facts (attached picture will help): 


  • We have two branches, let's say A107 and A105 (internal branch coding, not relevant)
  • These two branches have connectivity with all the other branches via MPLS. These branches have their own Internet connectivity as well. 
  • A107 and A105 have few subnets which aren't routable neither via MPLS nor WAN, they also have few subnets routable via MPLS as well
  • Each depicted branch would like to access the "unroutable" subnets of the other branch (i.e. A107 would like to access unroutable subnets in A105 & vice versa). Source address would be from MPLS routable subnet of one branch and the destination subnet would be in unroutable subnet of the other plant. 
  • MPLS interfaces of the UTMs of both branches can see each other through ICMP, TCP and UDP
  • No firewall rules are defined from A105's MPLS interface to A107's MPLS interface and vice versa
  • All the routable subnets between A105, A107 and moreover all the other plants are routed via MPLS, nothing is routed via WAN.

Most important question is:
How can we achieve the state when administrators from one branch can access the unroutable subnets located in the other branch from routable subnets and vice versa? 

We were thinking about various soulutions of this situation. Let's summarize our outcomes

  • RED isn't suitable for us, it needs public IPs to work and we'd like to route traffic to unroutable subnets via MPLS. However, RED would make the unroutable subnets "visible" in between these two branches and only in between these to branches (that is what we want to achieve). What a pity we can't use it. 
  • NAT - after deeper thoughts, we had to disapprove this solution as well. Let's explain why: We can imagine there would be PAT rules going to devices in unroutable subnets on each branch's UTM. These PAT rules would be located in MPLS interface of each UTM. When we wan't to establish connection from MPLS routable subnet in one branch to MPLS unroutable subnet in the other branch, the first TCP segment (with SYN) abides to PAT rules. The reply (ACK+SYN), though, is routed according to routing table and since the source address (the one sending ACK+SYN) isn't routable in MPLS, the last ACK (going back to unroutable subnet from the routable one) never goes through.
  • IPSec tunnel - we defined and successfully established IPSec between A107's and A105's UTMs. We explicitly said the unroutable subnets are reachable through this tunnel (on each side, remote unroutable and local - from MPLS's point of view - unroutable subnets were defined). Problem was, we couldn't get from one branch (from MPLS routable subnet) to the other (to MPLS unroutable) subnet. The routing table told us there were two routes to this unroutable subnet (one through IPSec tunnel with no next hop, U flag and metric:0, the other through MPLS next hop - this was formerly defined with regards to some former experiments). We therefore couldn't be 100% sure that the traffic going back and forth is IPSec encapsulated and. The traffic going from MPLS routable subnet to MPLS unroutable subnet in the other branch was dropped in the begining on local UTM (iti didn't get through the MPLS).


I hope I precisely described our current situation (each branch has unroutable subnets) and the desired outcome (we wan't to access these subnets through MPLS mutually). If you need further info I'm eager to provide it and I'm looking forward to hearing from all of you.

Best regards, 
Stanislav Zitta


This thread was automatically locked due to age.
Parents
  • 0
    Let me restate this in my own way, Stanislav, so you can tell me if I've understood.

    {192.168.254.0/24}--------{192.168.255.0/24}

    If that's the case, why not two gateway routes:

    In UTM A105, {192.168.255.0/24}->10.0.255.1
    In UTM A107, {192.168.254.0/24}->10.0.254.1


    The MPLS provider might need similar routes, but I don't understand why that should be a problem.  If there's a conflict in the MPLS network, then IPsec between the two UTMs is the preferred solution.

    If 172.25.181.150 is an IP on a subnet defined on an Interface connected to the UTM, just leave 'Strict routing' disabled and move the traffic into the tunnel with an SNAT from 192.168.255.1 (select 'Rule applies to IPsec packets' in the 'Advanced' section of the SNAT).

    However, it would be my preference to make two tunnels.  One would share all unroutable subnets in A105 with all of the subnets in A107.  The second would share all unroutable subnets in A107 with all of the routable subnets in A105.

    IPsec with AES 128 PFS is normally the fastest solution.  If your processors have AES-NI, clone AES 128 PFS and select 'IPsec encryption algorithm: AES 128 GCM (96 bit)'.

    Cheers - Bob
    PS The same subscription that lets you make IPsec VPNs would also let you make a RED tunnel between two UTMs.  I prefer to use such RED tunnels only where I need IPs in the same subnet on both sides of the tunnel.
Reply
  • 0
    Let me restate this in my own way, Stanislav, so you can tell me if I've understood.

    {192.168.254.0/24}--------{192.168.255.0/24}

    If that's the case, why not two gateway routes:

    In UTM A105, {192.168.255.0/24}->10.0.255.1
    In UTM A107, {192.168.254.0/24}->10.0.254.1


    The MPLS provider might need similar routes, but I don't understand why that should be a problem.  If there's a conflict in the MPLS network, then IPsec between the two UTMs is the preferred solution.

    If 172.25.181.150 is an IP on a subnet defined on an Interface connected to the UTM, just leave 'Strict routing' disabled and move the traffic into the tunnel with an SNAT from 192.168.255.1 (select 'Rule applies to IPsec packets' in the 'Advanced' section of the SNAT).

    However, it would be my preference to make two tunnels.  One would share all unroutable subnets in A105 with all of the subnets in A107.  The second would share all unroutable subnets in A107 with all of the routable subnets in A105.

    IPsec with AES 128 PFS is normally the fastest solution.  If your processors have AES-NI, clone AES 128 PFS and select 'IPsec encryption algorithm: AES 128 GCM (96 bit)'.

    Cheers - Bob
    PS The same subscription that lets you make IPsec VPNs would also let you make a RED tunnel between two UTMs.  I prefer to use such RED tunnels only where I need IPs in the same subnet on both sides of the tunnel.
Children
No Data