Question about WAN Link Balancing

No idea?

The relase notes says:

"Of note is that in the Site-to-Site VPN section, there is now a new choice for the “local interfaces” drop-down box, which allows you to select “Uplink Interfaces” which resolves to the first available interface in the available interfaces box, increasing the redundancy available to site-site VPN’s."

Does it mean, that I have no chance to use redundancy on site-to-site VPNs with using multipath rules by selecting an interface?

BuBu already posted that problem without solution here.

I made a suggestion here, but, as I said in the post, I haven't tried it. 

Cheers - Bob
PS I think BuBu's problem was IP address conflicts.  He already had routes to the other network.  When he established the VPN, he, in essence, created another network with identical IPs.

That's almost what I thought would work.  What if, in the Multipath rule, you replace 1.2.3.4 with the local network(s) at the other location?

Also, what if you switch the order of the uplinks and make a second rule that prioritizes the SDSL link for all other traffic?  For that, you would need an "interface definition" like a network named 'Internet' with 0.0.0.0/0.  That way, anything that doesn't get routed by the first rule should be caught by the second.

Cheers - Bob
PS If this doesn't work, and you have support, please submit a ticket and then let us know the resolution.

That's almost what I thought would work.  What if, in the Multipath rule, you replace 1.2.3.4 with the local network(s) at the other location?

I got the same problem whith that combination, Astaro strictly uses the first available interface for VPN.

Also, what if you switch the order of the uplinks and make a second rule that prioritizes the SDSL link for all other traffic?  For that, you would need an "interface definition" like a network named 'Internet' with 0.0.0.0/0.  That way, anything that doesn't get routed by the first rule should be caught by the second.

I guess that would work but it wouldn't solve my problem, because I want to use different tunnels on different interfaces. In this case all traffic (e.g. two tunnels, htttp, etc.) should use the SDSL-Interface, but one tunnel should use the ADSL-Interface dedicated. If Astaro would do, I use the SDSL-Interface as the first one and the ADSL-Interface as the second one and add just one rule which forces Astaro to use the ADSL-Interface for this special tunnel.

I will submit a ticket and inform you, of course.

Kind regards,
Christian

Hi, we need such a config too, waiting for the Astaro response :-)

I had an issue with a dual WAN VPN setup that was resolved with a support call yesterday.  I had to create an availability group in the network definitions and include both remote ASG WAN IPs as network hosts in this group.  The availability group is a new option in the network definition types for 7.4.  If you set this up and use it as your gateway in the remote gateway setup for the IPSEC VPN, it may get the multipath rules working properly.

I got bad news from Astaro:

It is not possible to manage IPSec-Connections with multipath rules because the ASG starts the VPN-Tunnels before it considers the multipath rules. They didn't inform me about the reasons for that, but I guess there are some technical reasons for it.

The idea of bryan@rcg didn't work, I set "Uplink Interfaces" as the local interface on side A and used the secondary interface as the remote gateway on side B but the tunnel didn't establish. The ASG on side A is only listening on the primary interface.

Bryan, can you show us pics of your config?  I don't think cney tried what you were saying.

Perhaps I understood him wrong, but I think I tried the way Bryan described. On Side A, which has two outgoing WAN-Interfaces, I only can set the option "Uplink Interfaces" for this VPN-Tunnel, because otherwise I have to define a specific inteface. On Side B it is possible to use the new option "availability group" for the definition of the remote gateway. I set the secondary WAN-Interface of Side A as the first remote gateway but it didn't work, because Side A only listen on the primary interface even if I activate "respond only".

Did you use an availability group in the definition of the VPN?  Can you show us what didn't work?

Here my configuration:

***************************************************
=========
|| Side A ||
=========
Interfaces
----------
WAN1: 1.2.3.4
WAN2: 3.4.5.6

Uplink balancing
---------------
Type: Multipath
Priority: WAN1 (Pos. 1), WAN2 (Pos. 2)

Site-to-site VPN
----------------
Gateway type: Respond Only
Local Interface: Uplink Interfaces

=========
|| Side B ||
=========
Interfaces
----------
WAN1: 5.6.7.8

Site-to-site VPN
----------------
Gateway type: Initiate connection
Gateway: Availability group (3.4.5.6, 1.2.3.4)
***************************************************

This had no success because Side A just listens on WAN1 (1.2.3.4) on new VPN-connections. Perhaps I did something wrong?

Kind regards,
Christian

The advantage of a "respond only" setting is that you don't have to know the fixed IP address of the other end.  The disadvantage is that there can only be one pre-shared key for all such IPSec connections including remote access and site-to-site.  If you know the IP or can define a DynDNS address for the site, it's an advantage to use "Initiate connection."

Thanks, Christian, for getting the detail about site-to-site VPNs establishing without considering the order in Uplink Balancing.  That sounds like a bug to me!

Then again, I wonder if it would work "correctly" if you were to change to "Initiate connection" on Side A.  Probably not, if the Astaro Engineer had correct information, so...

I think Side B will persist in trying to establish the VPN on the first-listed Side A address (3.4.5.6) as long as it answers a ping.  Try setting up your test just like you did before, then disconnect 3.4.5.6; I bet the VPN will establish with 1.2.3.4.  So, if you switch the order in the availability group on Side B, everything should work even though not on the connection you wanted.

Cheers - Bob

The advantage of a "respond only" setting is that you don't have to know the fixed IP address of the other end.  The disadvantage is that there can only be one pre-shared key for all such IPSec connections including remote access and site-to-site.  If you know the IP or can define a DynDNS address for the site, it's an advantage to use "Initiate connection."

Thanks, Christian, for getting the detail about site-to-site VPNs establishing without considering the order in Uplink Balancing.  That sounds like a bug to me!

Then again, I wonder if it would work "correctly" if you were to change to "Initiate connection" on Side A.  Probably not, if the Astaro Engineer had correct information, so...

I think Side B will persist in trying to establish the VPN on the first-listed Side A address (3.4.5.6) as long as it answers a ping.  Try setting up your test just like you did before, then disconnect 3.4.5.6; I bet the VPN will establish with 1.2.3.4.  So, if you switch the order in the availability group on Side B, everything should work even though not on the connection you wanted.

Cheers - Bob