From nobody@FreeBSD.org  Sat May 28 22:01:37 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3EE6616A41C
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 28 May 2005 22:01:37 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 17E4A43D1D
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 28 May 2005 22:01:37 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j4SM1adi056101
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 28 May 2005 22:01:36 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j4SM1aiA056100;
	Sat, 28 May 2005 22:01:36 GMT
	(envelope-from nobody)
Message-Id: <200505282201.j4SM1aiA056100@www.freebsd.org>
Date: Sat, 28 May 2005 22:01:36 GMT
From: Billy Newsom <mailhelp@leadhill.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipnat fails to start after upgrade to RELENG_5_4
X-Send-Pr-Version: www-2.3

>Number:         81606
>Category:       kern
>Synopsis:       [ipfilter] ipnat fails to start after upgrade to RELENG_5_4
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-net
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat May 28 22:10:01 GMT 2005
>Closed-Date:    Wed Jul 03 01:53:19 UTC 2013
>Last-Modified:  Wed Jul 03 01:53:19 UTC 2013
>Originator:     Billy Newsom
>Release:        RELENG_5
>Organization:
USA
>Environment:
FreeBSD host1.mydomain.com 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed May 18 09:29:47 CDT 2005     root@host1.mydomain.com:/usr/obj/usr/src/sys/BILLYSMP3  i386

>Description:
      I upgraded from a FreeBSD Stable circa February 2005 (about halfway between 5.3 and 5.4), to a post-5.4 Stable.  This was very soon after the release of 5.4 my kernel build date was May 18, 2005.  Once the machine rebooted with the new kernel, ipnat did not automatically load its NAT tables.  ipfilter firewall tables are installed as normal, and other subsystems installed as normal.

I posted this problem to the FreeBSD-stable mailing list on 25 May 2005.  Two others reported the same problem.  See http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/015329.html (my original post) and followups.  For a possible similar problem, see also http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/014792.html



>How-To-Repeat:
      Install a working NAT configuration for ipnat in FreeBSD 5.3-Release.  Compile and install 5.4 and reboot.  ipnat does not load on boot.  (I have confirmed privately with someone that the GENERIC kernel has the same problem as the SMP or custom kernel).  When you run ipnat on the commandline as root, ipnat operates normally.
>Fix:
      I don't see any CVS changes to ipfilter or ipnat.  Perhaps a problem with rc or rc.d loading?
>Release-Note:
>Audit-Trail:

