Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3266 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.
  • 0
    Stanislav - several random thoughts.  RED doesn't need public IPs.  Both IPsec and routing should work as well as RED for what you want.  NAT doesn't seem necessary.

    Why are these subnets unroutable over MPLS?  Are the UTMs in routable subnets?

    Cheers - Bob
  • 0
    Dear Bob, 

    thank you for your prompt reply. I propose to disqualify NAT (overkill) and RED (nobody will pay for that in this time regardless of the fact you told me yesterday). 

    These subnets are unroutable due to organizational reasons. There are few /24 unroutable networks hidden behind A107's and A105's UTM. The UTM's MPLS interfaces are in routable subnet and whole MPLS cloud is aware of these interfaces. 

    Let's think about the IPsec solution further. Okay, IPsec tunnel is established on both sites and local and remote networks have been defined on both sites. Let's say these are our unroutable networks: 


    • A107 - 192.168.255.0/24
    • A105 - 192.168.254.0/24


    IPsec tunnel A107's site says: 

    • 1) Local network: 192.168.255.0/24 (Sophos requests it when creating IPsec tunnel)
    • 2) Remote network: 192.168.254.0/24
    • 3) Source tunnel interface: the one in MPLS network
    • 4) Destination address: A105's MPLS interface.


    Question is: what happens if we access the remote 192.168.254.1 address with following source address: 172.25.181.150 ? In my humble opinion, it won't go through the tunnel because source address differs from the address written in 1st bullet in the list above despite of the fact that the "strict routing" feature is disabled...
  • 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.
  • 0
    Good morning dear BAlfson, 

    sorry for the delay I'm replying you with. We were under heavy load of of other tasks, we therefore didn't proceed with the issue described in my 1st post. 

    Anyway, we were able to successfully establish the connection with your precious advices. However, there was one small change compared to your suggestions. We created two tunnels, but these tunnels were between [routable A105][unroutable A107] && [unroutable A105][routable A107]. 

    Thank you for your effort and help. 

    Have a nice day. 
    Stan