Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 3895 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 tunnel unexpectedly falls!

thesNu
Hello all. 
We have site-to-site VPN configured trough ACC.  Since last update to ver 9.100-16. Ipsec tunnel start to down by all tests. But both sides show to us that everything is OK (5 of 5 IPsec SAs established).  We tried to restore backup, but it didn't help.
Disable/enable connection (1-3 times) in ACC configure VPN just help or sometimes reboot.

Log of command  "ipsec status": (When ipsec is not work but still established) 

KHV_Representation:/home/login # ip addr

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

7: eth0.1@eth0:  mtu 1500 qdisc noqueue state UP 

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

    inet 192.168.127.1/26 brd 192.168.127.63 scope global eth0.1

    inet 192.168.1.126/24 scope global eth0.1

8: eth0.7@eth0:  mtu 1500 qdisc noqueue state UP 

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

    inet 195.239.237.130/30 brd 195.239.237.131 scope global eth0.7

KHV_Representation:/home/login # ipsec status

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===192.168.224.0/24; erouted; eroute owner: #17

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0":   newest ISAKMP SA: #1; newest IPsec SA: #17; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===172.16.0.0/16; erouted; eroute owner: #15

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1":   newest ISAKMP SA: #0; newest IPsec SA: #15; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===192.168.223.0/24; erouted; eroute owner: #16

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2":   newest ISAKMP SA: #0; newest IPsec SA: #16; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===151.193.141.0/24; erouted; eroute owner: #13

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3":   newest ISAKMP SA: #0; newest IPsec SA: #13; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===151.193.178.0/24; erouted; eroute owner: #14

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4":   newest ISAKMP SA: #7; newest IPsec SA: #14; 

000 

000 #17: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2353s; newest IPSEC; eroute owner

000 #17: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" esp.ca597178@91.207.252.247 (5965125 bytes, 0s ago) esp.a061d9e4@195.239.237.130 (0 bytes); tunnel

000 #1: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 3045s; newest ISAKMP

000 #15: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2037s; newest IPSEC; eroute owner

000 #15: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" esp.d16a5f94@91.207.252.247 (0 bytes) esp.a93325e7@195.239.237.130 (0 bytes); tunnel

000 #16: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2267s; newest IPSEC; eroute owner

000 #16: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" esp.a6e9f6a1@91.207.252.247 (0 bytes) esp.7c2399e0@195.239.237.130 (0 bytes); tunnel

000 #13: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1864s; newest IPSEC; eroute owner

000 #13: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" esp.eeb780e2@91.207.252.247 (3648 bytes, 38s ago) esp.ec4b9191@195.239.237.130 (0 bytes); tunnel

000 #7: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3535s; newest ISAKMP

000 #14: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1875s; newest IPSEC; eroute owner

000 #14: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" esp.565b9988@91.207.252.247 (0 bytes) esp.e8bcbd04@195.239.237.130 (0 bytes); tunnel

000


Log of command  "ipsec status": (When ipsec is work fine) 

KHV_Representation:/home/login # ip addr     

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

7: eth0.1@eth0:  mtu 1500 qdisc noqueue state UP 

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

    inet 192.168.127.1/26 brd 192.168.127.63 scope global eth0.1

    inet 192.168.1.126/24 scope global eth0.1

8: eth0.7@eth0:  mtu 1500 qdisc noqueue state UP 

    link/ether 38:60:77:55:b1:e6 brd ff:ff:ff:ff:ff:ff

    inet 195.239.237.130/30 brd 195.239.237.131 scope global eth0.7

KHV_Representation:/home/login # ipsec status

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===192.168.224.0/24; erouted; eroute owner: #12

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0":   newest ISAKMP SA: #1; newest IPsec SA: #12; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===172.16.0.0/16; erouted; eroute owner: #9

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1":   newest ISAKMP SA: #0; newest IPsec SA: #9; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===192.168.223.0/24; erouted; eroute owner: #8

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2":   newest ISAKMP SA: #0; newest IPsec SA: #8; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===151.193.141.0/24; erouted; eroute owner: #11

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3":   newest ISAKMP SA: #0; newest IPsec SA: #11; 

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4": 192.168.127.0/26===195.239.237.130[KHV.ru]...91.207.252.247[91.207.252.247]===151.193.178.0/24; erouted; eroute owner: #10