From: Billy Newsom <mailhelp@leadhill.net>
To: bug-followup@FreeBSD.org, mailhelp@leadhill.net
Cc:  
Subject: Re: kern/81606: ipnat fails to start after upgrade to RELENG_5_4
Date: Tue, 31 May 2005 00:00:58 -0500

 I reported the first time that ipnat failed to start on the first boot 
 after installing FreeBSD 5.4.
 
 I am now reporting that on the second boot, ipnat loaded and installed 
 its tables, as expected.   A quick "ipnat -vls" at boot confirmed this. 
   YEAH!  But ON SECOND LOOK, I found out that ipnat was failing to do 
 its normal network translation.  A subsequent "ipnat -vls" confirmed 
 that there were no statistics for anything a day later -- all 0's, but I 
 should have been mapping in and out a lot of connections.
 
 So I cleared ipnat's tables and reloaded the same ones.  Instantly some 
 connections that were waiting to start were NATed in, and I saw some 
 active connections in the NAT statistics.  There had aparently been none 
 since the second boot using FreeBSD 5.4.
 
 NAT is now working, but only because I manually cleared and re-loaded 
 the NAT tables. [See shell output below]
 
 If I am away from this server, I wonder what I would do if I depended on 
 ipnat during a spontaneous reboot???  I would be firewalled out, 
 essentially, needing to login locally to fix it.  This is major, or so I 
 see it.
 
 Someone on the freebsd-stable list suggested I turn on ipv6 in rc.conf 
 or in the kernel.  Have not tried, yet.
 
 Here's a few sanitized shell outputs from the second boot of this 
 machine having ipnat problems.  I changed the port numbers to protect 
 the innocent.  [Note: oo0 is the name I gave to my WAN interface in 
 rc.conf.]
 
 Sun May 29 18:19:29 CDT 2005
 [[Bootup time for machine with FreeBSD 5.4, second boot]]
 # ipnat -vls
 mapped  in      0       out     0
 added   0       expired 0
 no memory       0       bad nat 0
 inuse   0
 rules   6
 wilds   0
 table 0xbfbfebc8 list 0xc1bc6e00
 List of active MAP/Redirect filters:
 rdr oo0 192.168.1.2/32 port 899 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 21111 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1238 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1234 -> 127.0.0.1 port 56 tcp
 rdr oo0 192.168.1.2/32 port 1236 -> 127.0.0.1 port 192 tcp
 rdr oo0 192.168.1.2/32 port 1237 -> 192.168.0.2 port 152 tcp
 
 List of active sessions:
 
 List of active host mappings:
 
 [Then I ran it again on the 30th... NO STATISTICS A DAY LATER]]
 
 # ipnat -vls
 mapped  in      0       out     0
 added   0       expired 0
 no memory       0       bad nat 0
 inuse   0
 rules   6
 wilds   0
 table 0xbfbfeba8 list 0xc1bc6e00
 List of active MAP/Redirect filters:
 rdr oo0 192.168.1.2/32 port 899 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 21111 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1238 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1234 -> 127.0.0.1 port 56 tcp
 rdr oo0 192.168.1.2/32 port 1236 -> 127.0.0.1 port 192 tcp
 rdr oo0 192.168.1.2/32 port 1237 -> 192.168.0.2 port 152 tcp
 
 List of active sessions:
 
 List of active host mappings:
 
 # ipnat -C
 6 entries flushed from NAT list
 
 # ipnat -vls
 mapped  in      0       out     0
 added   0       expired 0
 no memory       0       bad nat 0
 inuse   0
 rules   0
 wilds   0
 table 0xbfbfeba8 list 0x0
 List of active MAP/Redirect filters:
 
 List of active sessions:
 
 List of active host mappings:
 
 # ipnat -f /etc/ipnat.rules
 
 [Here we have GOOD STATS a few minutes later....]
 # ipnat -vls
 mapped  in      14      out     12
 added   1       expired 0
 no memory       0       bad nat 0
 inuse   1
 rules   6
 wilds   0
 table 0xbfbfeba8 list 0xc43f1a00
 List of active MAP/Redirect filters:
 rdr oo0 192.168.1.2/32 port 899 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 21111 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1238 -> 127.0.0.1 port 99 tcp
 rdr oo0 192.168.1.2/32 port 1234 -> 127.0.0.1 port 56 tcp
 rdr oo0 192.168.1.2/32 port 1236 -> 127.0.0.1 port 192 tcp
 rdr oo0 192.168.1.2/32 port 1237 -> 192.168.0.2 port 152 tcp
 
 List of active sessions:
 RDR 127.0.0.1       99    <- -> 192.168.1.2    899 [16.10.10.211 42666]
          age 438 use 0 sumd 0xba36/0xba36 pr 6 bkt 251/408 flags 1 drop 0/0
          ifp oo0 bytes 8532 pkts 26
 
 List of active host mappings:
 
 
 [NOTE: the statistics were reported correctly.]
 [ipnat had failed for over a day until I fixed it.]
Responsible-Changed-From-To: freebsd-bugs->darrenr 
Responsible-Changed-By: arved 
Responsible-Changed-When: Mon Jun 6 16:08:52 GMT 2005 
Responsible-Changed-Why:  
Over to ipfilter maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=81606 

From: Billy Newsom <billy@nlcc.us>
To: bug-followup@FreeBSD.org, mailhelp@leadhill.net
Cc:  
Subject: Re: kern/81606: ipnat fails to start after upgrade to RELENG_5_4
Date: Sun, 12 Jun 2005 18:17:41 -0500

 See also PR 81006 -
 
 Possible similarities:
 1. In PR 81006, ipnat fails to automatically load after a reboot.
 
 2. ipnat works fine after manually running ipnat from the shell.
 
 Differences:
 1. In PR 81006, the problem occurs on a gif interface.
 
 2. In PR 81006, the issue occurs on FreeBSD 5.3-RELEASE.
 

From: Fabian <df99@gmx.net>
To: bug-followup@freebsd.org, mailhelp@leadhill.net
Cc:  
Subject: Re: kern/81606: ipnat fails to start after upgrade to RELENG_5_4
Date: Thu, 30 Jun 2005 10:31:43 -0000

 -Bug also exist on clean install of FreeBSD Releng_5_4 or Releng_5.
 
 -Turning on ipv6 in the kernel does NOT solve this problem.
 
 -This could be related: Not compiling ipfilter into the kernel but loading  
 it as module on startup sometimes causes the system (i386 Releng_5) to  
 crash on startup (at the time of loading ipfilter).

