Date: Thu, 1 Jun 2000 04:17:15 -0700 (PDT) From: vons@iname.com To: freebsd-gnats-submit@FreeBSD.org Subject: kern/18938: ipnat fails on dynamically created interfaces (e.g. tun) Message-ID: <20000601111715.1078137B851@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000601111715.1078137B851>