[Solves] No IPSEC connection after 2.4.4 upgrade to some hosts
-
We have several IPSEC connections.
2 of those broke after the upgrade to 2.4.4.
Asynchronous cryptography is disabled (like it was by default), also, since both affected connections are the only ones with multiple P2 entries, I copied one of the entries to only have 1 P2 entry, and the problem still exists.It seems like there is no connection being established at all.
We don't get an answer to our request, also never see the other sites request, and it is the same for the other side.
Oct 29 09:24:32 charon: 13[NET] <con13000|1> sending packet: from XXX.XXX.XXX.155[500] to XXX.XXX.XXX.150[500] (184 bytes) Oct 29 09:24:32 charon: 13[IKE] <con13000|1> sending retransmit 1 of request message ID 0, seq 1
I increased the debug log verbosity as per the troubleshooting site, but no other log message seems to be relevant.
I also had a look at the firewall log (normal view) to see if something was blocked, but the remote IP does not appear here at all.
-
I downgraded (luckily, this time I made a backup before the upgrade) - no change though.
I went back to the upgraded version - no change.
Next day, everything is working fine (with upgraded version).
No idea what is happening there.
I had similar things before though: the tunnels not coming up for many hours or even a day or two after an upgrade. -
@andipandi said in [Solves] No IPSEC connection after 2.4.4 upgrade to some hosts:
We don't get an answer to our request, also never see the other sites request, and it is the same for the other side
That sounds more like a connectivity problem between the sites, or someplace in between you filtering traffic. I doubt that has anything to do with pfSense if the request just disappears along the way.
Wouldn't be the first time ISPs were caught fiddling with IPsec.
-
@jimp Perhaps, I had it once or twice with no update. Also, the direct ping on external other address was working fine. I was wondering if there was an ipsec traceroute to see if something is blocked, but I guess that would not really exist?!
That would perhaps also explain why 2 sites were affected at the same time. -
There isn't an IPsec traceroute exactly, but you can use
hping
to get a similar effect.For example, to see how far ESP (tunneled traffic) makes it, run this command:
$ hping -0 1.2.3.4 -H 50 -d 10 -t 1
Replace
1.2.3.4
with the far side, and increase the-t
value until you do not get a response. That's where it gets dropped. I see-T
in thehping
settings now and it might be helpful as well.If the tunnel won't connect at all, however, that would be a simple UDP test for port 500 and 4500. For that you can probably use a traditional
traceroute
command with-P UDP -p 500
and again for-p 4500
.