[strongSwan] Minimum achievable MTU with eth0 and IPsec ?

[Bharath Kumar]

Hi Mariano,

Please take a look at this note from the FAQ
http://wiki.strongswan.org/projects/strongswan/wiki/FAQ. Not sure but might
explain what's going on.

*Q:** strongSwan fails to initiate a connection to a peer. I'm using RSA
authentication and I noticed the two error messages: **'discarding
duplicate packet; already STATE_MAIN_I3'** on the initiator side and **'max
number of retransmissions (2) reached STATE_MAIN_R2'** on the responder
side.*

*A:* This problem might be related to the Path MTU (Maximum Transmission
Unit). The IKE protocol is transported in UDP datagrams. As result the UDP
datagrams also contain the X.509 certificate you are using. Now, if you're
using a large certificate the UDP datagram might get bigger than the PMTU.
That's the point where IP fragmentation kicks in and cuts your IP packet /
UDP datagram in two or more pieces. There are some firewalls out there that
strictly block IP fragments and therefore hamper your IKE connection. Large
X.509 certificates could result from long Distinguished names or from long
RSA keys (2048 bit). As a workaround you can reconfigure your firewall, try
to make your certificates smaller or preload the certificates on both
sidesand thereby get away without transmitting the certificates over
UDP.

Thanks,
Bharath Kumar


On Sat, May 4, 2013 at 5:32 AM, Mariano Lazzaro <marianolazzaro at gmail.com>wrote:

>  Hi all, I've searched the Wiki over this and couldn't find anything
> other than the tfc=%mtu (in the conn section) and the fragmentation=yes (I
> think). I already tested those 2 options on server and client with no
> success. I tried tfc=1400 and tfc=%mtu, having the interface MTU previously
> set to 1400, but it doesn't work when changed.
>
> My version of sSwan is 5.0.2.
>
> What I already tested is this, lowered the interface MTU of the server
> side to 1400, then strongswan connects OK (IKEv2) with the client having
> the interface MTU of 1500.
>
> When I tried another value of the client side interface MTU, the first
> part of the IPsec auth was OK, but the second part stalls, resending
> packets (it said it was sending packets of ~1990 bytes). That's odd (at
> least for me), because I know my DSL modem has MTU of 1492, my eth0 was at
> 1500 working OK, then my eth0 with MTU of 1400 or 1492 CAN'T CONNECT.
>
> I really don't understand why that happens, it shouldn't make any
> difference if I set my eth0 to 1500 or 1492 since the modem will do that
> later, chopping every packet to 1492 bytes, and fragmenting the ones that
> were larger.
>
> The second thing I don't understand is why the 1990 byte packets for the
> second part of ipsec auth?  WHY THE LARGE PACKETS?
> And if they're so large, they're supposed to be fragmented, because
> obviously then can't fit in a 1500 byte packet, or a 1492 one (it doesn't
> matter), the thing is that if those 1990 byte packets are somehow
> fragmented by the IP sender, that would mean 2 packets of MTU=1500, one
> full packet and the other with the other 400 remaining bytes.  And if the
> sender's MTU were 500 it should be fragmenting into 4 packets to accomplish
> sending the one 1990 or 1996 bytes IKEv2 auth packet.
>
> I hope I was clear enough.  I hope someone can help me understand what
> happens with strongSwan and MTU and fragmentation, I consider this rather
> important (I wish I could change the MTU as low as possible, I think I NEED
> to do that for other networking purposes, but the IPsec is locking me to
> 1500 bytes MTU).
>
> Besides all this questions I have, maybe you could just answer which is
> the minimum MTU so IPsec can work, and the second question would be "does
> strongSwan really need to have ALWAYS a 1500 byte MTU on the interfaces?".
>
> Thanks for your help, see you!
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130507/6ba2c70f/attachment.html>