Guest User!

You are not Sophos Staff.

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


Reply
  • 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


Children
No Data