So, essentially, there is no easy mechanism to avoid fragmentation of the
ESP/UDP packet in the scenario described.

Thanks for the help!

On Wed, Nov 11, 2009 at 7:31 AM, Andreas Steffen <
[email protected]> wrote:

> Reid Stidolph wrote:
> > Thanks Andreas!
> >
> > Does this solution consider the case when the original packet does not
> > require fragmenation, however after adding the ESP header/trailer, it
> > becomes larger than the ethernet interface MTU on the same host?
> >
> Yeah, this actually works for host who are not aware that their traffic
> is going to be tunnelled in between.
>
> Regards
>
> Andreas
>
> >
> > On Mon, Nov 9, 2009 at 9:13 PM, Andreas Steffen
> > <[email protected] <mailto:[email protected]>>
> > wrote:
> >
> >     Hi,
> >
> >     the 'overridemtu' was used by FreeS/WANs own KLIPS IPsec stack
> >     and has in fact been deprecated with the native NETKEY IPsec stack of
> >     the Linux 2.6 kernel. The best way to avoid IP fragmentation problems
> >     is by enabling PMTU (Path MTU discovery) by setting the "do not
> >     fragment" (DF) bit in IP packets and allowing the forwarding of the
> >     "fragmentation required" ICMP (type 3, subtype 4) notifications in
> all
> >     firewalls in between.
> >
> >     Regards
> >
> >     Andreas
> >
> >     Reid Stidolph wrote:
> >     > I am looking for a way to modify the MTU on the virtual tunnel
> >     interface.
> >     > It seemed like there was a depricated setting 'overridemtu' that
> >     could be
> >     > configured in ipsec.conf.  However, when I configure:
> >     >
> >     > conn home
> >     >         left=192.168.1.30
> >     >         leftsourceip=%config
> >     >         eap_identity=xxxxxxx
> >     >         leftid=xxxxxxx
> >     >         leftauth=eap
> >     >         leftfirewall=yes
> >     >         right=192.168.1.2
> >     >         rightid=192.168.1.2
> >     >         rightsubnet=172.16.90.0/24 <http://172.16.90.0/24>
> >     >         auto=add
> >     >         ike=3des-sha1-md5-modp1024
> >     >         overridemtu=1300
> >     >
> >     > I get the following:
> >     >
> >     > r...@shuttle2:/usr/local/etc# ipsec start
> >     > Starting strongSwan 4.3.5 IPsec [starter]...
> >     > charon is already running (/var/run/charon.pid exists) -- skipping
> >     charon
> >     > start
> >     > # unsupported keyword 'overridemtu' in conn 'home'
> >     > ### 1 parsing error (0 fatal) ###
> >     >
> >     > What is the proper way to set tunnel MTU?
> >     >
> >     > I am needing to reduce tunnel MTU sizes, in order to prevent
> ESP/UDP
> >     > fragmentation (due to exceeding the ethernet interface MTU).
> >      Re-assymbly of
> >     > large amounts of ESP/UDP packets is burdening my gateway network
> >     processors.
> >     >
> >     > Help is greatly appreciated.
>
> ======================================================================
> Andreas Steffen                         [email protected]
> strongSwan - the Linux VPN Solution!                www.strongswan.org
>
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to