Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 4294 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 Tunnels, Uplink Balancing, Multipath rules, oh my

Jayson
Howdy

We are adding (hopefully) a second WAN connection to the mix. The connection comes from a totally different provider, in this case CABLE. With that we have turned on UPLINK BALANCING and created a couple MULTIPATH RULES to route our WEB SURFING traffic and all is well, so we thought.

The problem is we have 2 site to site VPN tunnels in the mix. These tunnels go to external partners and were working flawlessly prior to turning on UPLINK BALANCING, to add more drama to the mix on one VPN tunnel we need to have various protocals running and the other has a WEB PORTAL

Needless to say this is adding some complexity to the mix I'm just not able to wrap my head around. 

I have checked out many of the simplar threads but I've been unable to find anything that outlines what we need to do.

Do any of you by chance have some insight in to setting something like this up? Maybe know of a document that outlines this setep? Or just have a great idea you want to share?

As always, thanks for any and all help...

-Jayson

Edit --

Reading that again I feel I should add some more info.

Whats working
Uplink Balancing is working
Routing Web Surfing traffic out to the new Cable line is working

Whats not working
VPN tunnels are connected BUT are no longer usable. eg no taffic of any sort seems to be getting to or from the target host/networks


This thread was automatically locked due to age.
  • 0
    The "trick" here is to use a Multipath rule with persistence by interface on the dual-WAN side and an 'Availability Group' on the other side.

    On the dual-WAN side, change the 'IPsec Connection' to have 'Local Interface: Uplink Interfaces'.  On the other side, in the 'Remote Gateway', into 'Gateway', put an 'Availability Group' that contains the IP favored by the Multipath rule first, and the other IP second.

    Say, you have a location with WAN-1 (11.21.31.41) and WAN-2 (62.72.82.92), your Multipath rule in that location would be:

    'Uplink Interfaces -> IPsec -> Any (or specific locations) : Persistence by Interface WAN-1'



    In the other location, the 'Availability Group' above would contain, in order, Host definitions for 11.21.31.41 and 62.72.82.92.

    Cheers - Bob
  • 0 in reply to BAlfson
    The "trick" here is to use a Multipath rule with persistence by interface on the dual-WAN side and an 'Availability Group' on the other side.

    On the dual-WAN side, change the 'IPsec Connection' to have 'Local Interface: Uplink Interfaces'.  On the other side, in the 'Remote Gateway', into 'Gateway', put an 'Availability Group' that contains the IP favored by the Multipath rule first, and the other IP second.

    Cheers - Bob


    The "OTHER IP" being the IP that currently resides in the REMOTE GATEWAY | GATEWAY box?
  • 0
    You're right, that's a bit unclear, so I've added an example to Post #2.

    Cheers - Bob
  • 0 in reply to BAlfson
    The "trick" here is to use a Multipath rule with persistence by interface on the dual-WAN side and an 'Availability Group' on the other side.

    On the dual-WAN side, change the 'IPsec Connection' to have 'Local Interface: Uplink Interfaces'.  On the other side, in the 'Remote Gateway', into 'Gateway', put an 'Availability Group' that contains the IP favored by the Multipath rule first, and the other IP second.

    Say, you have a location with WAN-1 (11.21.31.41) and WAN-2 (62.72.82.92), your Multipath rule in that location would be:

    'Uplink Interfaces -> IPsec -> Any (or specific locations) : Persistence by Interface WAN-1'



    In the other location, the 'Availability Group' above would contain, in order, Host definitions for 11.21.31.41 and 62.72.82.92.

    Cheers - Bob


    Ok let me clear up what I currently have. Chime in / edit what should be changed to make the above work.

    Interfaces (On my local ASG)
    WAN-1 = 222.111.000.123
    WAN-1 = 222.111.000.125 (second IP)
    WAN-2 = 222.111.000.124

    Uplink Balancing
    Active Interfaces
    WAN-1
    WAN-2

    Multipath Rules
    Internal-network01 -> any -> Various Nodes and Services -> WAN-1
    Internal-network01 -> any -> 111.222.000.1 -> WAN-1
    Internal-network01 -> Web Surfing -> ANY

    Site-to-Site
    IPSec Connection
    Name - VPN01
    Remote Gateway - VPN01 Peer
    Local Interface - Uplink (was WAN-1 second IP)  
    Policy - VPN01 Policy
    Local Networks - Internal-network01
    AFR - X
    SR - X

    IPSec Connection
    Name - VPN02
    Remote Gateway - VPN02 Peer
    Local Interface - Uplink (was WAN-1 second IP)
    Policy - VPN02 Policy
    Local Networks - Internal-network01
    AFR - X
    SR - X

    Remote Gateways
    Name - VPN01 Peer
    Gateway type - Initiate connection
    Gateway - Availability group (111.222.111.222) 
    Authentication type - X
    Key - X
    Repeat - X
    VPN IP type - IP Address
    VPN ID - [blank]
    Remote networks - 111.222.000.0 | 111.222.001.0

    Name - VPN02 Peer
    Gateway type - Initiate connection
    Gateway - Availability group (222.111.222.111) 
    Authentication type - X
    Key - X
    Repeat - X
    VPN IP type - IP Address
    VPN ID - [blank]
    Remote networks - 111.222.000.1

    Red - shows my confusion points
  • 0
    Keep in mind that we do not have administrative control of the remote side of the tunnel nor are the remote peers ASG appliances.  The WAN links (WAN-1 and WAN-2 are simply our connections to the internet.
     
    Also of note is that without uplink balancing enabled we are translating traffic on different external IP’s based on whether it is destined for the “internet” vs. one of the protected networks (VPNs).  

    For example, all unprotected web traffic (http/s) is proxied and the source is translated to WAN-1 = 222.111.000.123 (also the interface IP).  While traffic destined for the protected networks source is translated to WAN-1 = 222.111.000.125

    The “Local Networks” on each VPN configuration is set to a single IP on the External Interface (WAN-1 222.111.000.125)
    When the second uplink is added it seems to want to route traffic out the interface IP rather than sourcing it from the WAN-1 second IP which happens to be eh ONLY IP that the remote peer network will accept traffic from.

    BTW, I work with Jayson.
  • 0
    Solved!  

    We added SNAT rules for traffic destined for the protected networks and checked the "Rule applies to IPSec packets".  This then correctly translates the traffic source to the IP that the remote side of the VPN is expecting.  

    I love it when a plan comes together.

    Thanks for all the feedback.

    Aaron
  • 0
    Hi, Aaron, and welcome to the User BB!  Sorry I missed the posts you both put up on the 2nd.

    I think you guys lost me...

    There's not a place in the IPsec Connection where you can select the IP of an interface, so the only way to get outbound IPsec packets to leave with a source IP of an Additional Address is what Aaron found.  I don't understand how you guys were making it work before.

    Using Uplink Interfaces in your IPsec connections requires, as I explained in Post #2, that the device on the other side use an Availability Group (or the equivalent) and that you use a Multipath rule.   At present, if there were an interruption with WAN-1, the Astaro would try to establish the tunnels via WAN-2, but your correspondants would refuse the connections, or if your SNAT also applies to Uplink Interfaces, they would answer to WAN-1, and that wouldn't work.

    So, the best thing to do quickly would be to change your SNAT to apply only to WAN-1.

    Also, change the IPsec Connections back to WAN-1 instead of Uplink Interfaces if you can't get the other companies to configure so that you can come in from either WAN-1#2 or WAN-2.  If the other sides are Ciscos or other good VPN devices, they should be able to do this easily.

    I hate to offer unsolicited advice, but it's something I got unsolicited in the beginning, and I was glad I'd heard it.  I notice that you're using PSKs to authenticate.  Best practice recommends changing PSKs monthly or at least quarterly.  Any site-to-site that's intended to be used for longer than several months should be configured with RSA keys or X509 certificates.  RSA keys are easier, and, with only two tunnels, you likely don't need the PKI of certs.

    Cheers - Bob
    PS Jayson, great thread title, by the way! [:)]
  • 0 in reply to BAlfson
    Old thread but want to say thanks to all for solving a new challenge for me. Just set up a new site where the internal LAN connects to home office and internet over a T1 WAN but there is a surveillance camera system on a different subnet that connects to the world over a Cable WAN.
    This post clarified for me the proper Multipath rules to keep the traffic separate.
    Source Subnet1, Various services, Any, T1 WAN
    Source Subnet2, Various services, Any, Cable WAN
    Untick Advanced Skip Rule on Interface Error.

    PS: Note to self: Don't forget to add Subnet2 to Network Services DNS Allow and add Network Protection DNAT for Subnet2 and Firewall rule to allow required services.