From owner-freebsd-current@FreeBSD.ORG Mon May 2 18:41:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCB6016A4CE for ; Mon, 2 May 2005 18:41:39 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E606843D53 for ; Mon, 2 May 2005 18:41:38 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77609 invoked from network); 2 May 2005 18:41:27 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 May 2005 18:41:27 -0000 Message-ID: <42767460.2040102@freebsd.org> Date: Mon, 02 May 2005 20:41:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Matthew Sullivan References: <20050424150211.GA87520@walton.maths.tcd.ie> <426BC78A.3E56D99B@freebsd.org> <426C1600.106@uq.edu.au> <426D2307.97D15253@freebsd.org> <426D306B.7010000@freebsd.org> <426E0F5C.3F157398@freebsd.org> <4272AF49.1090400@uq.edu.au> <42763D42.BB3B5416@freebsd.org> <427643E2.4070008@uq.edu.au> <42764884.8070704@freebsd.org> <42764EC4.7030403@uq.edu.au> <42765153.3090409@freebsd.org> <42765479.4000101@uq.edu.au> In-Reply-To: <42765479.4000101@uq.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: DF (Don't frag) issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 18:41:40 -0000 Matthew Sullivan wrote: > Andre Oppermann wrote: > >> Matthew Sullivan wrote: >> >>> Andre Oppermann wrote: >>> >>>> Matthew Sullivan wrote: >>>> >>>>> Give me the switches you want on tcpdump and I'll be happy to >>>>> provide the packets ;-) >>>> >>>> >>>> >>>> This should do the trick: >>>> >>>> tcpdump -n -p -i fxp0 -s 128 -w dump >>>> >>> Ok this is what you have: >>> >>> root@scorpion:~# tcpdump -n -p -i fxp0 -s 128 -w pktdump not port 24 >>> >>> and it's at: http://scorpion.sorbs.net/ICMP/pktdump >> >> >> >> Ok, this is the problem: >> >> MTU of next hop: 0 >> >> Have you installed my patch on the gateway machine too, or only on your >> host? > > Patch is on both servers (the VPN server and the host the dump is from). > >> >> MTU of next hop should not be zero under normal circumstances. It >> indicates >> a bug somewhere in the normal IP forwarding path. >> >> Is this the correct packet flow: >> >> ... --> dc0 --> gif0 --> IPSec --> fxp0 --> Internet --> ... >> > That is correct for the VPN server. > > ifconfig for the VPN server as follows: > fxp0: flags=8843 mtu 1500 > options=8 > inet 203.101.254.252 netmask 0xffffff00 broadcast 203.101.254.255 > inet6 fe80::290:27ff:fec2:4977%fxp0 prefixlen 64 scopeid 0x1 > ether 00:90:27:c2:49:77 > media: Ethernet autoselect (100baseTX ) > status: active > dc0: flags=108843 mtu 1500 > options=8 > inet 203.15.51.61 netmask 0xffffffe0 broadcast 203.15.51.63 > inet6 fe80::2a0:cff:fec0:cc23%dc0 prefixlen 64 scopeid 0x2 > ether 00:a0:0c:c0:cc:23 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > gif0: flags=8051 mtu 1280 > tunnel inet 203.101.254.252 --> 138.130.223.244 > tunnel inet6 203.101.254.252 --> 138.130.223.244 > inet 203.15.51.61 --> 192.168.1.2 netmask 0xffffff00 > inet6 fe80::290:27ff:fec2:4977%gif0 prefixlen 64 scopeid 0x5 > > FreeBSD stealth.sorbs.net 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Fri Apr 29 > 17:50:25 EST 2005 > root@stealth.sorbs.net:/usr/obj/usr/src/sys/STEALTH i386 I'm at loss for an explanation. I've recreated approximatly the same setup with the gif tunnel (but no IPSec) and it works just fine for me. Getting correct MTU back and everything. What is your IPSec setup? Could it be that you do the IPSec on the IP packet first before it goes into the gif tunnel instead of the other way around? That may explain this behaviour. -- Andre