[Solves] No IPSEC connection after 2.4.4 upgrade to some hosts
andipandi last edited by andipandi
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 to XXX.XXX.XXX.150 (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.
andipandi last edited by
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.
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.
andipandi last edited by
@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
hpingto get a similar effect.
For example, to see how far ESP (tunneled traffic) makes it, run this command:
$ hping -0 184.108.40.206 -H 50 -d 10 -t 1
220.127.116.11with the far side, and increase the
-tvalue until you do not get a response. That's where it gets dropped. I see
hpingsettings 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
-P UDP -p 500and again for