IPsec fails to renegotiate after loss of a peer-still exists in 1.2.3-RELEASE



  • I didn't want to tack onto the over 120 day old topic.  Sorry if that causes any heartburn.

    It appears that this issue still exists in 1.2.3-RELEASE.  I never had issues with IPsec tunnels in old versions of pfSense, but ever since I upgraded to 1.2-3-RELEASE 6 months or so ago I've been having intermittent issues with tunnels hanging.  In the last few days this has started being 3-5 outages per day (or more).

    I can use any of these methods to temporarily fix the issue, but it returns sometimes within 30 minutes:

    1. setkey -F

    2. you can also kill all of the SAs for that tunnel and it will fix it.

    3. you can also restart racoon service and that will fix it.

    here's the output from setkey -D when it's happening:

    my-firewall-ip their-firewall-ip
            esp mode=any spi=877118684(0x3447c4dc) reqid=16389(0x00004005)
            E: 3des-cbc  4ab1260f 8c105ac3 2e67e27a 30f3ec6e cbc068d9 6230da67
            A: hmac-sha1  201cd317 d1066379 0ea624cf 17335865 bd722635
            seq=0x00000000 replay=4 flags=0x00000000 state=mature
            created: May  3 22:15:10 2010  current: May  3 23:01:12 2010
            diff: 2762(s)  hard: 3600(s)  soft: 2880(s)
            last:                          hard: 0(s)      soft: 0(s)
            current: 0(bytes)      hard: 0(bytes)  soft: 0(bytes)
            allocated: 0    hard: 0 soft: 0
            sadb_seq=4 pid=3306 refcnt=1
    my-firewall-ip their-firewall-ip
            esp mode=any spi=877118679(0x3447c4d7) reqid=16389(0x00004005)
            E: 3des-cbc  8f33855b b501a9cb 0a1334d8 47078fff 184422d1 d4d8eb34
            A: hmac-sha1  95da3bc7 6c391cd4 4ca8592f eff8692e cec55305
            seq=0x000011e8 replay=4 flags=0x00000000 state=mature
            created: May  3 20:15:24 2010  current: May  3 23:01:12 2010
            diff: 9948(s)  hard: 28800(s)  soft: 23040(s)
            last: May  3 23:01:10 2010      hard: 0(s)      soft: 0(s)
            current: 595280(bytes)  hard: 0(bytes)  soft: 0(bytes)
            allocated: 4584 hard: 0 soft: 0
            sadb_seq=3 pid=3306 refcnt=2
    their-firewall-ip my-firewall-ip
            esp mode=tunnel spi=65028625(0x03e04211) reqid=16390(0x00004006)
            E: 3des-cbc  00e8d829 f34e4e58 fab174f7 6478434d e122b278 06db3b9d
            A: hmac-sha1  05d4df5d 4815ed86 581648a4 e0c5b4da 83e409c3
            seq=0x0000000b replay=4 flags=0x00000000 state=mature
            created: May  3 22:15:10 2010  current: May  3 23:01:12 2010
            diff: 2762(s)  hard: 3600(s)  soft: 2880(s)
            last: May  3 22:16:54 2010      hard: 0(s)      soft: 0(s)
            current: 840(bytes)    hard: 0(bytes)  soft: 0(bytes)
            allocated: 11  hard: 0 soft: 0
            sadb_seq=2 pid=3306 refcnt=1
    their-firewall-ip my-firewall-ip
            esp mode=tunnel spi=91333755(0x0571a47b) reqid=16390(0x00004006)
            E: 3des-cbc  85a806eb 02607275 20eac3fb 9f1b03ac 9b836e40 4685bf49
            A: hmac-sha1  0503f329 560a7258 9f3a6aed b21df11a 756d4e2a
            seq=0x0000de5c replay=4 flags=0x00000000 state=mature
            created: May  3 20:15:24 2010  current: May  3 23:01:12 2010
            diff: 9948(s)  hard: 28800(s)  soft: 23040(s)
            last: May  3 21:15:20 2010      hard: 0(s)      soft: 0(s)
            current: 74385717(bytes)        hard: 0(bytes)  soft: 0(bytes)
            allocated: 56924        hard: 0 soft: 0
            sadb_seq=1 pid=3306 refcnt=1
    their-firewall-ip my-firewall-ip
            esp mode=tunnel spi=250122876(0x0ee8927c) reqid=16390(0x00004006)
            E: 3des-cbc  8ca8e442 882c922c 77417a7a 98741878 62be60dd b457f389
            A: hmac-sha1  acd09080 04f43fc1 bcb42de5 5739b6c9 aba041b9
            seq=0x00000000 replay=4 flags=0x00000000 state=mature
            created: May  3 20:15:24 2010  current: May  3 23:01:12 2010
            diff: 9948(s)  hard: 28800(s)  soft: 23040(s)
            last:                          hard: 0(s)      soft: 0(s)
            current: 0(bytes)      hard: 0(bytes)  soft: 0(bytes)
            allocated: 0    hard: 0 soft: 0
            sadb_seq=0 pid=3306 refcnt=1

    the other thread had some discussion about the issue possibly being fixed, but it looks like it might not be.

    Other info:

    • I have made NO recent changes to the firewall configuration
    • I have asked if the other firewall at the remote end was changed but don't have an answer from my hosting provider yet
    • There were no consistent messages in the IPsec pfSense log


  • As I had expected, our hosting provider had made NO changes on their side either.

    They are using Netscreen 6.2.0r1.0 on their side.  I'm going to check this forum for Netscreen issues now.


  • Rebel Alliance Developer Netgate

    You might try to check the advanced option to prefer old IPsec SAs.

    I have had 0 issues with IPsec renegotiation with 1.2.3 since its release that were problematic before. I have had to check the prefer old IPsec SA option when connecting to some other vendor equipment.

    It may be a difference in which router initiated the tunnel. In IPsec, renegotiation is left up to the initiator, so one side may handle it better than the other.



  • @jimp:

    You might try to check the advanced option to prefer old IPsec SAs.

    I have had 0 issues with IPsec renegotiation with 1.2.3 since its release that were problematic before. I have had to check the prefer old IPsec SA option when connecting to some other vendor equipment.

    It may be a difference in which router initiated the tunnel. In IPsec, renegotiation is left up to the initiator, so one side may handle it better than the other.

    Unfortunately, there are an infinite number of possible configurations of IPsec tunnels, which makes it hard to track down issues with code and figure out where the bugs really are.  Case in point, my hosting provider made some change to their configuration and the problem has not reappeared for 36 hours.

    Comment from my provider on their change:

    We went ahead and adjusted a default negotiation number on the Netscreen. With the errors it was receiving I have seen this fix the issue many times.



  • @saxd40:

    It appears that this issue still exists in 1.2.3-RELEASE.  I never had issues with IPsec tunnels in old versions of pfSense, but ever since I upgraded to 1.2-3-RELEASE 6 months or so ago I've been having intermittent issues with tunnels hanging.  In the last few days this has started being 3-5 outages per day (or more).

    Are you using carp on the master site (two firewalls) ?

    I'have a lot of ipsec tunnels, towards pfsense boxes and cisco routers (837,857 and 877).
    I am using 'Prefer old IPsec SAs', and when A remote routers reboot (like AC loss) I must reboot the Firewall Master Node.
    When 'Prefer old IPsec SAs' is off, the tunnel goes down after the phase1 lifetime.
    From Ipsec status I always see green icons.

    PS:I suggest to use openvpn (when you have firewalls on both sides :P )

    Giacomo


Locked