Bug 72210

Summary: [ipfilter] ipnat problem with IP Fastforward enabled
Product: Base System Reporter: Remy de Ruysscher <remy>
Component: kernAssignee: Cy Schubert <cy>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.3-BETA6   
Hardware: Any   
OS: Any   

Description Remy de Ruysscher 2004-09-30 19:50:11 UTC
ipnat is not working correctly after enabling IP Fastforward. 
ipmon shows NAT:MAP and NAT:RDR connections but don't seem to work on clients pc's.

I couldn't find any solutions at the usual places. Andre Opperman suggested I created this PR.

Fix: 

Disable IP fastforward. sysctl net.inet.ip.fastforwarding=0
How-To-Repeat: Enable IP fastforward. sysctl net.inet.ip.fastforwarding=1
Comment 1 Andre Oppermann freebsd_committer freebsd_triage 2004-09-30 22:26:52 UTC
Responsible Changed
From-To: freebsd-i386->andre

Take over.
Comment 2 Andre Oppermann freebsd_committer freebsd_triage 2004-10-14 21:03:30 UTC
This is a very stange problem.  Everything works fine with ipfw and pf/nat
but not with ipfilter/ipnat.  I'm a little bit at loss why ipnat breaks
when doing fastforwarding.  Need to check with Darren.

