I've connected to gentoo gateways with openswan succesfully - as far as I use little amounts of data. E.G. if I make a http-request through that connection which loads a bigger picture 5kb afterwards, the download freezes and mozilla shows only the already fetched part of that picture. At the same time the pmtu discovery on SA ESP/12d83c5d/54b87h97 is logged on the sending machine. One (local) is connected via adsl/pppoe and dialup-ip to the net, the other remote) has dual-isdn and a fixed ip. The local one sets ppp0 MTU to 1492 and does clamping via netfilter. The remote one uses MTU of 1500 It seems there are some issues with mtu-discovery or wrong mss/mtu settings. overridemtu in /etc/ipsec/ipsec.conf does not work, I'm using Kernel 2.6.15-r1 (x86 gentoo-sources). I read on openswan.org that ther are some mtu issues fixed in 2.5-rcX, and there are patches available. Are they included in that big general gentoo-patch? Does anyone has solved that problem? or worked around? ervin ---------------------------- woodstok files # emerge -pv openswan && emerge info These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-misc/openswan-2.4.4 0 kB Total size of downloads: 0 kB Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/fax /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.tu-clauthal.de/pub/linux/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 acpi activefilter apache2 apm audiofile bash-completion berkdb bitmap-fonts bzip2 crypt cups curl dhcp doc eurofile examples extensions fbcon firebird foomaticdb freetds gdbm gif gmp gpm gs gstreamer gtk2 idn imagemagick imap ipppd iproute2 ipv6 isdnlog java jpeg kerberos ldap libg++ libwww logrotate mhash mppe-mppc ncurses nls pam pcre perl pg-hier pg-intdatetime pg-vacuumdelay png postfix postgres ppds pppd python readline samba sasl sdl slp spell ssl tcpd tetex tiff tools truetype truetype-fonts type1-fonts udev unicode usb winbind xml xml2 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Workaround: I set the mtu on the remote machine to 1492. I read something that pmtu-discovery might fail in some cases, because of misconfigured routers/gateways. it works for quite a while now. ervin
I've assumed the maintainer position.
I guess some ruter along the line filters ICMP "fragmentation needed" packets. Clamping MSS to PMTU won't help you since this field is present only in TCP packets and IPSec traffic is anything but TCP (keys are negociated through UDP and data packets are transferred using AH or ESP). overridemtu parameter is ignored when openswan use your kernel implementation of ipsec. openswan no longer creates ipsec%d interfaces and therefore cannot modify MTU: ipsec_setup: WARNING: overridemtu= is ignored when using the NETKEY stack Try to use tracepath to see if someone filters those precious ICMP packets. After you identify the guilty ones, tell them how braindead is their filtering policy. Bug closed as INVALID.
