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.
Parents
  • 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
Reply
  • 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
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML