Okay, so i followed the following guide: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec
And i have configured IPsec using IKEv2 with RSA authentication, everything i’ve done is according to the manual, i am successfully connecting to the IPsec server and i can ping public addresses and browse web sites freely.
Here is the problem, when i load some websites i get TLS handshake timeout, but this doesn’t happen to every HTTPS website, some websites work fine over HTTPS, others just give me TLS handshake timeout.
The client is strongswan.
Thank you in advance for the delegated time!
I would attribute this to MTU handling problem. Tunnelling packets via IPsec reduces usable MTU, and if some device on the path between the remote end of the tunnel and the remote server blocks ICMP in general, the MTU auto-accommodation mechanism which relies on ICMP messages “fragmentation needed” to be delivered to the TCP sender, large packets which can’t fit into the IPsec transport packets never get reduced and thus never get through.
Or there may be the same issue between the machine running the web client and the machine running the strongswan client if one of the firewalls involved blocks ICMP both explicitly and as “related” packets (the “fragmentation needed” messages are considered “related” to the TCP session they are, well, related to
Soo i looked through my firewall configs like fifty times, i even disabled the ICMP rules that i have just for the test, but the issue remains
Is my only option to configure IPsec through a L2TP?
If the problem is the one I suspect, changing the VPN type changes nothing about the problem as any VPN reduces the usable MTU of packets.
And as you only have a problem with some https servers, I assume that, as I’ve stated initially, the issue does not exist between your web client and your IPsec client but between your IPsec server and the https server. A packet sniff from the web client (tcpdump, wireshark) would be necessary to confirm this; if the web client and the IPsec client run on the same machine, it may be impossible to capture there at all (I don’t know whether the strongswan’s ipsecN virtual interfaces provide a capturing API or not).
The light bulb above my head just burned out
Since strongswan doesn’t create an interface as OpenVPN does, I just reduced the MTU of the interface that my computer was using at the moment, and now everything works as expected.
Before: wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
After: wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1400
Thank you so much for pointing out where the problem is!
If it is like this, then it seems to me like a strongswan problem as it doesn’t report back to the client that a packet is too large. So not that something between the IPsec server and the https server doesn’t let ICMP “fragmentation needed” through, but that the strongswan itself doesn’t send it to the https client.
I think you may have misunderstood me, the IPsec server is running on RouterOS, and the client is running strongswan.
As far as i know, and i did research a lot, there is no way to change the MTU in strongswan manually, so that’s why i changed the interface’s MTU.
I don’t say there should be a way to change the MTU at strongswan side. But when the strongswan gets a TCP packet (from the https client) for transmission and that packet is too large to fit into one ESP packet given the MTU on the wire and is marked with “don’t fragment”, the strongswan should do one of two things:
ignore the “don’t fragment” flag, split the packet into two parts and send each part in its own ESP packet; in this case, I’m not sure whether the recipient of the ESP (which is the Mikrotik’s implementation of IPsec) would reassemble the packet or forward the fragments
not send the packet at all and send back the ICMP “fragmentation needed” message to tell the TCP stack to send a smaller part of the stream data - this is the way to adjust the TCP’s MSS to the lowest MTU on the path so that instead of fragmenting each packet originally sent by the TCP stack into one big and one small one in transmission, already the sending TCP stack would slice the data stream into the largest possible packets which can fit everywhere along the path, as the latter way provides higher bandwidth efficiency
.
It would require more detailed analysis to find out which of the two scenarios happens. Different https servers use different TLS modes so it may be that the packets from the client differ in size depending on what the particular https server asks for, so it may be that they don’t exceed the “effective MTU” of the ESP where the connections succeed, but it may also be that the strongswan always fragments the packets before sending but some https servers don’t accept fragmented packets or don’t ever receive the fragments due to some firewalls’ activity.
I assume that the chain is https client → strongswan → Mikrotik → https server, correct?
As far as i know, the ICMP protocol was enabled on the the server and the gateway for the client, so i don’t get why it didn’t work correctly.
I even tried disabling my drop rules completely for the ICMP protocol and the fragmentation still didn’t happen, so i am guessing that the web server’s firewall was the culprit.
(Or maybe the Mikrotik IPsec implementation doesn’t reassemble the packets?)
I sincerely doubt that