-- 
Andre
Comment 3 shattered 2007-08-17 18:43:22 UTC
Do you see any outgoing (NAT'd) traffic?

-- 
Sergey Svishchev
Comment 4 Remy de Ruysscher 2007-08-17 20:09:29 UTC
Hi,

I submitted this bug 3 years ago! And it's still not working.

I see outgoing packets but nothings gets through (timeouts):

17/08/2007 21:08:05.693252 STATE:CLOSE 83.98.233.137,50027 ->
69.147.83.33,80 PR tcp Forward: Pkts in 0 Bytes in 0 Pkts out 5 Bytes out
800 Backward: Pkts in 4 Bytes in 535 Pkts           out 0 Bytes out 0
17/08/2007 21:08:05.693256 STATE:CLOSE 83.98.233.137,50029 ->
69.147.83.33,80 PR tcp Forward: Pkts in 0 Bytes in 0 Pkts out 5 Bytes out
804 Backward: Pkts in 4 Bytes in 536 Pkts           out 0 Bytes out 0
17/08/2007 21:08:05.693259 STATE:EXPIRE 218.103.245.251,18652 ->
10.0.1.1,4999 PR udp Forward: Pkts in 1 Bytes in 90 Pkts out 1 Bytes out 90
Backward: Pkts in 0 Bytes in 0 Pkts           out 0 Bytes out 0
17/08/2007 21:08:05.751058 STATE:NEW 83.98.233.137,58881 -> 84.53.148.80,80
PR tcp
17/08/2007 21:08:05.794595 STATE:NEW 83.98.233.137,56668 ->
216.205.80.164,80 PR tcp
17/08/2007 21:08:05.837965 STATE:NEW 83.98.233.137,50722 -> 84.53.136.27,80
PR tcp
17/08/2007 21:08:06.195517 STATE:CLOSE 83.98.233.137,50031 ->
69.147.83.33,80 PR tcp Forward: Pkts in 0 Bytes in 0 Pkts out 5 Bytes out
804 Backward: Pkts in 4 Bytes in 543 Pkts           out 0 Bytes out 0
17/08/2007 21:08:06.695216 STATE:CLOSE 83.98.233.137,50033 ->
69.147.83.33,80 PR tcp Forward: Pkts in 0 Bytes in 0 Pkts out 5 Bytes out
801 Backward: Pkts in 4 Bytes in 537 Pkts           out 0 Bytes out 0


-----Original Message-----
From: Sergey Svishchev [mailto:svs@ropnet.ru] 
Sent: vrijdag 17 augustus 2007 19:43
To: bug-followup@FreeBSD.org; remy@unix-asp.com
Subject: Re: kern/72210

Do you see any outgoing (NAT'd) traffic?

-- 
Sergey Svishchev
Comment 5 shattered 2007-08-20 15:28:30 UTC
tcpdump reports that outgoing (NAT'd) packets have bad checksum...  Do you 
see this, too?

-- 
Sergey Svishchev
Comment 6 shattered 2007-09-14 19:19:32 UTC
ipfilter assumes that checksums will be recalculated later [1];
pf fixes checksums itself.

This works around the problem:

--- sys/contrib/ipfilter/netinet/ip_nat.c.orig	2005-03-13 21:08:56.000000000 +0300
+++ sys/contrib/ipfilter/netinet/ip_nat.c
@@ -2450,7 +2450,7 @@ maskloop:
 			CALC_SUMD(s1, s2, sumd);
 			fix_outcksum(fin, &ip->ip_sum, sumd);
 		}
-#if (SOLARIS || defined(__sgi)) || !defined(_KERNEL)
+#if (SOLARIS || defined(__sgi)) || defined(__FreeBSD__) || !defined(_KERNEL)
 		else {
 			if (nat->nat_dir == NAT_OUTBOUND)
 				fix_outcksum(fin, &ip->ip_sum, nat->nat_ipsumd);


[1] http://www.mail-archive.com/ipfilter@coombs.anu.edu.au/msg05755.html

-- 
Sergey Svishchev
Comment 7 K. Macy freebsd_committer freebsd_triage 2007-11-15 23:15:28 UTC
Responsible Changed
From-To: andre->darren


darren is the ipfilter maintainer
Comment 8 K. Macy freebsd_committer freebsd_triage 2007-11-15 23:16:32 UTC
Responsible Changed
From-To: darren->darrenr


mis-transcribed darren's e-mail
Comment 9 Eugene Perevyazko 2010-03-23 12:04:43 UTC
I still see this on 7.2-Stable now.
Maybe this should be fixed at last?
Although I've moved to ipfw nat and don't care anymore.

-- 
Eugene Perevyazko
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2013-07-03 01:50:32 UTC
State Changed
From-To: open->open

commit bit has been taken in for safekeeping. 


Comment 11 Mark Linimon freebsd_committer freebsd_triage 2013-07-03 01:50:32 UTC
Responsible Changed
From-To: darrenr->freebsd-net
Comment 12 Cy Schubert freebsd_committer freebsd_triage 2013-07-03 06:16:26 UTC
Responsible Changed
From-To: freebsd-net->cy

Mine.
Comment 13 commit-hook freebsd_committer freebsd_triage 2015-12-20 18:02:51 UTC
A commit references this bug:

Author: cy
Date: Sun Dec 20 18:02:13 UTC 2015
New revision: 292518
URL: https://svnweb.freebsd.org/changeset/base/292518

Log:
  Don't assume checksums will be calculated later when fastfoward is
  enabled (by default in r290383).

  PR:		72210
  MFC after:	1 week

Changes:
  head/sys/contrib/ipfilter/netinet/ip_nat.c
Comment 14 commit-hook freebsd_committer freebsd_triage 2015-12-27 23:26:00 UTC
A commit references this bug:

Author: cy
Date: Sun Dec 27 23:25:21 UTC 2015
New revision: 292811
URL: https://svnweb.freebsd.org/changeset/base/292811

Log:
  MFC r292518.

  Don't assume checksums will be calculated later when fastfoward is
  enabled (by default in r290383).

  PR:		72210

Changes:
_U  stable/10/
  stable/10/sys/contrib/ipfilter/netinet/ip_nat.c
Comment 15 Cy Schubert freebsd_committer freebsd_triage 2015-12-27 23:31:04 UTC
Fixed.
Comment 16 commit-hook freebsd_committer freebsd_triage 2016-03-16 02:02:07 UTC
A commit references this bug:

Author: cy
Date: Wed Mar 16 02:01:17 UTC 2016
New revision: 296924
URL: https://svnweb.freebsd.org/changeset/base/296924

Log:
  Don't assume checksums will be calculated later when fastfoward is
  enabled.

  This is a direct commit to the stable/9 because this branch uses
  ipfilter 4.1.28 whereas head has ipfilter 5.1.2. This corresponds
  to r292518 and r292813 in head and r292979 and r292811 in stable/10.

  PR:		72210

Changes:
  stable/9/sys/contrib/ipfilter/netinet/ip_nat.c