Guest User!

You are not Sophos Staff.

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

IPSEC fails on Primary, even though only secondary link affected

BSavage
We use dual links in multipath, with IPSEC VPN tunnels setup for uplink interface. We noticed that when our secondary link goes down, the IPSEC tunnel attempts to reestablish, even though it's up and fine on the primary. Anyone else notice this?

Our primary goal is uptime. These blips would be small, but IPSEC doesn't always reestablish itself, requiring manual intervention. So it seems to us that we have twice as much chance of going down in multipath mode, rather than in failover mode. 

I don't see this as a known issue. I can replicate this on v7 and v8. Does anyone know about the issue and can comment? Astaro support was notified, but I have had a lack of response on it.

Brian


This thread was automatically locked due to age.
  • 0
    Brian, is this two Astaros each with two different WAN connections?  Assuming that these two have configurations that mirror each other, how about pics of the 'IPsec Connection' and the 'Remote Gateway' from one side?

    Cheers - Bob
  • 0
    ASG #1 example has 2 WAN connections, with IPSEC tunnel configured for uplink interfaces in multipath mode. Cable and FIOS on eth1 and eth2 respectively. Doesn't matter if it's v7 or v8. It's initiating the connection to ASG #2 in respond only mode on only 1 WAN connection. 

    What happens is ASG#1 Eth1 on cable has IPSEC tunnel, and is fine. ASG#1 on eth2 FIOS drops, IPSEC restarts. you see the 'forgetting secrets' in the IPSEC VPN Log. 

    My question:
    If Eth1 is fine, why is ipsec restarted when eth2 fails? 

    Why it's such a big issue:
    I have 30+ ASG's that mimic ASG#1. Tunnels don't establish often. Many times I have to connect to ASG#1 on the external IP address, and toggle the tunnel. Sometimes I have to toggle the tunnel. Picture having to do this for 30+ ASG's. This is a daily annoyance. We were transitioning away from failover mode, to multipath mode hoping to maximize our bandwidth usage, but this issue makes our environment less stable, dropping our uptime numbers to new lows. Thanks
  • 0
    Brian, I have a client with eight locations doing a similar thing, and I don't believe this problem exists for them.

    Please show your multipath rule in ASG#1 AND your 'Availability Group' in ASG#2.  Pics of the IPsec configurations for both might be helpful.

    You said, "ASG#2 on eth2 FIOS drops" - but I thought you said there was only one WAN connection for the second ASG. - Fixed

    Cheers - Bob
  • 0
    I edited the post to correct the "ASG#2 on eth2 FIOS drops"" error to ASG#1. Thanks. 

    ASG #1's IPSEC tunnel is configured to connect to one ip address endpoint(ASG#2). No availability group on ASG#2 because it's in respond only. Cable and FIOS are dhcp, and when I tried dyndns, tunnels failed to establish sometimes, when dyndns failed to update properly .

    This unit is one example. It's our old v7 config, with 'any' in the tunnel definition. We always had them in failover mode, until we upgraded our ASG#2 to v8, and failover wasn't working properly. We do also have newer v8 units, in multipath, with only specific subnets configured for a tunnel to ASG#2, which behaves the same way. There is more explanation to this. Below is a print screen.


    FIOS on Eth2 has tunnel up
    Cable is Eth1, which experiences a failure.
    Tunnel is brought down, and doesn't reestablish until we connect remotely and toggle it off/on.


    Kernel messages log:
    --------------------------
    2011:07:16-08:33:30 apny-211-spg kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
    2011:07:16-11:08:46 apny-211-spg kernel: IPSEC EVENT: KLIPS device ipsec0 shut down.



    Service monitor log:
    ---------------------------
    sub="loadbalancing" name="multipath 1 ICMP 69.18.128.1 changed state to OFFLINE"
    2011:07:16-08:33:36 apny-211-spg service_monitor[26707]: id="4000" severity="info" sys="System" sub="loadbalancing" name="multipath 1 ICMP 69.18.128.3 changed state to OFFLINE"


    IPSEC VPN log:
    -----------------------
    2011:07:16-08:33:53 apny-211-spg pluto[20877]: forgetting secrets


  • 0
    OK, I think I see it.  You have a fast, reliable WAN connection for the data center, and two inexpensive connections at the remote locations.  Your configuration looks fine to me although I don't see any reason to be in Multipath mode.  It shouldn't make any difference, but what if you tried a multipath rule:

    Any -> IPsec -> DCE : bind to Verizon FiOS



    Cheers - Bob
    PS Your reseller really should get this escalated at Astaro Support.
    PPS Have you considered using the ACC?
  • 0
    We are only moving to multipath mode lately, and moving away from split tunneling. So your right,  multipath in this case is useless since all data passes over the tunnel. We were steered in that direction because our tunnels would need manual intervention, and it was believed multipath would help with the reestablish issue.  If we bind IPSEC to FIOS, then if the primary fails, it won't establish on Cable. This is why we use the uplink interface for the failover. Unless I'm wrong about that. Thanks for the input.
  • 0
    It will fail over with the multipath rule.

    Cheers - Bob
  • 0
    Latest test is v8.103 ASG #1 to v8.103 ASG#2. 
    ASG#1 is the remote unit with FIOS and cable, setup in multipath mode, set to establish IPSEC to 1 IP address.

    ASG#2 is the Data Center high bandwidth static IP on one interface, now set in initiate mode, availability group has dns host configured for domain names that resolve properly to eth1 and eth4 on ASG#1. I noticed the availability group, you can set the order of the hosts. I have them set to same order on each side. Meaning availability group on ASG#2 has eth1 at the top, then eth4 of ASG#1, and ASG#1's multipath has ETH1 at top, and Eth4 below it under multipath/uplink balancing/active interfaces.

    When I pull the plug on ASG#1 eth1, the IPSEC tunnel fails over to eth4. So a layer 2 test failure shows it will work fine. If I use manual checkip, set the checkip to my personal firewall at home that won't return a ping, the tunnel won't fail over. This is regardless of the multipath rule. I appreciate your time Bob. We are at the point now where no matter what configuration or version the ASG's are on, I can't stabilize IPSEC failover. If I can find a configuration that would allow IPSEC tunnels to failover, wether it's layer 2 failure, checkip failure, I could die a happy man. I tried the multipath rule, and couldn't get the checkip test to failover. Is it possible that the ASG#2 knows eth1 is up, and won't establish a tunnel with eth4 on ASG#1? Could it be that stringent? I'm still confused why respond only mode doesn't work. I tried the multipath rule, and it didn't seem to build a tunnel until I manually toggled. Thank you for your attention on this. I really appreciate it.

    Brian

    Brian
  • 0
    Brian, I like the idea of having both sides set to "Initiate connection" instead of setting the DC side to "Respond only" as that also protects you from a routing failure that affects only one ISP.  I'm surprised that your IP changes though, even with DHCP; I don't see that occurring elsewhere.  In any case, it might be worth the few dollars a month needed for static IPs.

    With the 'Availability Group' and 'Initiate Connection', the only real difference between your setup and my client's is that ha has fixed IPs and uses 'Automatic monitoring' instead of defined hosts.

    Cheers - Bob