From owner-freebsd-bugs Thu Jun 1 4:20:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 5978837BA53 for ; Thu, 1 Jun 2000 04:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA96838; Thu, 1 Jun 2000 04:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: by hub.freebsd.org (Postfix, from userid 32767) id 1078137B851; Thu, 1 Jun 2000 04:17:15 -0700 (PDT) Message-Id: <20000601111715.1078137B851@hub.freebsd.org> Date: Thu, 1 Jun 2000 04:17:15 -0700 (PDT) From: vons@iname.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/18938: ipnat fails on dynamically created interfaces (e.g. tun) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 18938 >Category: kern >Synopsis: ipnat fails on dynamically created interfaces (e.g. tun) >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jun 01 04:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Gert-Jan Vons >Release: FreeBSD 4.0-RELEASE i386 >Organization: >Environment: FreeBSD dodo.vons.local 4.0-RELEASE FreeBSD 4.0-RELEASE #3: Thu Jun 1 12:57:13 CEST 2000 vons@dodo.vons.local:/usr/src/sys/compile/DODO i386 IPFILTER 3.3.16 in the kernel (the version of ipfilter that comes with 4.0-release has the same problem) This machine is the firewall between my home network (10.0.1.x) and the internet. ipnat rule "map tun0 10.0.0.0/16 -> 0/32" Userland ppp with the -background -unit0 options, and started manually (i.e. not automatically during the boot or something) >Description: Connections to the internet from any system on my local network fail, "tcpdump -i tun0" on the firewall shows that the packets going out of the firewall don't have their source addresses translated. Digging around in the ipnat code shows that when the nat rules are loaded at boot time, the in_ifp is set to (void*)-1 since the tun0 interface doesn't actually exist yet. Later on, when the tun device is created when ppp is started for the first time, the rules aren't updated and thus fail to match the outgoing packets. After flushing and re-loading the nat rules, things start working as expected since the interface now exists when the rules are added. Maybe ipnat needs the equivalent of "ipf -y", or is the kernel able to inform ipfilter/ipnat that a new dynamic interface has been created? Note that this problem also occurs on my laptop (FreeBSD 3.4 + PAO + fbsd3.4's ipfilter). When booting, the ed0 device does not exist, so when the pcmcia network card is inserted after ipnat has started, no address translation takes place. Again, reloading the ipnat rules after ed0 has been created fixes the problem. >How-To-Repeat: 1) reboot the system (removes any existing tun0 device) "ipnat -l" shows that the nat rule has been installed but "ifconfig -a" doesn't list the tun0 device yet. 2) start ppp (creates the tun0 device). 3) try to connect from the private lan to the internet. "tcpdump -i tun0" shows that packets are going out with 10.0.1.x as source address, i.e. untranslated. 4) after flushing and re-loading the nat rules, everything is fine. >Fix: A work-around is to reload the ipnat rules once the network device has been created. An alternative is the following patch (for ipfilter 3.3.16): -----8<----- *** ip_nat.c.org Fri May 19 17:52:29 2000 --- ip_nat.c Thu Jun 1 11:45:53 2000 *************** *** 1353,1358 **** --- 1353,1365 ---- hv = NAT_HASH_FN(iph, ipf_natrules_sz); for (np = nat_rules[hv]; np; np = np->in_mnext) { + if (np->in_ifp == (void*)-1) + { + np->in_ifp = (void *)GETUNIT(np->in_ifname); + if (!np->in_ifp) + np->in_ifp = (void *)-1; + } + if ((np->in_ifp == ifp) && np->in_space && (!(np->in_flags & IPN_RF) || (np->in_flags & nflags)) && -----8<----- >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message