From owner-freebsd-current@FreeBSD.ORG Mon Aug 22 22:39:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 190CA16A420 for ; Mon, 22 Aug 2005 22:39:56 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id 3934143D46 for ; Mon, 22 Aug 2005 22:39:54 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 64967 invoked by uid 1001); 22 Aug 2005 22:39:53 -0000 Date: Tue, 23 Aug 2005 00:39:53 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org Message-ID: <20050822223952.GA62234@dataloss.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Cc: freebsd-current@freebsd.org Subject: freebsd 6-beta2, pf, route-to, checksum errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2005 22:39:56 -0000 Hi, I recently upgraded my FreeBSD/sparc64 5.4 router at home to 6-BETA2, without changing pf.conf. Since this upgrade, UDP packets redirected with pf's route-to feature get the wrong checksum. My complete ruleset: root@onion# grep -v ^# /etc/pf.conf ext_if="hme0" # replace with actual external interface name i.e., dc0 int_if="vlan2" # replace with actual internal interface name i.e., dc1 virtix_if="vlan4" # replace with actual internal interface name i.e., dc1 scrub in all nat on $ext_if from $int_if:network to any -> ($ext_if) nat on $virtix_if from $int_if:network to any -> ($virtix_if) pass out on $ext_if route-to ( $virtix_if 195.16.85.169 ) from $virtix_if:network to any ifconfig snippets to understand :network above: vlan2: flags=8843 mtu 1500 inet 172.16.13.32 netmask 0xffffff00 broadcast 172.16.13.255 vlan4: flags=8843 mtu 1500 inet 195.16.85.170 netmask 0xfffffff8 broadcast 195.16.85.175 tcpdump output of a broken DNS request: onion# tcpdump -n -i vlan4 -s 0 -v port 53 tcpdump: listening on vlan4, link-type EN10MB (Ethernet), capture size 65535 bytes 00:28:37.762481 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto: UDP (17), length: 68) 83.160.178.78.32812 > 195.16.85.170.53: 31240+ A? onion.home.dataloss.nl. (40) 00:28:37.765844 IP (tos 0x0, ttl 64, id 37505, offset 0, flags [none], proto: UDP (17), length: 117, bad cksum 86f (->c94d)!) 195.16.85.170.53 > 83.160.178.78.32812: 31240*- 1/1/1 onion.home.dataloss.nl. A 195.16.85.170 (89) Note the 'bad cksum'. When I set a route to this client IP (83.160.178.78), thereby never matching the relevant pf rule, the packet is fine and the answer arrives: 00:29:57.498780 IP (tos 0x0, ttl 64, id 38175, offset 0, flags [none], proto: UDP (17), length: 117) 195.16.85.170.53 > 83.160.178.78.32812: 33831*- 1/1/1 onion.home.dataloss.nl. A 195.16.85.170 (89) Am I doing something wrong, did I miss a notice in upgrading, or have I uncovered a bug? Thank you for your time. Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack