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=1the 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.
-
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.
-
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.
-
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