000 "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4":   newest ISAKMP SA: #7; newest IPsec SA: #10; 

000 

000 #6: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2674s

000 #6: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" esp.bfb62e9e@91.207.252.247 (38220 bytes) esp.916e0a50@195.239.237.130 (3088 bytes); tunnel

000 #1: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 7000s; newest ISAKMP

000 #12: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3289s; newest IPSEC; eroute owner

000 #12: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_0" esp.b0746ff6@91.207.252.247 (337763 bytes, 0s ago) esp.798b4909@195.239.237.130 (101345 bytes, 0s ago); tunnel

000 #5: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2714s

000 #5: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" esp.10251556@91.207.252.247 (0 bytes) esp.7848f732@195.239.237.130 (0 bytes); tunnel

000 #9: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3289s; newest IPSEC; eroute owner

000 #9: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_1" esp.7450763@91.207.252.247 (0 bytes) esp.687a76bf@195.239.237.130 (0 bytes); tunnel

000 #4: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2599s

000 #4: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" esp.d0488b67@91.207.252.247 (0 bytes) esp.96ba07aa@195.239.237.130 (0 bytes); tunnel

000 #8: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3289s; newest IPSEC; eroute owner

000 #8: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_2" esp.f075c2c3@91.207.252.247 (0 bytes) esp.1778f3e9@195.239.237.130 (0 bytes); tunnel

000 #3: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2907s

000 #3: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" esp.b1c68a9b@91.207.252.247 (0 bytes) esp.b7e95e26@195.239.237.130 (0 bytes); tunnel

000 #11: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3289s; newest IPSEC; eroute owner

000 #11: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_3" esp.61ac6e17@91.207.252.247 (144 bytes, 3s ago) esp.41cc2c0e@195.239.237.130 (0 bytes); tunnel

000 #2: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2581s

000 #2: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" esp.c3f7fc3a@91.207.252.247 (0 bytes) esp.ce792b00@195.239.237.130 (0 bytes); tunnel

000 #10: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3289s; newest IPSEC; eroute owner

000 #7: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 7489s; newest ISAKMP

000 #10: "S_REF_ACC_LOC_028e880b304f418992270c953cb1b7b4b7b4_1_4" esp.d98095d6@91.207.252.247 (0 bytes) esp.b0bd706c@195.239.237.130 (0 bytes); tunnel


Log from ipsec.log when change is happened 

2013:05:27-15:21:08 KHV_Representation pluto[18841]: "S_KHV" #2: replacing stale IPsec SA

2013:05:27-15:21:08 KHV_Representation pluto[18841]: "S_KHV" #7: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP to replace #2 {using isakmp#1}

2013:05:27-15:21:08 KHV_Representation pluto[18841]: "S_KHV" #7: sent QI2, IPsec SA established {ESP=>0xe097aae6 0xb85c23c5 0xd4ba9c43 0xb151d58c 


Please help to solve this problem


This thread was automatically locked due to age.
  • 0
    Hi, thesNu, and welcome to the User BB!

    You definitely should get Sophos Support involved.  The only thing I can think of would be to delete the definitions in WebAdmin and then put them back.  Any luck with that?

    If not, then please show all of the IPsec log from 2013:05:27-15:21:00 through 23:22.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi, Bob. Thank you for your hospitality and quick answer!

    I can't delete definitions: they are used by others UTM. But I can tell You that there are 2 other UTM's with Ipsec VPN (using same definitions) and they are working correctly!

    We collected ipsec.log from down state, then up state, then down state again:

    Best regards, thesNu
    thesNu-IPsec-log.zip
  • 0
    There's something going on here that might be visible in the log for the same time on the other side.  Then again, there's also the ACC involvement, and I can't tell if the objects have been orphaned in this UTM or if they're still managed by the ACC.  Also, I question whether V9.1 can work with ACCv3 instead of SUMv4.

    Long story short, without looking through all three devices, it's a bit of a mystery ... please let us know what Sophos Support sas about this one.

    Cheers - Bob
    PS I replaced your link to another site with an attached zip file.  We're very security-concious here, and try to avoid links to unfamiliar sites where an object might get hi-jacked and injected with malware.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML