From owner-freebsd-questions Fri Apr 12 5:20:50 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mail.nuvisions.net (mail.nuvisions.net [216.143.135.16]) by hub.freebsd.org (Postfix) with ESMTP id 4681F37B405 for ; Fri, 12 Apr 2002 05:20:41 -0700 (PDT) Received: from controlcenter ([65.89.71.23]) by mail.nuvisions.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 08:16:51 -0400 From: "Mark Uhrmacher" To: Subject: gif device checksum problem Date: Fri, 12 Apr 2002 08:20:39 -0400 Message-ID: <008701c1e21c$758ef7b0$0104a8c0@controlcenter> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 12 Apr 2002 12:16:51.0657 (UTC) FILETIME=[ED50BB90:01C1E21B] Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, Basically, I'm trying to setup an IPSEC-based VPN between two LANs that use cable modems to connect to the Internet. In both cases the internal LANs are behind "residential gateways" that provide NAT and some limited firewall services. For the first step, however, I'm attempting to get an IPv4-in-IPv4 tunnel working. Both of these gateways are configured to shunt all traffic from the external interface over to the FreeBSD box on their internal network described below. So, they don't filter but they do change the destination IP address on all packets to the internal address. Note this is the only way (I've found) to get non-TCP/UDP IP traffic coming from the Internet through these gateways. Both FreeBSD boxes are running 4.5 with a kernel enhanced with the following four lines added to the GENERIC kernel: # IPSec configuration params added by maui 2-Apr-2002 options IPSEC options IPSEC_ESP options IPSEC_DEBUG device gif 4 # tunnel for ipsec The configuration: NOTE: the external addresses for these setups have been changed to the alphabetic addresses a.b.c.d and e.f.g.h +------------+ +---------+ | | 192. | | | freebsd-hp +-- 168.-+ Netgear +--a.b.c.d---+ | | 4.2 | RT-314 | | +------------+ +---------+ | Internet +------------+ +---------+ | | | 192. | | | | unixserver +-- 168.-+ D-Link +--e.f.g.h---+ | | 0. | DI-713P | +------------+ 174 +---------+ I've configured tunnels as described below: freebsd-hp# gifconfig -a gif0: flags=8051 mtu 1280 inet6 fe80::2a0:c9ff:fe73:e269%gif0 prefixlen 64 inet 192.168.4.2 --> 192.168.0.174 netmask 0xffffff00 physical address inet 192.168.4.2 --> e.f.g.h unixserver# gifconfig -a gif0: flags=8051 mtu 1280 inet 192.168.0.174 --> 192.168.4.2 netmask 0xffffff00 inet6 fe80::2b0:d0ff:fe29:d3be%gif0 prefixlen 64 physical address inet 192.168.0.174 --> a.b.c.d After I did this I attempted pings in both directions. When that didn't work I started to do a little debugging with tcpdump and found some very interesting data. When pinging from freebsd-hp (192.168.4.2) to unixserver (192.168.0.174) I get the following output from tcpdump on both hosts: -- output -- freebsd-hp# tcpdump -vvv -n dst host e.f.g.h or src host e.f.g.h tcpdump: listening on fxp0 07:54:16.213186 192.168.4.2 > e.f.g.h: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54896, len 84) (ttl 30, id 54897, len 104) 07:54:17.223215 192.168.4.2 > e.f.g.h: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54905, len 84) (ttl 30, id 54906, len 104) 07:54:18.233106 192.168.4.2 > e.f.g.h: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54908, len 84) (ttl 30, id 54909, len 104) 07:54:19.243109 192.168.4.2 > e.f.g.h: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54911, len 84) (ttl 30, id 54912, len 104) unixserver# tcpdump -vvv -n src host a.b.c.d or dst host a.b.c.d tcpdump: listening on xl0 07:54:12.472425 a.b.c.d > 192.168.0.174: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54896, len 84) (ttl 11, id 54897, len 104) 07:54:12.472497 192.168.0.174 > a.b.c.d: 192.168.0.174 > 192.168.4.2: icmp: echo reply (ttl 64, id 14302, len 84) (ttl 30, id 14303, len 104, bad cksum 0!) 07:54:13.482047 a.b.c.d > 192.168.0.174: 192.168.4.2 > 192.168.0.174: icmp: echo request (ttl 64, id 54905, len 84) (ttl 11, id 54906, len 104) 07:54:13.482094 192.168.0.174 > a.b.c.d: 192.168.0.174 > 192.168.4.2: icmp: echo reply (ttl 64, id 14306, len 84) (ttl 30, id 14307, len 104, bad cksum 0!) --- end output --- So the ping request from freebsd-hp arrives at unixserver and a response is sent. Unfortunately, it never arrives. In addition tcpdump claims the packets send by unixserver have bad checksums. I suspect this is the problem. It is worth noting that when pinging from unixserver to freebsd-hp the request is lost and the ping request packets have the bad checksums. Regular pings to the external addresses work fine and have been verified by tcpdump not to have checksum errors. Also, the checksum error isn't specific to icmp. I get the same problem with ssh between the two boxes. It seems all packets going over the gif interface on unixserver have bad (uncalculated) checksums. Now on the questions: - why would taffic over the gif device not calculate checksums? - is there some way to turn them on? - why does one system do this and not the other? They were installed with 4.5 about a week apart Thanks, Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message