From: David Pick <D.M.Pick@qmul.ac.uk>
To: bug-followup@FreeBSD.org, mailhelp@leadhill.net
Cc:  
Subject: Re: kern/81606: ipnat fails to start after upgrade to RELENG_5_4
Date: Mon, 11 Jul 2005 11:49:02 +0100

 The "ipf" command has an optional flag "-y" which (according to the 
 manual) performs the following action:
 	"Manually resync the in-kernel interface list maintained by
 	 IP Filter with the current interface status list."
 I don't know if this automagically does the same for the "ipnat"
 component of IPFilter, or if "ipnat" needs a similar flag, but I
 certainly used to find that it was useful doing "ipf -y" after
 creating new dynamic interfaces (PCCard, "vlan<n>"), &c, when
 the rules had already been read by "ipf".
 
 It might be necessary to arrange to call "ipf -y" (and a similar
 "ipnat -y" if that program needs it added) at suitable points in
 the startup sequences. In fact, I guess it would not be *wrong*
 to call it whenever an interface is created, destroyed, or
 renamed.
 
 -- 
 	David Pick
 

From: Billy Newsom <mailhelp@leadhill.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/81606: ipnat fails to start after upgrade to RELENG_5_4
Date: Tue, 12 Jul 2005 03:42:16 -0500

 This is a multi-part message in MIME format.
 --------------090704070807030602040100
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Yep.  See /etc/rc.d/netif, which does this thing called 
 "/etc/rc.d/ipfilter resync", which then runs ipf -y.  All of that 
 happens on bootup.  See also "rcorder /etc/rc.d/*" for what order things 
 are run during the rc phase.
 
 Looking at that order, you will see ipfilter and ipnat get run, then the 
 resync gets done when netif is run.  But as you say, I can't see how 
 ipnat ever gets resynced as ipf does.  But in my humble opinion, perhaps 
 a call to ipnat will fix that.  See the diff file I am including for a 
 FreeBSD 5.4 system.  Run patch in /etc/rc.d.
 
 I believe this will help the matter, and it might fix my problem and 
 others' if they have renamed interfaces.  I have tested.  Works for me. 
   It seems to solve the issue I was having.
 
 I have tested "/etc/rc.d/ipnat resync" on the commandline and it seems 
 to work fine.  There is not a big reason to rewrite the ipnat file with 
 a new command (resync), except that perhaps the ipfilter/ipnat 
 maintainer (Darren Reed) will write a -y option for ipnat someday? 
 Otherwise, I could have just said "/etc/rc.d/ipnat reload".  I like my 
 patch better, but not by much over just a simple reload.  My main 
 addition is that the following is output during the boot phase:
 "Re-Installing NAT rules"
 
 Note the "Re-".
 
 My patch should be attached below.
 
 Billy
 
 --------------090704070807030602040100
 Content-Type: text/plain;
  name="ipnat-diff.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="ipnat-diff.txt"
 
 diff -u --exclude=bak bak/ipnat ./ipnat
 --- bak/ipnat	Thu Nov  4 19:27:17 2004
 +++ ./ipnat	Mon Jul 11 12:20:39 2005
 @@ -18,7 +18,8 @@
  start_cmd="ipnat_start"
  stop_cmd="${ipnat_program} -F -C"
  reload_cmd="${ipnat_program} -F -C -f ${ipnat_rules}"
 -extra_commands="reload"
 +resync_cmd="ipnat_resync"
 +extra_commands="reload resync"
  
  ipnat_precmd()
  {
 @@ -42,5 +43,13 @@
  	echo "Installing NAT rules."
  	${ipnat_program} -CF -f ${ipnat_rules} ${ipnat_flags}
  }
 +
 +
 +ipnat_resync()
 +{
 +	echo -n "Re-"
 +	ipnat_start
 +}
 +
  
  run_rc_command "$1"
 diff -u --exclude=bak bak/netif ./netif
 --- bak/netif	Wed Dec 22 05:26:00 2004
 +++ ./netif	Mon Jul 11 12:22:30 2005
 @@ -65,8 +65,9 @@
  	network_common ifn_start verbose
  
  	if [ -f /etc/rc.d/ipfilter ] ; then
 -		# Resync ipfilter
 +		# Resync ipfilter and reload ipnat
  		/etc/rc.d/ipfilter resync
 +		/etc/rc.d/ipnat resync
  	fi
  }
  
 
 --------------090704070807030602040100--
State-Changed-From-To: open->open 
State-Changed-By: linimon 
State-Changed-When: Wed Jul 3 00:50:32 UTC 2013 
State-Changed-Why:  
commit bit has been taken in for safekeeping. 

To submitter: is this ancient PR still relevant? 


Responsible-Changed-From-To: darrenr->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jul 3 00:50:32 UTC 2013 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=81606 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Wed Jul 3 01:53:09 UTC 2013 
State-Changed-Why:  
Submitter's email address bounces. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=81606 
>Unformatted:
