Re: ipfw nat and smaller wan mtu

[John Hay]

Hi,

Adding this patch does make it work for me. There might be better ways to
do it. I have tested with ping and ssh. In ping's case, ping reported:
frag needed and DF set (MTU 1392)

In ssh's case I could see with tcpdump that the "need to frag (mtu 1392)"
was sent back and the next packet's length was adjusted.

#
06:29:59.869677 IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP
(6), length 1500)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], cksum 0xb64d (correct), seq
39:1487, ack 39, win 1027, options [nop,nop,TS val 260430893 ecr
926374970], length 1448
06:29:59.869954 IP (tos 0x0, ttl 63, id 62454, offset 0, flags [none],
proto ICMP (1), length 596)
10.10.2.2 > 10.10.1.3: ICMP 10.10.7.7 unreachable - need to frag (mtu
1392), length 576
IP (tos 0x48, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length
1500, bad cksum e081 (->19b7)!)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], seq 39:1487, ack 39, win
1027, options [nop,nop,TS val 260430893 ecr 926374970], length 1448
06:29:59.871301 IP (tos 0x48, ttl 64, id 0, offset 0, flags [DF], proto TCP
(6), length 1392)
10.10.1.3.64344 > 10.10.7.7.22: Flags [.], cksum 0x6841 (correct), seq
39:1379, ack 39, win 1027, options [nop,nop,TS val 260430893 ecr
926374970], length 1340
#

--- sys/netinet/libalias/alias.c.orig   2022-05-12 04:54:03.0 +
+++ sys/netinet/libalias/alias.c2022-12-08 05:42:25.12798 +
@@ -365,6 +365,19 @@
lnk = NULL;

if (lnk != NULL) {
+   /*
+   If the packet was locally generated, it will have a
+   loopback address as source, which will not be handled
+   correctly. For now use the destination address as source
+   address. The correct source address might be the the
+   interface address that the packet will be going out on.
+   */
+   if (IN_LOOPBACK(ntohl(pip->ip_src.s_addr)) &&
+   !IN_LOOPBACK(ntohl(pip->ip_dst.s_addr))) {
+   DifferentialChecksum(>ip_sum,
+   >ip_dst, >ip_src, 2);
+   pip->ip_src = pip->ip_dst;
+   }
if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP) {
int accumulate, accumulate2;
struct in_addr original_address;

On Wed, 7 Dec 2022 at 16:33, John Hay  wrote:

> Hi,
>
> What would the proper ipfw rules be to make nat work and properly get the
> icmp too big packets back to a local host if the wan interface needs a
> smaller mtu?
>
> I'm using a FreeBSD machine as router/firewall, but its wan interface
> needs a smaller mtu (1392) than the default ethernet mtu. I have replicated
> this in a VM so I can test it. My simplified ipfw rules make it work for
> packets that are smaller than the wan mtu:
>
> #
> net.inet.ip.fw.one_pass=0
> net.inet.ip.fw.verbose=1
> #
> fwcmd="/sbin/ipfw -q"
> wan="vtnet0"
> lan="vtnet1"
> ${fwcmd} nat 123 config if ${wan} log
> ${fwcmd} add 1000 count log all from any to any
> ${fwcmd} add 5000 nat 123 ip4 from any to any via ${wan}
> ${fwcmd} add 6000 allow log all from any to any
> #
> The wan ip of the firewall is 10.10.2.2 and the ip address of the host (on
> the lan side) I'm testing from is 10.10.1.3. And I did a ping to 10.10.5.5,
> which is on the other side of the wan interface.
>
> This works for packets smaller than the wan mtu. But if the packet is
> larger than the wan mtu, the icmp too big is generated, but with 127.0.0.1
> as the source and the wan ip as the destination and then sent via lo0 and
> it looks like this in the ipfw log:
>
> Dec  7 13:24:59 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
>
> So I added a nat ipfw rule to catch that:
>
> ${fwcmd} add 5050 nat 123 ip4 from any to not 127.0.0.1 via lo0
>
> That helped partly because it was then able to recover the address of the
> host I was testing from and tried to send the packet out on the correct
> interface (vtnet1). Unfortunately it still had the source address of
> 127.0.0.1, which means it did not actually make it to the wire:
>
> ##
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
> in via vtnet1
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.1.3 10.10.5.5
> in via vtnet1
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
> out via vtnet0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5
> out via vtnet0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.2.2
> out via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
> in via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3
> in via lo0
> Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 

ipfw nat and smaller wan mtu

[John Hay]

Hi,

What would the proper ipfw rules be to make nat work and properly get the
icmp too big packets back to a local host if the wan interface needs a
smaller mtu?

I'm using a FreeBSD machine as router/firewall, but its wan interface needs
a smaller mtu (1392) than the default ethernet mtu. I have replicated this
in a VM so I can test it. My simplified ipfw rules make it work for packets
that are smaller than the wan mtu:

#
net.inet.ip.fw.one_pass=0
net.inet.ip.fw.verbose=1
#
fwcmd="/sbin/ipfw -q"
wan="vtnet0"
lan="vtnet1"
${fwcmd} nat 123 config if ${wan} log
${fwcmd} add 1000 count log all from any to any
${fwcmd} add 5000 nat 123 ip4 from any to any via ${wan}
${fwcmd} add 6000 allow log all from any to any
#
The wan ip of the firewall is 10.10.2.2 and the ip address of the host (on
the lan side) I'm testing from is 10.10.1.3. And I did a ping to 10.10.5.5,
which is on the other side of the wan interface.

This works for packets smaller than the wan mtu. But if the packet is
larger than the wan mtu, the icmp too big is generated, but with 127.0.0.1
as the source and the wan ip as the destination and then sent via lo0 and
it looks like this in the ipfw log:

Dec  7 13:24:59 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
out via lo0

So I added a nat ipfw rule to catch that:

${fwcmd} add 5050 nat 123 ip4 from any to not 127.0.0.1 via lo0

That helped partly because it was then able to recover the address of the
host I was testing from and tried to send the packet out on the correct
interface (vtnet1). Unfortunately it still had the source address of
127.0.0.1, which means it did not actually make it to the wire:

##
Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
in via vtnet1
Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.1.3 10.10.5.5
in via vtnet1
Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5
out via vtnet0
Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5
out via vtnet0
Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
out via lo0
Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.2.2
out via lo0
Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2
in via lo0
Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3
in via lo0
Dec  7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.1.3
out via vtnet1
Dec  7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3
out via vtnet1
##

Once I have this sorted, there seems to be a similar problem with nptv6.

Regards

John

[Bug 213154] [patch] allow ipfw nat single pass with ipfw netgraph multi pass

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213154

Graham Perrin  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Graham Perrin  ---
Keyword: 

patch
or  patch-ready

– in lieu of summary line prefix: 

[patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 



-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

Lutz Donnerhacke  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #11 from Lutz Donnerhacke  ---
Seems to be solved.
Hopefully.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

Lutz Donnerhacke  changed:

   What|Removed |Added

  Flags||mfc-stable13+,
   ||mfc-stable12+

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

--- Comment #10 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=1883127de4888b2a30a6cb51e8fb4bdf33b7f411

commit 1883127de4888b2a30a6cb51e8fb4bdf33b7f411
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-27 21:42:54 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-07-06 07:10:02 +

libalias: Switch to SPLAY trees

Current data structure is using a hash of unordered lists.  Those
unordered lists are quite efficient, because the least recently
inserted entries are most likely to be used again.  In order to avoid
long search times in other cases, the lists are hashed into many
buckets.  Unfortunatly a search for a miss needs an exhaustive
inspection and a careful definition of the hash.

Splay trees offer a similar feature - almost O(1) for access of the
least recently used entries), and amortized O(ln(n) - for almost all
other cases.  Get rid of the hash.

Now the data structure should able to quickly react to external
packets without eating CPU cycles for breakfast, preventing a DoS.

PR: 192888
Discussed with: Dimitry Luhtionov
Differential Revision: https://reviews.freebsd.org/D30516
Differential Revision: https://reviews.freebsd.org/D30536
Differential Revision: https://reviews.freebsd.org/D30844

(cherry picked from commit 935fc93af157dee352eb4b6c83f8a2a9e7fd9a4e)
(cherry picked from commit d261e57deacb0d00d9e827447f235df83dda3e3a)
(cherry picked from commit f70c98a2f5d993dc518efd606aa341eda99400ef)
(cherry picked from commit 25392fac9488bcae5c451500df2e2945430484a6)
(cherry picked from commit 2f4d91f9cb22fc65eb65407e8118b433a5d71976)
(cherry picked from commit 4060e77f49d1b9fd2254f3f4da94fd64fce83f72)

 sys/netinet/libalias/HISTORY  |   3 +-
 sys/netinet/libalias/alias_db.c   | 502 +++---
 sys/netinet/libalias/alias_db.h (new) | 443 ++
 sys/netinet/libalias/alias_local.h|  10 +-
 4 files changed, 489 insertions(+), 469 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

--- Comment #9 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3a96a25da8614d27f717ba8d29d32bafb04a70e8

commit 3a96a25da8614d27f717ba8d29d32bafb04a70e8
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-27 21:42:54 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-07-06 06:55:53 +

libalias: Switch to SPLAY trees

Current data structure is using a hash of unordered lists.  Those
unordered lists are quite efficient, because the least recently
inserted entries are most likely to be used again.  In order to avoid
long search times in other cases, the lists are hashed into many
buckets.  Unfortunatly a search for a miss needs an exhaustive
inspection and a careful definition of the hash.

Splay trees offer a similar feature - almost O(1) for access of the
least recently used entries), and amortized O(ln(n) - for almost all
other cases.  Get rid of the hash.

Now the data structure should able to quickly react to external
packets without eating CPU cycles for breakfast, preventing a DoS.

PR: 192888
Discussed with: Dimitry Luhtionov
Differential Revision: https://reviews.freebsd.org/D30516
Differential Revision: https://reviews.freebsd.org/D30536
Differential Revision: https://reviews.freebsd.org/D30844

(cherry picked from commit 935fc93af157dee352eb4b6c83f8a2a9e7fd9a4e)
(cherry picked from commit d261e57deacb0d00d9e827447f235df83dda3e3a)
(cherry picked from commit f70c98a2f5d993dc518efd606aa341eda99400ef)
(cherry picked from commit 25392fac9488bcae5c451500df2e2945430484a6)
(cherry picked from commit 2f4d91f9cb22fc65eb65407e8118b433a5d71976)
(cherry picked from commit 4060e77f49d1b9fd2254f3f4da94fd64fce83f72)

 sys/netinet/libalias/HISTORY  |   3 +-
 sys/netinet/libalias/alias_db.c   | 502 +++---
 sys/netinet/libalias/alias_db.h (new) | 443 ++
 sys/netinet/libalias/alias_local.h|  10 +-
 4 files changed, 489 insertions(+), 469 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

--- Comment #8 from Lutz Donnerhacke  ---
May you please test your problem against 14-CURRENT?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=d261e57deacb0d00d9e827447f235df83dda3e3a

commit d261e57deacb0d00d9e827447f235df83dda3e3a
Author: Lutz Donnerhacke 
AuthorDate: 2021-05-28 20:36:59 +
Commit: Lutz Donnerhacke 
CommitDate: 2021-06-19 20:12:28 +

libalias: Switch to efficient data structure for incoming traffic

Current data structure is using a hash of unordered lists.  Those
unordered lists are quite efficient, because the least recently
inserted entries are most likely to be used again.  In order to avoid
long search times in other cases, the lists are hashed into many
buckets.  Unfortunatly a search for a miss needs an exhaustive
inspection and a careful definition of the hash.

Splay trees offer a similar feature: Almost O(1) for access of the
least recently used entries, and amortized O(ln(n)) for almost all
other cases.  Get rid of the hash.

Now the data structure should able to quickly react to external
packets without eating CPU cycles for breakfast, preventing a DoS.

PR: 192888
Discussed with: Dimitry Luhtionov
MFC after:  1 week
Differential Revision: https://reviews.freebsd.org/D30536

 sys/netinet/libalias/alias_db.c| 75 +-
 sys/netinet/libalias/alias_local.h |  6 +--
 2 files changed, 36 insertions(+), 45 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

--- Comment #6 from Lutz Donnerhacke  ---
May you try to apply those patches, please?

https://reviews.freebsd.org/D30516
https://reviews.freebsd.org/D30536

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

Lutz Donnerhacke  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #4 from Lutz Donnerhacke  ---
I went through the source code and can drill the problem down to an full scan
of an unsorted linked list in a given hash bucket. This eats CPU cycles for
breakfast.

A workaround is to increase the hash table size in
sys/netinet/libalias/alias_local.h:
#define LINK_TABLE_OUT_SIZE4001

A short term solution is to make the hard coded parameters tunable.

But the real solution is to find a data structure which allows sub linear
access methods to the flow data. Possibly using a non blocking algorithm for
access and modification.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

Lutz Donnerhacke  changed:

   What|Removed |Added

 CC||i...@freebsd.org
 Status|New |Open
   Assignee|i...@freebsd.org|don...@freebsd.org

--- Comment #3 from Lutz Donnerhacke  ---
All versions up to current are affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |In Progress
   Assignee|i...@freebsd.org|ma...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=652908599b6fa7285ee60cb567b97e70b648ac29

commit 652908599b6fa7285ee60cb567b97e70b648ac29
Author: Mark Johnston 
AuthorDate: 2021-04-21 19:38:01 +
Commit: Mark Johnston 
CommitDate: 2021-04-21 19:47:05 +

Add required checks for unmapped mbufs in ipdivert and ipfw

Also add an M_ASSERTMAPPED() macro to verify that all mbufs in the chain
are mapped.  Use it in ipfw_nat, which operates on a chain returned by
m_megapullup().

PR: 255164
Reviewed by:ae, gallatin
MFC after:  1 week
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D29838

 sys/netinet/ip_divert.c  |  6 ++
 sys/netpfil/ipfw/ip_fw_nat.c |  1 +
 sys/netpfil/ipfw/nat64/nat64_translate.c | 10 ++
 sys/sys/mbuf.h   | 11 +++
 4 files changed, 28 insertions(+)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

--- Comment #5 from 0xcdcdc...@gmail.com ---
I installed the patched ipdivert.ko and enabled the sendfile for nginx.
A few hours passed, but still no panic.
I will report it if it occurs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

--- Comment #4 from 0xcdcdc...@gmail.com ---
Thanks for your advices.

I disabled the sendfile for nginx and confirmed that it works stably.

I'm building a kernel with the patch you provided, so I'm going to apply it and
check it out.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

--- Comment #3 from Joshua Kinard  ---
This might be related to the issue I reported in Bug #255104, where I get
random crashes/panics shortly after activating a divert(4) rule in my IPFW
firewall to route packets to Snort for inline inspection.  WLAN traffic seems
to more easily trigger it than wired LAN traffic.  I'll look at trying to test
this patch in the next few days to see if it resolves the issue somewhat (or
makes it less likely to happen).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

--- Comment #2 from Andrey V. Elsukov  ---
Created attachment 224248
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224248=edit
proposed patch (untested)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

Andrey V. Elsukov  changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #1 from Andrey V. Elsukov  ---
Did you try to disable sendfile for nginx? 
I think this can be related to lack of mb_unmapped_to_ext() call in ip_divert()
code. ipfw_nat and ipfw_nat64 also seems need to be modified. Do you have saved
core dump from this panic?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 255164] Panic with ipfw/nat under 13.0-RELEASE amd64

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164

Mark Linimon  changed:

   What|Removed |Added

   Keywords||panic, regression
   Assignee|b...@freebsd.org|i...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

l...@donnerhacke.de changed:

   What|Removed |Added

 CC||l...@donnerhacke.de

--- Comment #2 from l...@donnerhacke.de ---
It seems that the problems still exists:
(Articles in German)
https://lutz.donnerhacke.de/Blog/Performance-Probleme-mit-NAT
https://lutz.donnerhacke.de/Blog/Wenn-der-Traceroute-Kreise-tanzt

It's a variant of the LAND attack https://en.wikipedia.org/wiki/LAND.

My solution is to use ipfw (which is used to activate NAT) to drop incoming
packets sourced from the public NAT IP. So simple antispoofing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 192888] ipfw NAT vulnerable to simple DOS attacks

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888

Tom Jones  changed:

   What|Removed |Added

 CC||t...@freebsd.org

--- Comment #1 from Tom Jones  ---
Could you add some more detail or steps to reproduce? If this issue still
exists in FreeBSD I would be very interested in fixing this. If I don't have
any response in the next few months I will close this issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 224231] [ipfw] kernel panic when using ipfw nat

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224231

Andrey V. Elsukov  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #2 from Andrey V. Elsukov  ---
Fixed in head/ and stable/11.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 224231] [ipfw] kernel panic when using ipfw nat

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224231

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-ipfw@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPFW NAT behaviour different on 10-Stable versus 11-Stable [SOLVED]

[Graham Menhennitt]

On 02/09/2017 20:46, Ian Smith wrote:

On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:

  > I have a problem that seems to be a difference between ipfw/NAT
  > behaviour in 10-Stable versus 11-Stable. I have two servers: one running
  > 10-Stable and one running 11-Stable. I'm using the same rule set on both
  > (see below). It works correctly on 10-Stable but not on 11.
  >
  > The problem is seen on two places: an outgoing SMTP connection on port
  > 465, and an incoming to an IMAP server on port 993. In both cases, there
  > are lost packets and retransmissions. See below for a tshark capture of
  > one attempted SMTP session.
  >
  > Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no
  > difference. Deleting the sshguard rule (table 22) makes no difference.
  > Deleting the nat rule makes everything work for this SMTP session (but
  > breaks the other machines on my network obviously).
  >
  > I have no doubt that I have misconfigured the firewall, but I don't see
  > what. And why is 11 different to 10? Any help would be much appreciated.
  >
  > Thanks in advance,
  >
  >  Graham

Mysterious.  Unless this is some other networking issue, three thoughts:

1) given that YYY is your public IP address, are the problematic SMTP
sessions actually going through NAT at all, or are they initiated from
YYY directly?  If the latter, it's hard to see why removing the NAT rule
should affect these session at all?

2) does it make any difference if you split the NAT rules into separate
rules, as per the ipfw(8) 'NAT, REDIRECT AND LSNAT' section in EXAMPLES?

3) given the tokens used in your ruleset, it appears that you are using
a preproceesor to substitute values rather than shell variables?  If so
(or even if not) can you confirm that the resulting in-place rulesets
shown by 'ipfw list' are absolutely identical on both machines?

Just some long shots ..

cheers, Ian


Thanks for replying, Ian.

Well I solved it. Similarly to my previous problem, the solution was to 
disable the TXCSUM option on the interface. So, now the entry in 
/etc/rc.conf says:


ifconfig_igb1="DHCP -vlanhwtso -tso4 -txcsum"

And it all works.

Thanks again,

Graham

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPFW NAT behaviour different on 10-Stable versus 11-Stable

[Ian Smith]

On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:

 > I have a problem that seems to be a difference between ipfw/NAT 
 > behaviour in 10-Stable versus 11-Stable. I have two servers: one running 
 > 10-Stable and one running 11-Stable. I'm using the same rule set on both 
 > (see below). It works correctly on 10-Stable but not on 11.
 > 
 > The problem is seen on two places: an outgoing SMTP connection on port 
 > 465, and an incoming to an IMAP server on port 993. In both cases, there 
 > are lost packets and retransmissions. See below for a tshark capture of 
 > one attempted SMTP session.
 > 
 > Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no 
 > difference. Deleting the sshguard rule (table 22) makes no difference. 
 > Deleting the nat rule makes everything work for this SMTP session (but 
 > breaks the other machines on my network obviously).
 > 
 > I have no doubt that I have misconfigured the firewall, but I don't see 
 > what. And why is 11 different to 10? Any help would be much appreciated.
 > 
 > Thanks in advance,
 > 
 >  Graham

Mysterious.  Unless this is some other networking issue, three thoughts:

1) given that YYY is your public IP address, are the problematic SMTP 
sessions actually going through NAT at all, or are they initiated from 
YYY directly?  If the latter, it's hard to see why removing the NAT rule 
should affect these session at all?

2) does it make any difference if you split the NAT rules into separate 
rules, as per the ipfw(8) 'NAT, REDIRECT AND LSNAT' section in EXAMPLES?

3) given the tokens used in your ruleset, it appears that you are using 
a preproceesor to substitute values rather than shell variables?  If so 
(or even if not) can you confirm that the resulting in-place rulesets 
shown by 'ipfw list' are absolutely identical on both machines?

Just some long shots ..

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

IPFW NAT behaviour different on 10-Stable versus 11-Stable

[Graham Menhennitt]

I have a problem that seems to be a difference between ipfw/NAT 
behaviour in 10-Stable versus 11-Stable. I have two servers: one running 
10-Stable and one running 11-Stable. I'm using the same rule set on both 
(see below). It works correctly on 10-Stable but not on 11.


The problem is seen on two places: an outgoing SMTP connection on port 
465, and an incoming to an IMAP server on port 993. In both cases, there 
are lost packets and retransmissions. See below for a tshark capture of 
one attempted SMTP session.


Setting sysctl net.inet.ip.fw.one_pass to one or zero makes no 
difference. Deleting the sshguard rule (table 22) makes no difference. 
Deleting the nat rule makes everything work for this SMTP session (but 
breaks the other machines on my network obviously).


I have no doubt that I have misconfigured the firewall, but I don't see 
what. And why is 11 different to 10? Any help would be much appreciated.


Thanks in advance,

Graham


Tshark:

(XXX is the SMTP server, YYY is my public IP address)

root# tshark -Y tcp.port==465 -i igb1
Capturing on 'igb1'
4   0.722919 YYY → XXX TLSv1.2 180 Client Key Exchange, Change 
Cipher Spec, Encrypted Handshake Message
  527  17.822843 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 1335  51.814540 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 1393  85.806537 YYY → XXX TCP 180 [TCP Retransmission] 63024 → 465 
[PSH, ACK] Seq=1 Ack=1 Win=65535 Len=126
 2142 107.799346 XXX → YYY TCP 60 465 → 63024 [FIN, ACK] Seq=1 Ack=1 
Win=15544 Len=0
 2143 107.799393 YYY → XXX TCP 54 63024 → 465 [ACK] Seq=127 Ack=2 
Win=65535 Len=0
 2144 107.800135 YYY → XXX TCP 54 63024 → 465 [FIN, ACK] Seq=127 Ack=2 
Win=65535 Len=0
 2145 107.822047 YYY → XXX TCP 74 53762 → 465 [SYN] Seq=0 Win=65535 
Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=2591962 TSecr=0

 2146 107.977234 XXX → YYY TCP 60 465 → 63024 [RST] Seq=2 Win=0 Len=0
 2149 108.001214 XXX → YYY TCP 62 465 → 53762 [SYN, ACK] Seq=0 Ack=1 
Win=14600 Len=0 MSS=1460 SACK_PERM=1
 2150 108.001270 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=1 Ack=1 
Win=65535 Len=0

 2151 108.009014 YYY → XXX TLSv1 323 Client Hello
 2160 108.187708 XXX → YYY TCP 60 465 → 53762 [ACK] Seq=1 Ack=270 
Win=15544 Len=0

 2176 108.687644 XXX → YYY TLSv1.2 1514 Server Hello
 2177 108.687884 XXX → YYY TCP 1514 465 → 53762 [PSH, ACK] Seq=1461 
Ack=270 Win=15544 Len=1460 [TCP segment of a reassembled PDU]
 2178 108.687949 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=270 Ack=2921 
Win=62874 Len=0
 2179 108.688175 XXX → YYY TCP 1230 465 → 53762 [PSH, ACK] Seq=2921 
Ack=270 Win=15544 Len=1176 [TCP segment of a reassembled PDU]
 2180 108.704012 XXX → YYY TCP 1514 465 → 53762 [ACK] Seq=4097 Ack=270 
Win=15544 Len=1460 [TCP segment of a reassembled PDU]
 2181 108.704052 YYY → XXX TCP 54 53762 → 465 [ACK] Seq=270 Ack=5557 
Win=64240 Len=0
 2182 108.704625 XXX → YYY TLSv1.2 969 Certificate, Server Key 
Exchange, Server Hello Done
 2183 108.715222 YYY → XXX TLSv1.2 180 Client Key Exchange, Change 
Cipher Spec, Encrypted Handshake Message
 2211 109.133829 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2238 109.443030 XXX → YYY TCP 969 [TCP Spurious Retransmission] 465 → 
53762 [PSH, ACK] Seq=5557 Ack=270 Win=15544 Len=915[Reassembly error, 
protocol TCP: New fragment overlaps old data (retransmission?)]
 2239 109.443099 YYY → XXX TCP 54 [TCP Dup ACK 2183#1] 53762 → 465 
[ACK] Seq=396 Ack=6472 Win=65535 Len=0
 2244 109.772021 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2301 110.827331 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2402 112.770796 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2612 116.391551 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2711 119.018591 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2737 123.957850 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2789 133.632511 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126
 2859 152.776509 YYY → XXX TCP 180 [TCP Retransmission] 53762 → 465 
[PSH, ACK] Seq=270 Ack=6472 Win=65535 Len=126

^C32 packets captured
root#


Rules:

# stop spoofing
add deny all from LAN_NET to any in via OUTSIDE_IF
add deny all from WIFI_NET to any in via OUTSIDE_IF

# allow anything on the LAN
add allow all from any to any via LAN_IF

# and from the VPN
add allow all from any to any via VPN_IF

# allow anything from the wireless network to the outside world (but not 
to the LAN)

add allow ip from any to not LAN_NET via WIFI_IF

# create a table of addresses to block
#table 1 destroy
#table 1 create type addr
table 1 flush
# add

[Bug 216719] panic: ipfw_check_frame: unknown retval - while trying to ipfw nat incoming packet without translation state (can be L2 firewall related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719

smi...@nimnet.asn.au changed:

   What|Removed |Added

 CC||smi...@nimnet.asn.au

--- Comment #2 from smi...@nimnet.asn.au ---
(In reply to bsd from comment #1)

You have set net.link.ether.ipfw=1b

Are you using any rules for layer2 ?  If not, set that to 0.  If so,
likely best to follow the example in ipfw(8) /PACKET FLOW to separate
layer2 from layer 3 processing, otherwise every rule is tested on
both layer2 and layer 3 passes, i.e. usually on each of 4 passes.

Which is why adding 'not layer2'  to the nat rule fixed it here, but
other dragons may lie hidden in other rules checked at both layers.

But of course, it shouldn't panic .. backtrace looks all layer2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 216719] panic: ipfw_check_frame: unknown retval - while trying to ipfw nat incoming packet without translation state (can be L2 firewall related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719

--- Comment #1 from b...@kobyla.org ---
Adding the "not layer2" to ipfw nat rule helps to avoid this problem

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 216719] panic: ipfw_check_frame: unknown retval - while trying to ipfw nat incoming packet without translation state (can be L2 firewall related)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-ipfw@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

FreeBSD 11.0 Stable: ipfw nat show? where show?

[valery4]

Hello!

freebsd-amd64

10.3-STABLE FreeBSD 10.3-STABLE #0 r308165M:
# ipfw nat 1 show
nat 1: icmp=3, udp=27, tcp=77, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=107


11.0-STABLE FreeBSD 11.0-STABLE #0: Mon Nov 14 17:54:37

# ipfw nat 1 show
ipfw: Please specify action. Available: config,log


Where show?



-- 

mailto:vale...@vorkuta.com

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

FreeBSD 11.0 Stable: ipfw nat show? where?

[support]

Здравствуйте, Freebsd-ipfw.

freebsd-amd64

10.3-STABLE FreeBSD 10.3-STABLE #0 r308165M:
# ipfw nat 1 show
nat 1: icmp=3, udp=27, tcp=77, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / 
tot=107



11.0-STABLE FreeBSD 11.0-STABLE #0: Mon Nov 14 17:54:37

# ipfw nat 1 show
ipfw: Please specify action. Available: config,log



-- 
С уважением,
 Support  mailto:supp...@vorkuta.com

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 213154] [patch] allow ipfw nat single pass with ipfw netgraph multi pass

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213154

Mark Linimon <lini...@freebsd.org> changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-ipfw@FreeBSD.org
Summary|ipfw nat single pass with   |[patch] allow ipfw nat
   |ipfw netgraph multi pass|single pass with ipfw
   ||netgraph multi pass

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 211256] ipfw nat tablearg regression in FreeBSD 11

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211256

Andrey V. Elsukov  changed:

   What|Removed |Added

   Assignee|freebsd-ipfw@FreeBSD.org|a...@freebsd.org
 CC||a...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 211256] ipfw nat tablearg regression in FreeBSD 11

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211256

Mark Linimon <lini...@freebsd.org> changed:

   What|Removed |Added

   Keywords||regression
   Assignee|freebsd-standards@FreeBSD.o |freebsd-ipfw@FreeBSD.org
   |rg  |
Summary|FreeBSD 11 ipfw nat |ipfw nat tablearg
   |tablearg|regression in FreeBSD 11

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

ipfw NAT, igb and hardware checksums

[Karim Fodil-Lemelin]

Hi,

I've hit a very interesting problem with ipfw-nat and local TCP traffic 
that has enough TCP options to hit a special case in m_megapullup(). 
Here is the story:


I am using the following NIC:

igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086 
rev=0x01 hdr=0x00


And when I do ipfw nat to locally emitted packets I see packets not 
being processed in the igb driver for HW checksum. Now a quick search 
for m_pullup in the igb driver code will show that our igb driver 
expects a contiguous ethernet + ip header in igb_tx_ctx_setup(). Now the 
friendly m_megapullup() in alias.c doesn't reserve any space before the 
ip header for the ethernet header after its call to m_getcl like 
tcp_output.c (see m->m_data += max_linkhdr in tcp_output.c).


So the call to M_PREPEND() in ether_output() is forced to prepend a new 
mbuf for the ethernet header, leading to a non contiguous ether + ip. 
This in turn leads to a failure to properly read the IP protocol in the 
igb driver and apply the proper HW checksum function. Particularly this 
call in igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);


To reproduce the issue I simply create a NAT rule for an igb interface 
and initiate a TCP connection locally going out through that interface 
(it should go through NAT obviously) something like:


ipfw nat 1 config igb0 reset
ipfw add 10 nat 1 via igb0

 Although you need to make sure you fill enough of the SYN packet to 
trigger the allocation of new memory in m_megapullup. You can do this by 
using enough TCP options so its filling up almost all of the 256 mbuf or 
make RESERVE something like 300 bytes in alias.c.


The fix I propose is very simple and faster for all drivers, including 
the ones that do perform a check for ether + ip to be contiguous upon 
accessing the IP header. If the leading space is available it doesn't 
allocate any extra space (as it should for most cases) but if for some 
reason the mbuf used doesn't have 100 bytes (RESERVE in megapullup) of 
free space it will reserve some at the front too. If the leading space 
isn't necessary then it won't cause any harm.



-Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
+Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
diff --git a/freebsd/sys/netinet/libalias/alias.c 
b/freebsd/sys/netinet/libalias/alias.c

index 876e958..dc424a6 100644
--- a/freebsd/sys/netinet/libalias/alias.c
+++ b/freebsd/sys/netinet/libalias/alias.c
@@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
 * writable and has some extra space for expansion.
 * XXX: Constant 100bytes is completely empirical. */
 #defineRESERVE 100
-   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
+ if (m->m_next == NULL && M_WRITABLE(m) &&
+ M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >= 
max_linkhdr)

return (m);

if (len <= MCLBYTES - RESERVE) {
@@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
goto bad;

m_move_pkthdr(mcl, m);
+ mcl->m_data += max_linkhdr;
m_copydata(m, 0, len, mtod(mcl, caddr_t));
mcl->m_len = mcl->m_pkthdr.len = len;
m_freem(m);

It would be nice if some FBSD comitter could review and hopefully add 
this patch to FBSD.


Thank you,

Karim.
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw NAT, igb and hardware checksums

[Adrian Chadd]

This looks mostly sensible. hm!



-a


On 13 January 2016 at 11:55, Karim Fodil-Lemelin
<fodillemlinka...@gmail.com> wrote:
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic that
> has enough TCP options to hit a special case in m_megapullup(). Here is the
> story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086
> rev=0x01 hdr=0x00
>
> And when I do ipfw nat to locally emitted packets I see packets not being
> processed in the igb driver for HW checksum. Now a quick search for m_pullup
> in the igb driver code will show that our igb driver expects a contiguous
> ethernet + ip header in igb_tx_ctx_setup(). Now the friendly m_megapullup()
> in alias.c doesn't reserve any space before the ip header for the ethernet
> header after its call to m_getcl like tcp_output.c (see m->m_data +=
> max_linkhdr in tcp_output.c).
>
> So the call to M_PREPEND() in ether_output() is forced to prepend a new mbuf
> for the ethernet header, leading to a non contiguous ether + ip. This in
> turn leads to a failure to properly read the IP protocol in the igb driver
> and apply the proper HW checksum function. Particularly this call in
> igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);
>
> To reproduce the issue I simply create a NAT rule for an igb interface and
> initiate a TCP connection locally going out through that interface (it
> should go through NAT obviously) something like:
>
> ipfw nat 1 config igb0 reset
> ipfw add 10 nat 1 via igb0
>
>  Although you need to make sure you fill enough of the SYN packet to trigger
> the allocation of new memory in m_megapullup. You can do this by using
> enough TCP options so its filling up almost all of the 256 mbuf or make
> RESERVE something like 300 bytes in alias.c.
>
> The fix I propose is very simple and faster for all drivers, including the
> ones that do perform a check for ether + ip to be contiguous upon accessing
> the IP header. If the leading space is available it doesn't allocate any
> extra space (as it should for most cases) but if for some reason the mbuf
> used doesn't have 100 bytes (RESERVE in megapullup) of free space it will
> reserve some at the front too. If the leading space isn't necessary then it
> won't cause any harm.
>
>
> -Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
> +Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
> diff --git a/freebsd/sys/netinet/libalias/alias.c
> b/freebsd/sys/netinet/libalias/alias.c
> index 876e958..dc424a6 100644
> --- a/freebsd/sys/netinet/libalias/alias.c
> +++ b/freebsd/sys/netinet/libalias/alias.c
> @@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
>  * writable and has some extra space for expansion.
>  * XXX: Constant 100bytes is completely empirical. */
>  #defineRESERVE 100
> -   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
> + if (m->m_next == NULL && M_WRITABLE(m) &&
> + M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >=
> max_linkhdr)
> return (m);
>
> if (len <= MCLBYTES - RESERVE) {
> @@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
> goto bad;
>
> m_move_pkthdr(mcl, m);
> + mcl->m_data += max_linkhdr;
> m_copydata(m, 0, len, mtod(mcl, caddr_t));
> mcl->m_len = mcl->m_pkthdr.len = len;
> m_freem(m);
>
> It would be nice if some FBSD comitter could review and hopefully add this
> patch to FBSD.
>
> Thank you,
>
> Karim.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

[Bug 180729] [ipfw] ipfw nat show empty output

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180729

Colin anonymous.bug.rep...@gmail.com changed:

   What|Removed |Added

 CC||anonymous.bug.report@gmail.
   ||com

--- Comment #2 from Colin anonymous.bug.rep...@gmail.com ---
You need to add the log keyword.
ipfw nat 1 config if igb1 log unreg_only reset

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

[Bug 180729] [ipfw] ipfw nat show empty output

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180729

Nick Hibma n_hi...@freebsd.org changed:

   What|Removed |Added

 Status|In Discussion   |Issue Resolved
 Resolution|--- |Works As Intended

--- Comment #3 from Nick Hibma n_hi...@freebsd.org ---
This is actually true: If you want to see the NAT log counters you need to
configure it so with `nat X config log ...` .

It is beyond me why this simple counting requires this, but that is left as an
exercise to the reader.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/180729: [ipfw] ipfw nat show empty output

[linimon]

Old Synopsis: ipfw nat show empty output
New Synopsis: [ipfw] ipfw nat show empty output

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 26 21:47:32 UTC 2013
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=180729
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: IPFW NAT show problems

[wishmaster]

 --- Original message ---
From: isp ml...@ukr.net
Date: 20 July 2013, 18:12:07

 
 Hi! I have problems with displaing information about NAT states on
 FreeBSD 9.1.
 There is no information when I use `ipfw nat 1 show`
  
  I have the same issue on my router 9.1-STABLE FreeBSD 9.1-STABLE #1
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

ipfw nat show?

[wishmaster]

Hi,

Recently, I have switched from pf to ipfw. All works fine, except nat statistic.
When I type 

ipfw nat show or ipfw nat 1 show nothing is on output.

FreeBSD xxx.com 9.1-STABLE FreeBSD 9.1-STABLE #0: Tue Apr 30 22:03:16 EEST 2013 
wishmas...@xxx.com:/usr/obj/usr/src/sys/MY6  i386
Kernel with VIMAGE option.

On another machine with -CURRENT all fine.
Is it bug?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/129093: [ipfw] ipfw nat must not drop packets

[Коньков Евгений]

The following reply was made to PR kern/129093; it has been noted by GNATS.

From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:  
Subject: Re: kern/129093: [ipfw] ipfw nat must not drop packets
Date: Tue, 20 Dec 2011 20:38:52 +0200

 seems work on latest FreeBSD versions (9 and 10)
 
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

ipfw nat drops icmp packets from localhost

[Oleg Strizhak]

Dear All!

Would you mind enlightening me a little bit on the following:

when I ping or traceroute any external host (even default gateway) w/o 
ipfw -- it's OK;

when I ping -- w/ ipfw -- it's OK
when I traceroute -- it FAILS =( all hop are three stars in a row
when any LAN (192.168.0.х) host ping or traceroute any ext host (by ipfw 
nat) -- it's OK



# uname -a
FreeBSD proxy.yy.ru 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Mon Oct  3 
19:19:30 MSD 2011 a...@xx.yy.ru:/usr/obj/usr/src/sys/ZZZ  amd64

# ipfw nat show config
ipfw nat 7 config if vr0 log same_ports reset redirect_port tcp 
192.168.0.97:3389 7899 redirect_port tcp 192.168.0.250:3389 8998 redirect_port 
tcp 192.168.0.98:3389 7997 redirect_port tcp 192.168.0.201:3389  
redirect_port tcp 192.168.0.254:3389 5995 redirect_port tcp 192.168.0.99:3389 
9998 redirect_port tcp 192.168.0.95:3389 8899 redirect_port tcp 
192.168.0.248:20-21 20-21


After an investigation I've found out a very strange situation - it 
seems to me, that ipfw nat drops some (type 11?) icmp reply packets, 
whose udp request packets it hasn't rewritten/seen before, e.g:



05577 count log logamount 1000 icmp from any to any
05600 nat 7 ip from any to me in { recv fxp0 or recv vr0 }
05677 count log logamount 1000 icmp from any to any


if I ping (let's suppose that my external ip is 1.2.3.4 and dst ip is 
equal to 5.6.7.8, vr0 - external iface, fxp0 -- reserved external face, 
not used when vr0 is up  running):



Оct  6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:8.0 1.2.3.4 5.6.7.8 out via 
vr0
Oct  6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:8.0 1.2.3.4 5.6.7.8 out via 
vr0
Oct  6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:0.0 5.6.7.8 1.2.3.4 in via 
vr0
Oct  6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:0.0 5.6.7.8 1.2.3.4 in via 
vr0


if I traceroute:


Oct  6 11:01:53 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via 
vr0
Oct  6 11:01:58 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via 
vr0
Oct  6 11:02:03 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via 
vr0


at the same time, if LAN host (yes, LAN's behind ale0) traceroutes ext 
host via nat 7:



Oct  6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via 
vr0
Oct  6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.168.0.97 
in via vr0
Oct  6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 192.168.0.97 
out via ale0
Oct  6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.168.0.97 
out via ale0


So, I wonder whether someone else has seen the same case under the 
similar circumstances? Isn't it a bug within ipfw nat module and is 
there any work-around/patch for that? I've surely googled, but in vain 
=( The only thing, that seems alike to my problem, is 
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 
branch didn't cure anything =(


WBR,
Oleg Strizhak


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw nat drops icmp packets from localhost

[Oleg Strizhak]

Hello, Andrey V. Elsukov!

You wrote on 06.10.2011 at 13:38:


On 06.10.2011 12:29, Oleg Strizhak wrote:

After an investigation I've found out a very strange situation - it seems to 
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't 
rewritten/seen before, e.g:

So, I wonder whether someone else has seen the same case under the similar 
circumstances? Isn't it a
bug within ipfw nat module and is there any work-around/patch for that? I've 
surely googled, but in
vain =( The only thing, that seems alike to my problem, is
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch 
didn't cure anything =(


Can you describe how you did apply and test this patch?


in a usual way =) Unfortunately, copy-pasted from the mentioned above 
page patch couldn't be applied w/ error:



$ patch  ~/ip_fw_nat.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|--- stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58 2011 
(r223834)
|+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11 2011 
(r223835)
--
Patching file ip_fw_nat.c using Plan A...
patch:  malformed patch at line 4: else


the same results were obtained with combinations of -p5 -l and tail +2 
~/ip_fw_nat.patch options  commands
Finally, I modified the patch (which applies w/o a word =) a little bit 
w/o any difference to the original one:



 $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my
--- /root/ip_fw_nat.patch   2011-10-04 14:08:32.0 +0400
+++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400
@@ -1,5 +1,5 @@
 stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58 2011 
(r223834)
-+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11 2011 
(r223835)
+--- ip_fw_nat.c.orig   2010-12-21 20:09:25.0 +0300
 ip_fw_nat.c2011-10-04 14:27:02.0 +0400
 @@ -263,17 +263,27 @@
 else
 retval = LibAliasOut(t-lib, c,


then I recompiled the kernel, rebooted server and.. all is just the same =(

WBR,
Oleg
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw nat drops icmp packets from localhost [patch attached]

[Oleg Strizhak]

Здравствуйте, Andrey V. Elsukov!

Вы писали 06.10.2011 13:38:


On 06.10.2011 12:29, Oleg Strizhak wrote:

After an investigation I've found out a very strange situation - it seems to 
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't 
rewritten/seen before, e.g:

So, I wonder whether someone else has seen the same case under the similar 
circumstances? Isn't it a
bug within ipfw nat module and is there any work-around/patch for that? I've 
surely googled, but in
vain =( The only thing, that seems alike to my problem, is
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch 
didn't cure anything =(


Can you describe how you did apply and test this patch?


I beg your pardon: in my previous reply I forgot to attach my patch. 
Here it is


WBR,
Oleg
--- ip_fw_nat.c.orig2010-12-21 20:09:25.0 +0300
+++ ip_fw_nat.c 2011-10-04 14:27:02.0 +0400
@@ -263,17 +263,27 @@
else
retval = LibAliasOut(t-lib, c,
mcl-m_len + M_TRAILINGSPACE(mcl));
-   if (retval == PKT_ALIAS_RESPOND) {
-   m-m_flags |= M_SKIP_FIREWALL;
-   retval = PKT_ALIAS_OK;
-   }
-   if (retval != PKT_ALIAS_OK 
-   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
+
+   /*
+* We drop packet when:
+* 1. libalias returns PKT_ALIAS_ERROR;
+* 2. For incoming packets:
+*  a) for unresolved fragments;
+*  b) libalias returns PKT_ALIAS_IGNORED and
+*   PKT_ALIAS_DENY_INCOMING flag is set.
+*/
+   if (retval == PKT_ALIAS_ERROR ||
+(args-oif == NULL  (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT ||
+(retval == PKT_ALIAS_IGNORED 
+(t-lib-packetAliasMode  PKT_ALIAS_DENY_INCOMING) != 0 {
/* XXX - should i add some logging? */
m_free(mcl);
args-m = NULL;
return (IP_FW_DENY);
}
+
+   if (retval == PKT_ALIAS_RESPOND)
+m-m_flags |= M_SKIP_FIREWALL;
mcl-m_pkthdr.len = mcl-m_len = ntohs(ip-ip_len);
 
/*
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw nat drops icmp packets from localhost

[Alexander V. Chernikov]

On 06.10.2011 14:42, Oleg Strizhak wrote:
 Hello, Andrey V. Elsukov!
 
 You wrote on 06.10.2011 at 13:38:
 
 On 06.10.2011 12:29, Oleg Strizhak wrote:
 After an investigation I've found out a very strange situation - it
 seems to me, that ipfw nat drops
 some (type 11?) icmp reply packets, whose udp request packets it
 hasn't rewritten/seen before, e.g:

 So, I wonder whether someone else has seen the same case under the
 similar circumstances? Isn't it a
 bug within ipfw nat module and is there any work-around/patch for
 that? I've surely googled, but in
 vain =( The only thing, that seems alike to my problem, is
 http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for
 8 branch didn't cure anything =(

 Can you describe how you did apply and test this patch?
 
 in a usual way =) Unfortunately, copy-pasted from the mentioned above
 page patch couldn't be applied w/ error:

svn diff -c 223835 svn://svn.freebsd.org/base/stable/8  ~/r223835.diff
Can you try the patch attached (just to be sure) ?

This is exact situation from this (and some related PRs) and this
revision definitely fixes it.

Btw, what is the value of net.inet.ip.fw.one_pass sysctl ?
Are you sure that ipfw is the single enabled firewall on this machine ?
Are you sure that system is using new kernel ?


 
 $ patch  ~/ip_fw_nat.patch
 Hmm...  Looks like a unified diff to me...
 The text leading up to this was:
 --
 |--- stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58
 2011 (r223834)
 |+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11
 2011 (r223835)
 --
 Patching file ip_fw_nat.c using Plan A...
 patch:  malformed patch at line 4: else
 
 the same results were obtained with combinations of -p5 -l and tail +2
 ~/ip_fw_nat.patch options  commands
 Finally, I modified the patch (which applies w/o a word =) a little bit
 w/o any difference to the original one:
 
  $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my
 --- /root/ip_fw_nat.patch   2011-10-04 14:08:32.0 +0400
 +++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400
 @@ -1,5 +1,5 @@
  stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 08:33:58
 2011 (r223834)
 -+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c  Thu Jul 7 09:29:11
 2011 (r223835)
 +--- ip_fw_nat.c.orig   2010-12-21 20:09:25.0 +0300
  ip_fw_nat.c2011-10-04 14:27:02.0 +0400
  @@ -263,17 +263,27 @@
  else
  retval = LibAliasOut(t-lib, c,
 
 then I recompiled the kernel, rebooted server and.. all is just the same =(
 
 WBR,
 Oleg
 

Index: sys/netinet/ipfw/ip_fw_nat.c
===
--- sys/netinet/ipfw/ip_fw_nat.c(revision 223834)
+++ sys/netinet/ipfw/ip_fw_nat.c(revision 223835)
@@ -263,17 +263,27 @@
else
retval = LibAliasOut(t-lib, c,
mcl-m_len + M_TRAILINGSPACE(mcl));
-   if (retval == PKT_ALIAS_RESPOND) {
-   m-m_flags |= M_SKIP_FIREWALL;
-   retval = PKT_ALIAS_OK;
-   }
-   if (retval != PKT_ALIAS_OK 
-   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
+
+   /*
+* We drop packet when:
+* 1. libalias returns PKT_ALIAS_ERROR;
+* 2. For incoming packets:
+*  a) for unresolved fragments;
+*  b) libalias returns PKT_ALIAS_IGNORED and
+*  PKT_ALIAS_DENY_INCOMING flag is set.
+*/
+   if (retval == PKT_ALIAS_ERROR ||
+   (args-oif == NULL  (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT ||
+   (retval == PKT_ALIAS_IGNORED 
+   (t-lib-packetAliasMode  PKT_ALIAS_DENY_INCOMING) != 0 {
/* XXX - should i add some logging? */
m_free(mcl);
args-m = NULL;
return (IP_FW_DENY);
}
+
+   if (retval == PKT_ALIAS_RESPOND)
+   m-m_flags |= M_SKIP_FIREWALL;
mcl-m_pkthdr.len = mcl-m_len = ntohs(ip-ip_len);
 
/*

Property changes on: sys/contrib/pf
___
Modified: svn:mergeinfo
   Merged /head/sys/contrib/pf:r222806


Property changes on: sys/contrib/dev/acpica
___
Modified: svn:mergeinfo
   Merged /head/sys/contrib/dev/acpica:r222806


Property changes on: sys/cddl/contrib/opensolaris
___
Modified: svn:mergeinfo
   Merged /head/sys/cddl/contrib/opensolaris:r222806


Property changes on: sys/amd64/include/xen
___
Modified: svn:mergeinfo
   Merged /head/sys/amd64/include/xen:r222806


Property changes on: sys
___
Modified: svn:mergeinfo
   Merged /head/sys:r222806

Re: kern/157867: [patch][ipfw] natd globalport support for ipfw nat

[ae]

Synopsis: [patch][ipfw] natd globalport support for ipfw nat

State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 28 10:17:04 UTC 2011
State-Changed-Why: 
Merged to stable/8. Thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=157867
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

ipfw nat and ftp

[David van Rensburg - PC Network]

Hi Guys,

IS there anyway to get ftp to work properly with ipfw and nat without opening 
all high ports ? In linux I used to use a module that handled it for me.
Now im getting a deny log as:

Jul 19 11:49:54 bsd kernel: ipfw: 450 Deny TCP 192.168.1.99:51446 
196.43.2.109:34049 out via rl0

Any help would be appreciated.


David van Rensburg
PC Network
Tel: 0215107600
Fax: 0215104165
www.pcnetwork.co.zahttp://www.pcnetwork.co.za/

This electronic communication and the attached file(s) are subject to terms and 
conditions which can be accessed on the following link:
http://www.pcnetwork.co.za/terms as well as the acceptable usage policy which 
can be accessed on: http://www.pcnetwork.co.za/aup
If you are unable to view the above, please contact 
supp...@pcnetwork.co.zamailto:supp...@pcnetwork.co.za for a copy.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[ae]

Synopsis: [ipfw] ipfw nat traceroute problem

State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 7 09:42:47 UTC 2011
State-Changed-Why: 
Merged to stable/7 and stable/8. Thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/129093: [ipfw] ipfw nat must not drop packets

[ae]

Synopsis: [ipfw] ipfw nat must not drop packets

State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 7 09:43:23 UTC 2011
State-Changed-Why: 
Merged to stable/7 and stable/8. Thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/144187: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

[Dmitriy Demidov]

 Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit
 statements State-Changed-From-To: open-feedback
 State-Changed-By: ae
 State-Changed-When: Tue Jun 28 05:29:45 UTC 2011
 State-Changed-Why:
 Can you still reproduce this on a supported release?
 Or maybe you can test your rules on head/ branch?
 There were some changes related to ipfw_nat.
 http://www.freebsd.org/cgi/query-pr.cgi?pr=144187

Hello,

I have retested this configuration on today's build of FreeBSD 9-CURRENT i386. 
It seems that this problem is soved now! I am unable to reproduce deadlock 
anymore. All is working just fine.

Thanks!
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/144187: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

[ae]

Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

State-Changed-From-To: feedback-closed
State-Changed-By: ae
State-Changed-When: Sat Jul 2 19:42:05 UTC 2011
State-Changed-Why: 
The submitter has reported that the problem is already fixed. Thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=144187
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Load balancing ipfw + NAT

[Grégoire Leroy]

Hi,

I try to use load-balancing with IPFW. I've 3 lines : 2 ADSL and 1 SDSL. I try 
to loadbalance http trafic on ADSL1(192.168.7.1) and ADSL2(192.168.6.1).

My gateway has 4 network devices. 1 for each line (em 1 -192.168.5.10, em2 - 
192.168.6.10, em3 -192.168.7.10), and one for local network (em0 - 
192.168.4.1)

On my gateway, there are 3 nat instances :
natd -p 8868 -dynamic -interface em3
natd -p 8869 -dynamic -interface em2
natd -p 8868 -dynamic -interface em1
 
Here is my config relative to the load balanc :

$cmd 300 divert 8868 ip from any to any via $adsl1_if
$cmd 301 divert 8869 ip from any to any via $adsl2_if
$cmd 302 divert 8870 ip from any to any via $sdsl_if

$cmd 00320 check-state

$cmd 0670 prob 0.5 skipto 17000 tcp from $clients to any $tcp_web setup $ks
$cmd 0671 skipto 19000 tcp from $clients to any $tcp_web setup $ks

$cmd 017000 divert 8868 ip from $clients to any in
$cmd 017500 divert 8868 ip from $clients to any out 
$cmd 017700 allow all from any to any 
$cmd 019000 divert 8869 ip from $clients to any out 
$cmd 019500 divert 8869 ip from $clients to any in
$cmd 19700 allow all from any to any 

$cmd 17550 fwd $isp1 ip from 192.168.7.10 to any 
$cmd 19550 fwd $isp2 ip from 192.168.6.10 to any 
$cmd 23500 fwd $isp3 ip from 192.168.5.10 to any 

$cmd 65534 allow all from any to any

ipfw show :

00300 16789 17438940 divert 8868 ip from any to any via em3 
00301 00 divert 8869 ip from any to any via em2 
00302 00 divert 8870 ip from any to any via em1 

00670  6409  7934908 prob 0.50 skipto 17000 tcp from 192.168.4.2 to any 
dst-port 80,443,25,3128 setup keep-state
00671 21464 26576872 skipto 19000 tcp from 192.168.4.2 to any dst-port 
80,443,25,3128 setup keep-state

17000  114559132 divert 8868 ip from 192.168.4.2 to any in
17500 00 divert 8868 ip from 192.168.4.2 to any out
17700  6409  7934908 allow ip from any to any
19000 00 divert 8869 ip from 192.168.4.2 to any out
19500  3848   198584 divert 8869 ip from 192.168.4.2 to any in

The skipto seems good, so I don't understand why I don't catch packet with a 
tcpdump on em2 : it seems that all web traffic pass by em3.

Can someone explain me what is wrong ?

PS : my work is based on http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-
August/000399.html

Regards,
Grégoire leroy



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/144187: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

[ae]

Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Tue Jun 28 05:29:45 UTC 2011
State-Changed-Why: 
Can you still reproduce this on a supported release? 

Or maybe you can test your rules on head/ branch?
There were some changes related to ipfw_nat.

http://www.freebsd.org/cgi/query-pr.cgi?pr=144187
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157867: [patch][ipfw] natd globalport support for ipfw nat

[ae]

Synopsis: [patch][ipfw] natd globalport support for ipfw nat

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: ae
Responsible-Changed-When: Tue Jun 14 06:36:57 UTC 2011
Responsible-Changed-Why: 
Over to maintainer(s).


http://www.freebsd.org/cgi/query-pr.cgi?pr=157867
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157689: [ipfw] ipfw nat config does not accept nonexistent interfaces

[linimon]

Old Synopsis: ipfw nat config does not accept nonexistent interfaces
New Synopsis: [ipfw] ipfw nat config does not accept nonexistent interfaces

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jun 9 21:27:53 UTC 2011
Responsible-Changed-Why: 
Reclassify and assign.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157689
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[ae]

Synopsis: [ipfw] ipfw nat traceroute problem

State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:53:46 UTC 2011
State-Changed-Why: 
Patched in head/.

http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/129093: [ipfw] ipfw nat must not drop packets

[ae]

Synopsis: [ipfw] ipfw nat must not drop packets

State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:54:30 UTC 2011
State-Changed-Why: 
Patched in head/.

http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat

[ae]

Synopsis: [ipfw] mtr does not work if I use ipfw nat

State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:55:06 UTC 2011
State-Changed-Why: 
Patched in head/.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157379
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat

[Andrey V. Elsukov]

The following reply was made to PR kern/157379; it has been noted by GNATS.

From: Andrey V. Elsukov a...@freebsd.org
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:  
Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
Date: Mon, 06 Jun 2011 09:51:09 +0400

 Hi,
 
 Can you test this patch?
 http://people.freebsd.org/~ae/ipfw_nat.diff
 
 -- 
 WBR, Andrey V. Elsukov
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/129093: [ipfw] ipfw nat must not drop packets

[ae]

Synopsis: [ipfw] ipfw nat must not drop packets

State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 06:57:40 UTC 2011
State-Changed-Why: 
This seems to be a duplicate of kern/157379.
Can you confirm that proposed patch fixes this issue?

http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat

[ae]

Synopsis: [ipfw] mtr does not work if I use ipfw nat

State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 06:59:19 UTC 2011
State-Changed-Why: 
Feedback requested.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157379
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[ae]

Synopsis: [ipfw] ipfw nat traceroute problem

State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 07:00:37 UTC 2011
State-Changed-Why: 
Can you test this patch?
http://people.freebsd.org/~ae/ipfw_nat.diff

http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[ten]

The following reply was made to PR kern/122109; it has been noted by GNATS.

From: ten ten@gmail.com
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:  
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Mon, 6 Jun 2011 21:38:36 +0700

 --000e0cd22f68002b4704a50c0f97
 Content-Type: text/plain; charset=ISO-8859-1
 
 It seems I have too old version, and patch not applicable to me
 
 7.3-STABLE FreeBSD 7.3-STABLE #2 amd64
 
 src/sys/netinet/ip_fw_nat.c
 __FBSDID($FreeBSD: src/sys/netinet/ip_fw_nat.c,v 1.2.2.2 2008/06/23
 14:15:53 mav Exp $);
 
 --000e0cd22f68002b4704a50c0f97
 Content-Type: text/html; charset=ISO-8859-1
 
 It seems I have too old version, and patch not applicable to 
mebrbr7.3-STABLE FreeBSD 7.3-STABLE #2 
amd64brbrsrc/sys/netinet/ip_fw_nat.cbr__FBSDID(quot;$FreeBSD: 
src/sys/netinet/ip_fw_nat.c,v 1.2.2.2 2008/06/23 14:15:53 mav Exp $quot;);br
 br
 
 --000e0cd22f68002b4704a50c0f97--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[Alexander V. Chernikov]

The following reply was made to PR kern/122109; it has been noted by GNATS.

From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru, a...@freebsd.org
Cc:  
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Fri, 03 Jun 2011 10:08:13 +0400

 Problem is actually a bit deeper.
 
 Before libalias-based kernel nat appears natd uses PKT_ALIAS_IGNORE
 retrun code to drop packets iff PKT_ALIAS_DENY_INCOMING flag is set:
 
status = LibAliasIn (mla, buf, IP_MAXPACKET);
 if (status == PKT_ALIAS_IGNORED 
 mip-dropIgnoredIncoming) {
 
 if (verbose)
 printf ( dropped.\n);
 
 
 Current ipfw nat (and ng_nat) implementation simply drops every packet
 with PKT_ALIAS_IGNORE return code:
 
if (retval != PKT_ALIAS_OK 
retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
 /* XXX - should i add some logging? */
 m_free(mcl);
 
 Most of PKT_ALIAS_IGNORED are returned in case of no state is found (the
 rest are some (possibly) very rare unknown errors/handlers error).
 
 Libalias automatically create new state for every packet not found in
 aliasing database if it reasonable to do so (TCP/UDP packets is
 definitely reasonable since they represent logical sessions, icmp
 req/reply is reasonable too, etc..). On the opposite, there is no reason
 for creating state for packets signaling some existing session errors
 (icmp unreach, etc..) since such packets are rare/unidirectional and no
 reply is needed.
 
 The only 2 places states are not created (not mentioning
 PKT_ALIAS_PROXY_ONLY and PKT_ALIAS_DENY_INCOMING modes) are
 IcmpAliasIn2()|IcmpAliasOut2() functions.
 
 Those function dispatches various ICMP notification and tries to map
 those notification to existing states using original packet header
 within ICMP message. If such session is not found (PR case, since
 usually locally-originated packets are not passed to libalias and no
 replies are transmitted due to traceroute specific) return code is set
 to PKT_ALIAS_IGNORED.
 
 As a result: restoring original behavior should not break anything.
 
 This patch seems to fix the problem:
 
 Index: ip_fw_nat.c
 ===
 --- ip_fw_nat.c (revision 221263)
 +++ ip_fw_nat.c (working copy)
 @@ -267,8 +267,9 @@
 m-m_flags |= M_SKIP_FIREWALL;
 retval = PKT_ALIAS_OK;
 }
 -   if (retval != PKT_ALIAS_OK 
 -   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
 +   if (retval == PKT_ALIAS_ERROR || retval ==
 PKT_ALIAS_UNRESOLVED_FRAGMENT ||
 +   (retval == PKT_ALIAS_IGNORED 
 +(t-lib-packetAliasMode  PKT_ALIAS_DENY_INCOMING))) {
 /* XXX - should i add some logging? */
 m_free(mcl);
 args-m = NULL;
 
 
 Something similar should be applied to ng_nat.c
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat

[Alexander V. Chernikov]

The following reply was made to PR kern/157379; it has been noted by GNATS.

From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:  
Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
Date: Mon, 30 May 2011 15:23:34 +0400

 This seems to be a duplicate of kern/122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat

[linimon]

Old Synopsis: mtr does not work if I use ipfw nat
New Synopsis: [ipfw] mtr does not work if I use ipfw nat

Responsible-Changed-From-To: freebsd-i386-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun May 29 23:40:09 UTC 2011
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=157379
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[ten]

The following reply was made to PR kern/122109; it has been noted by GNATS.

From: ten d...@211.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:  
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Mon, 18 Apr 2011 22:41:45 +0700

 --20cf30563995a1b54304a1333ac0
 Content-Type: text/plain; charset=ISO-8859-1
 
 Work's fine.
 mfc ?
 
 
 --- sys/netinet/libalias/alias.c.orig   2010-09-10 03:28:46.0 +0700
 +++ sys/netinet/libalias/alias.c2011-04-18 22:05:07.0 +0700
 @@ -423,7 +423,7 @@
 }
 return (PKT_ALIAS_OK);
 }
 -   return (PKT_ALIAS_IGNORED);
 +   return (PKT_ALIAS_OK);
  }
 
 --20cf30563995a1b54304a1333ac0
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Work#39;s fine.brmfc ?brbrbr--- sys/netinet/libalias/alias.c.orig=
 =A0=A0 2010-09-10 03:28:46.0 +0700br+++ sys/netinet/libalias/alia=
 s.c=A0=A0=A0=A0=A0=A0=A0 2011-04-18 22:05:07.0 +0700br@@ -423,7 +=
 423,7 @@br=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }br
 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return (PKT_ALIAS_OK);br=A0=
 =A0=A0=A0=A0=A0=A0 }br-=A0=A0=A0=A0=A0=A0 return (PKT_ALIAS_IGNORED);br=
 +=A0=A0=A0=A0=A0=A0 return (PKT_ALIAS_OK);br=A0}brbr
 
 --20cf30563995a1b54304a1333ac0--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup

[hrs]

Synopsis: [ipfw] Problem with loading of ipfw NAT rules during system startup

Responsible-Changed-From-To: freebsd-ipfw-hrs
Responsible-Changed-By: hrs
Responsible-Changed-When: Wed Jan 5 01:05:33 UTC 2011
Responsible-Changed-Why: 
Take.

http://www.freebsd.org/cgi/query-pr.cgi?pr=148928
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

IPFW - NAT - two gateway -HELP

[Nima Khoramdin]

hello .

I installed freebsd 7.1 with ifpw - nat - dummynet with below kernel config
:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET
options HZ=1000


and i have three NICs , with internal webserver works with nat:

default gw : 172.16.1.5

(in natd.conf :

port 8668
interface nfe0
use_sockets yes

# redirect to webserver
redirect_port tcp 192.168.1.121:80 172.16.1.5:80)
   webserver
)

it works fine.


   ISP1   ISP2
wireless connection   ADSL
2mb/2mb 1mb/1mb
172.16.1.1/23   10.0.0.1/23

 |  |   
 |  |   
 |  |   
 |  |   
staticstatic
 172.16.1.5 10.0.1.15
   *aue0***tun0*
   *  FreeBSD  *
   *ep0*

 192.168.1.254
 |  
 |  
   *
Private LAN
  192.168.1.0/24
 |
 |
 |
 webserver

   192.168.1.121


how to use of this two gateways for my internal webserver with ipfw  nat

i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can see my internal
webserver page with two  separated ISPs ) not load balance . i want to use
two ISPs at the same time .

sorry for my bad explanation
thanx
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: IPFW - NAT - two gateway -HELP

[Julian Elischer]

On 1/1/11 10:42 PM, Nima Khoramdin wrote:

hello again

ok Maybe I was wrong explain. I already have an ip address in my network is
working with NAT ( nat to internal web server )  , i want to add another NIC
with a new isp (IP) for backup, and new nat rule.

how can i set two separated  gateways on freebsd.

thanx


so, your addresses are NOT 172... and 10.?

Assuming you have a way to get the externally sourced packets to your
interface, then you have a couple of options.
Firstly you will need to either use two natd instances, or single
natd using tow of the new 'instance' sections.

(quoting from the natd man page...)
   start quote---
 Options can be divided to several sections.  Each 
section
 applies to own natd instance.  This ability allows 
to config-
 ure one natd process for several NAT instances.  The 
first
 instance that always exists is a default 
instance.  Each

 another instance should begin with

   instance instance_name

 At the next should be placed a configuration 
option.  Exam-

 ple:

   # default instance
   port 8668
   alias_address 158.152.17.1

   # second instance
   instance dsl1
   port 
   alias_address 192.168.0.1

 Trailing spaces and empty lines are ignored.  A `#' 
sign will

 mark the rest of the line as a comment.

 -instance instancename
 This option switches command line options processing 
to con-
 figure instance instancename (creating it if 
necessary) till
 the next -instance option or end of command line.  
It is eas-
 ier to set up multiple instances in the 
configuration file
 specified with the -config option rather than on a 
command

 line.
   - end quote-

you can then use the ipfw 'fwd' command to decide which goes where
or alternatively, you can also use the new multiple routing table feature
to decide which sessions go to which gateway.



ISP1  ISP2
wireless connection   ADSL
2mb/2mb 1mb/1mb
172.16.1.1/23   10.0.0.1/23

  | |
  | |
  | |
  | |
 static   static
  172.16.1.510.0.1.15
*aue0***tun0*
*  FreeBSD *
*ep0*

 192.168.1.254
 |
 |
   *
Private LAN
  192.168.1.0/24
  |
  |
  |
  webserver

192.168.1.121


how to use of this two gateways for my internal webserver with ipfw   nat

i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can see my internal
webserver page with two  separated ISPs ) not load balance . i want to use
two ISPs at the same time .


do you REALLY have 172.16.1.5 and 10.0.1.15 as your IP addresses?
If so there is no way you can be reached from the outside..
unless you have made an agreement with the ISPs to forward some address/port
to you.
They are doing NAT on your outgoing sessions as it is already..




  sorry for my bad explanation

thanx
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/145167: [ipfw] ipfw nat does not follow its documentation

[ae]

Synopsis: [ipfw] ipfw nat does not follow its documentation

State-Changed-From-To: open-closed
State-Changed-By: ae
State-Changed-When: Fri Dec 10 05:26:02 UTC 2010
State-Changed-Why: 
Merged to stable/8.

http://www.freebsd.org/cgi/query-pr.cgi?pr=145167
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[Alexander V. Chernikov]

The following reply was made to PR kern/122109; it has been noted by GNATS.

From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:  
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Wed, 22 Sep 2010 01:24:40 +0400

 Problem can be fixed with a small patch:
 
 --- /usr/src/sys/netinet/libalias/alias.c.orig  2010-09-22
 01:07:19.0 +0400
 +++ /usr/src/sys/netinet/libalias/alias.c   2010-09-22
 01:11:11.0 +0400
 @@ -432,7 +432,7 @@
 }
 return (PKT_ALIAS_OK);
 }
 -   return (PKT_ALIAS_IGNORED);
 +   return (PKT_ALIAS_OK);
  }
 
 
 IcmpAliasIn2() doesn't create state for incoming packets (like
 IcmpAliasIn1() does)
 
 IcmpAliasIn2() is called only in case of
 ICMP_UNREACH|ICMP_SOURCEQUENCH|ICMP_TIMXCEED|ICMP_PARAMPROB
 
 If incoming icmp packet of given type is not found in internal state
 table we can just pass it to the host system (back to ipfw or netgraph
 hook, really) without even creating state
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/122109: [ipfw] ipfw nat traceroute problem

[linimon]

Synopsis: [ipfw] ipfw nat traceroute problem

Responsible-Changed-From-To: piso-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Sep 16 17:10:45 UTC 2010
Responsible-Changed-Why: 
piso's bit has been returned.

http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup

[Thomas Sandford]

The following reply was made to PR kern/148928; it has been noted by GNATS.

From: Thomas Sandford freebsdu...@paradisegreen.co.uk
To: bug-follo...@freebsd.org, fmy...@gmail.com
Cc:  
Subject: Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during
 system startup
Date: Sun, 12 Sep 2010 19:24:39 +0100

 The problem seems to be that ipdivert.ko is not loaded prior to the 
 /etc/rc.d/ipfw script being run.
 
 /etc/rc.d/natd _does_ load this module so restarting the firewall after 
 boot sequence is complete works.
 
 I've fixed this on my own system by adding
 === cut here 8===
  if checkyesno natd_enable; then
  required_modules=$required_modules ipdivert
  fi
 === cut here 8===
 at the end of the ipfw_prestart() function in /etc/rc.d/ipfw
 
 This appears to be a regression between the out of the box states for 
 8.0-RELEASE and 8.1-RELEASE.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup

[linimon]

Old Synopsis: Problem with loading of ipfw NAT rules during system startup
New Synopsis: [ipfw] Problem with loading of ipfw NAT rules during system 
startup

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 25 17:48:11 UTC 2010
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=148928
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: Problem with ipfw nat and packet to local services

[Ian Smith]

On Mon, 19 Jul 2010, Mamontov Roman wrote:
  Hello, Ian.
 
   UDP port 33564 on this box (xxx.xxx.xxx.xxx) is not redirected to any 
   other address:port, and you have specified deny_in (-deny_incoming in 
   natd-speak) so, well, you got what you asked for ..
  
   See the description under -deny_incoming and the explanation of what 
   happens to incoming packets under -alias_address in natd(8) .. the nat 
   description in ipfw(8) is still a bit thin, so natd(8) is still useful.
  
   Without deny_in, new inbound packets should be passed to the local 
   machine - so you will then need firewall rules to restrict which local 
   ports are to be accessible for connections from the outside.
  
   cheers, Ian
  
  I remove option deny_in from nat configuration. But inbound packets not 
  passed to the
  local services.
  
  #ipfw nat show config
  ipfw nat 1 config ip xxx.xxx.xxx.xxx
  
  #ipfw show
  0003559 4703 nat 1 log ip from any to any via ext_if1
  65000   51044734 allow ip from any to any
  65535 58083 11212917 deny ip from any to any

Hi Mamontov,

What's the value of sysctl net.inet.ip.fw.one_pass ?  It needs to be 0 
so that packets will re-enter the firewall after NAT processing.

Otherwise, it might help to

a) run 'ipfw zero' before any tests .. I'm wondering about all those 
packets hitting rule 65535; were they from before adding rule 65000?

b) add some count rules before and after nat, to show all packets 
that may be eligible for NAT translation, maybe something like:

00020 count log ip from any to any in recv ${ext_if}
00022 count log ip from any to any out xmit ${ext_if}
00024 count log ip from any to any out recv ${int_if} xmit ${ext_if}

00035 nat ...

00040 count log ip from any to any in recv ${ext_if}
00042 count log ip from any to any out xmit ${ext_if}
00044 count log ip from any to any out recv ${int_if} xmit ${ext_if}

So you actually get to see the flow of packets before and after nat, 
both to/from the local box and packets mapped to/rom inside addresses.
Again, an 'ipfw zero' before tests will make packet counts clearer.

Of course something like '# tcpdump -pn -i ext_if' will also show all 
packets via ext_if in some detail.  Be more specific if just looking for 
some particular flows, like maybe appending 'udp port N' to that.

That is, try to follow packets you'd expect to be coming in for services 
on the local box so if they are disappearing, you'll know where or why.  
'netstat -finet -an' will show all those services that are listening.

If that doesn't help, we'll need more information.

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: Problem with ipfw nat and packet to local services

[Ian Smith]

On Mon, 19 Jul 2010, Mamontov Roman wrote:
   What's the value of sysctl net.inet.ip.fw.one_pass ?  It needs to be 0 
   so that packets will re-enter the firewall after NAT processing.
  
   Otherwise, it might help to
  
   a) run 'ipfw zero' before any tests .. I'm wondering about all those 
   packets hitting rule 65535; were they from before adding rule 65000?
  
   b) add some count rules before and after nat, to show all packets 
   that may be eligible for NAT translation, maybe something like:
  
   00020 count log ip from any to any in recv ${ext_if}
   00022 count log ip from any to any out xmit ${ext_if}
   00024 count log ip from any to any out recv ${int_if} xmit ${ext_if}
  
   00035 nat ...
  
   00040 count log ip from any to any in recv ${ext_if}
   00042 count log ip from any to any out xmit ${ext_if}
   00044 count log ip from any to any out recv ${int_if} xmit ${ext_if}
  
   So you actually get to see the flow of packets before and after nat, 
   both to/from the local box and packets mapped to/rom inside addresses.
   Again, an 'ipfw zero' before tests will make packet counts clearer.
  
   Of course something like '# tcpdump -pn -i ext_if' will also show all 
   packets via ext_if in some detail.  Be more specific if just looking for 
   some particular flows, like maybe appending 'udp port N' to that.
  
   That is, try to follow packets you'd expect to be coming in for services 
   on the local box so if they are disappearing, you'll know where or why.  
   'netstat -finet -an' will show all those services that are listening.
  
   If that doesn't help, we'll need more information.
  
   cheers, Ian
  
  # sysctl net.inet.ip.fw.one_pass
  net.inet.ip.fw.one_pass: 0
  
  # ipfw show 20-49
  00020402016 count log ip from any to me dst-port 22 in recv ext_if1
  00021 0   0 count log ip from me 22 to any out xmit ext_if1
  00035 13192 9028716 nat 1 ip from any to any via ext_if1
  00040 0   0 count log ip from any to me dst-port 22 in recv ext_if1
  00041 0   0 count log ip from me 22 to any out xmit ext_if1

Ouch.  It does look like nat is just swallowing the ssh packets on the 
inbound pass .. these surely should appear again after NAT (unchanged).

  # ipfw nat show config
  ipfw nat 1 config ip xxx.xxx.xxx.xxx
  
  # tcpdump -pn -i ext_if1 'host yyy.yyy.yyy.yyy'
  14:12:48.885011 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]
  14:12:51.23 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]
  14:12:54.884966 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]
  14:12:57.884090 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460], length 0
  14:13:00.885131 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460], length 0
  14:13:03.887094 IP yyy.yyy.yyy.yyy.2777  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  2880611174, win 65535, options [mss 1460], length 0

Ah, if that 'TS' means TSO - tcpdump(1) doesn't mention either - then 
from the last section of ipfw(8):

 Due to the architecture of libalias(3), ipfw nat is not compatible with
 the TCP segmentation offloading (TSO).  Thus, to reliably nat your net-
 work traffic, please disable TSO on your NICs using ifconfig(8).

ifconfig ext_if1 ?

  Output
  # netstat -finet -an | grep yyy.yyy.yyy.yyy
  is blank.
 
  Without rule 35 nat 1 ip from any to any via ext_if1 inbound packet to ssh 
  (for example)
  pass correctly.
  
  # ipfw delete 35
  tcpdump -pn -i ext_if 'host yyy.yyy.yyy.yyy'
  14:21:45.467233 IP yyy.yyy.yyy.yyy.2790  xxx.xxx.xxx.xxx.22: Flags [S], seq 
  376101413, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]
  14:21:45.467670 IP xxx.xxx.xxx.xxx.22  xxx.xxx.xxx.xxx.2790: Flags [S.], 
  seq 3270699616, ack 376101414, win 65535, options [mss 1460,nop,wscale 
  3,nop,nop,TS[|tcp]

I guess that dest is just mis-obscured, ie yyy.yyy.yyy.yyy:2790

  14:21:45.468960 IP yyy.yyy.yyy.yyy.2790  xxx.xxx.xxx.xxx.22: Flags [.], ack 
  1, win 33304, options [nop,nop,TS val 40088404 ecr 1166915706], length 0
  14:21:45.527438 IP xxx.xxx.xxx.xxx.22  yyy.yyy.yyy.yyy.2790: Flags [P.], 
  ack 1, win 8326, options [nop,nop,TS val 1166915766 ecr 40088404], length 40
  
  # netstat -finet -an | grep yyy.yyy.yyy.yyy
  tcp4   0  0 xxx.xxx.xxx.xxx.22yyy.yyy.yyy.yyy.2790
  FIN_WAIT_2
  
  00020  8 1403 count log ip from any to me dst-port 22 in recv ext_if1
  00021  6 2280 count log ip from me 22 to any out xmit ext_if1
  00040  8 1403 count log ip from any to me dst-port 22 in recv ext_if1
  00041  6 2280 count log ip from me 22 to any out xmit ext_if1
  
  Any ideas?

[later: if you had TSO enabled on the interface

ipfw nat

[Michal]

Hello.

I am currently trying to replace pf with ipfw. NAT is the biggest 
missing bit in my configuration.


I want to go with ipfw nat (libalias) because I've been told it works 
fine with dynamic rules (unlike divert) - is that statement correct?


If yes, then could somebody point me to some kind of howto or manual 
please. All I'm finding in handbook, manuals and google is about divert 
and not ipfw nat.


Thanks, M.
--
The real problem is not whether machines think but whether men do. -B. 
F. Skinner


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/145167: [ipfw] ipfw nat does not follow its documentation

[linimon]

Old Synopsis: ipfw nat does not follow its documentation
New Synopsis: [ipfw] ipfw nat does not follow its documentation

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Mar 29 19:57:57 UTC 2010
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=145167
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

features request for kernel's libalias and ipfw nat

[Dmitriy Demidov]

Hi list,

I just wonder how hard it would be to implement a following list of features:
- ability to use proxy_rule statement in ipfw nat (natd -proxy_rule)
- ability to see actual content of libalias nat table (ipfw nat 1 show table)
- ability to use one aliasing table in multi nat instances (natd -globalport)

Would it be posible to see this features in ipfw nat some day?
How mach would it cost to sponsore development of this features directly (if 
it is the only way to get them)?  :)

Thanks.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/144187: [ipfw] deadlock using multiple ipfw nat and multiple limit statements

[linimon]

Old Synopsis: deadlock using multiple ipfw nat and multiple limit statements
New Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit 
statements

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 22 05:28:06 UTC 2010
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=144187
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/143653: [ipfw] [patch] ipfw nat redirect_port buf is too small error

[linimon]

Old Synopsis: ipfw nat redirect_port buf is too small error
New Synopsis: [ipfw] [patch] ipfw nat redirect_port buf is too small error

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 8 03:54:50 UTC 2010
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=143653
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

ipfw nat

[Michael Sierchio]

Unless I'm mistaken, there appears no way to cause ipfw's internal
nat mechanism to log dropped packets.  This is a considerable loss
of functionality from using natd.  Is there a reason for this?

- M

-- 
Michael Sierchio
+1 415 378 1182
PO Box 9036 Berkeley CA 94709 US
ku...@tenebras.com
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

dansguardian, ipfw, nat question

[Rakort]

Hello all

 

Trying to configure my gateway box running FBSD 7.2 to provide content
filtering services for some or all clients on a my network.

 

The box is configured with natd and running IPFW.  I like this combination
and have been using it successfully for years.  Not real interested to
changing to squid or pf or whatever else may be known (or better documented)
to work with dansguardian.

 

Dansguardian seems to be the preferred option for content filtering as near
as I can tell.  There is lots of documentation out there for configuring
dans with squid.  I can't find much of anything for IPFW / NAT

 

So, the question is, can this be done?  I've seen one or two suggestions out
there giving a brief description of how to use the fwd command to send
packets to dans but unfortunately I am not smart enough to implement that
here.

 

Any help, thoughts, or references would be appreciated

 

thanks

Brian

 

here is a boiled down set of rules that I use:

 

#!/bin/sh

 

cmd=ipfw add

skip=skipto 700

oif=dc0

iif=re0

log=log logamount 1000

ks=keep-state

 

ipfw -f flush

 

$cmd 098 allow all from any to any via $iif #
Allow LAN traffic

$cmd 099 allow all from any to any via lo0 #
Allow loopback traffic

 

$cmd 105 divert natd all from any to any in via $oif   # check if
packet is inbound and nat address if it is

$cmd 110 check-state
# Allow packet if it has previous been added to the dynamic rules table

 

### Authorized icmp / udp outbound packets

 $cmd 200 $skip  icmp from any to any out via $oif   $ks
# ping

 $cmd 201 $skip  udp  from any to any 123 out via $oif   $ks
# time

 $cmd 203 $skip $log udp  from any to xx.xxx.xx.1 67  out via $oif   $ks
# DHCP

 $cmd 205 $skip  udp  from any to any 53  out via $oif   $ks
# DNS

 

### Authorized tcp outbound packets

 $cmd 301 $skip  tcp from any to any 25  out via $oif setup $ks
# mail

 $cmd 303 $skip $log tcp from any to any 43  out via $oif setup $ks
# whois

 $cmd 305 $skip  tcp from any to any 80  out via $oif setup $ks
# http

 $cmd 306 $skip  tcp from any to any 110 out via $oif setup $ks
# mail

 $cmd 307 $skip  tcp from any to any 119 out via $oif setup $ks
# USENET

 $cmd 308 $skip  tcp from any to any 443 out via $oif setup $ks
# Secure http

 $cmd 310 $skip $log tcp from any to any 23  out via $oif setup $ks
# telnet

 

### Everything else outbound is dropped and logged

$cmd 351 deny log logamount 1 all from any to any out via $oif
# everything else

 

### Allow these incoming connections

 $cmd 360 allow $log udp from xx.xxx.xxx.x   to any 68in via $oif $ks
# DHCP

 $cmd 363 allow  tcp from anyto me  80in via $oif setup
$ks   # Incoming http connections

 

### May Consider Allowing these incoming connections

 $cmd 396 allow $log tcp  from anyto any 113 in via $oif   limit
src-addr 4  # Ident packets.

 $cmd 398 allow $log icmp from anyto any icmptype 3,11 in via $oif
limit src-addr 2# Allow out  in console traceroot command

 

### deny various incoming packets

 $cmd 401 deny $log all from 192.168.0.0/16  to any in via $oif  # RFC 1918
private IP

 $cmd 402 deny $log all from 172.16.0.0/12   to any in via $oif  # RFC 1918
private IP

 $cmd 403 deny $log all from 10.0.0.0/8  to any in via $oif  # RFC 1918
private IP

 $cmd 404 deny $log all from 127.0.0.0/8 to any in via $oif  # loopback

 $cmd 405 deny $log all from 0.0.0.0/8   to any in via $oif  # loopback

 $cmd 406 deny $log all from 169.254.0.0/16  to any in via $oif  # DHCP
auto-config

 $cmd 407 deny $log all from 192.0.2.0/24to any in via $oif  # reserved
for docs

 $cmd 408 deny $log all from 204.152.64.0/23 to any in via $oif  # Sun
cluster

 $cmd 409 deny $log all from 224.0.0.0/3 to any in via $oif  # Class D 
E multicast

 

### deny various incoming packets

 $cmd 448 reset $log tcp  from any to me  113 in via $oif limit src-addr 4 #
This sends a RESET to all ident packets.

 $cmd 449 deny  $log tcp  from any to any 113 in via $oif #
Deny ident

 $cmd 450 deny  $log icmp from any to any icmptype 5  in via $oif
# Stop  log external redirect requests.

 $cmd 451 deny  $log icmp from any to any in via $oif #
Deny pings from the world

 $cmd 452 deny  $log all  from any to any in frag #
Fragmented Packets

 $cmd 453 deny  $log all  from any to any 137,138,139,81 in via $oif  #
Deny all Netbios service  MS/Windows hosts2 name server

 $cmd 454 deny  $log all  from any to any frag in via $oif#
Deny any late arriving packets

 $cmd 455 deny  $log tcp  from any to any established in via $oif #
Deny ACK packets that did not match the dynamic rule table

 $cmd

Re: kern/137346: ipfw nat redirect_proto is broken

[remko]

Synopsis: ipfw nat redirect_proto is broken

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: remko
Responsible-Changed-When: Sun Aug 2 09:52:25 UTC 2009
Responsible-Changed-Why: 
Over to maintainer.

http://www.freebsd.org/cgi/query-pr.cgi?pr=137346
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw nat and localy initiated UDP traffic (bad udp cksum)

[Dmitriy Demidov]

On Thursday 16 July 2009, Chuck Swiger wrote:
 On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote:
  Update about this issue.
  There is somthing wrong with UDP pass through - ipfw nat makes it
  bad cksum.

 tcpdump receives local network traffic before the checksums are
 computed (especially if hardware checksums are enabled); this is a non-
 issue, although you could confirm by sniffing the traffic from an
 external machine like a laptop.

 Regards,

Wow! :) Thank you Chuck for this hint! I catch the problem!
My em0 have offload options on, so I turned them off and now all is working as 
expected.


before:
===
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
ether 00:20:ed:91:97:93
inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255
media: Ethernet autoselect (100baseTX full-duplex)
status: active
===


after:
===
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=98VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
ether 00:20:ed:91:97:93
inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255
media: Ethernet autoselect (100baseTX full-duplex)
status: active
===


dmesg | grep em0
===
em0: Intel(R) PRO/1000 Network Connection 6.9.6 port 0xa000-0xa03f mem 
0xdb10-0xdb11 irq 21 at device 9.0 on pci2
em0: [FILTER]
em0: Ethernet address: 00:20:ed:91:97:93
===


pciconf -lv
===
e...@pci0:2:9:0: class=0x02 card=0x30138086 chip=0x100e8086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (82540EM)'
class  = network
subclass   = ethernet
===



Do this looks like a bug (em drivers, nat, etc...) or not?
Should I make new PR for this problem?

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: kern/129093: [ipfw] ipfw nat must not drop packets

[linimon]

Old Synopsis: ipfw nat must not drop packets
New Synopsis: [ipfw] ipfw nat must not drop packets

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Nov 23 18:02:44 UTC 2008
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

ipfw nat/natd

[Prokofiev S.P.]

I have a problem at the scheme:

( gw ) - (   nat_router  ) - ( https )
  real.ip0real.ip1 10.19.90.110.19.90.2

If I use ipfw+natd on nat_router then redirect to https server and to 
nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to 
nat_router local address is fail. This is bug ?



ipfw+nat schema

- on nat_router
  - ipfw rules
ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \
   redirect_port tcp 10.19.90.2:443 443
ipfw add 500 nat 1 log ip from any to any via vlan2 //  nat
  - iperf -s -p 5000

- on gw
  - iperf -p 5000 -c real.ip1

tcpdump -np -i vlan2 host real.ip0


18:36:08.170034 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) 
win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785027736 0,sackOK,eol
18:36:08.170093 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785027736
18:36:11.170239 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785027736
18:36:11.208523 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) 
win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785030736 0,sackOK,eol
18:36:11.208554 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785030736
18:36:14.208712 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785030736
18:36:14.448772 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) 
win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785033936 0,sackOK,eol
18:36:14.448802 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785033936
18:36:17.449225 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 
785033936
18:36:17.689771 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) 
win 65535 mss 1460,sackOK,eol
18:36:17.689801 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:20.689736 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:20.944763 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) 
win 65535 mss 1460,sackOK,eol
18:36:20.944794 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:23.945252 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol



Thanks all!

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

ipfw nat/natd

[Prokofiev S.P.]

I have a problem at the scheme:

( gw ) - (   nat_router  ) - ( https )
  real.ip0real.ip1 10.19.90.110.19.90.2

If I use ipfw+natd on nat_router then redirect to https server and to 
nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect to 
nat_router local address is fail. This is bug ?



ipfw+nat schema

- on nat_router
  - ipfw rules
ipfw nat 1 config if vlan2 log redirect_port tcp 10.19.90.1:5000 5000 \
   redirect_port tcp 10.19.90.2:443 443
ipfw add 500 nat 1 log ip from any to any via vlan2 //  nat
  - iperf -s -p 5000

- on gw
  - iperf -p 5000 -c real.ip1

tcpdump -np -i vlan2 host real.ip0


18:36:08.170034 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) win 
65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785027736 0,sackOK,eol
18:36:08.170093 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785027736
18:36:11.170239 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785027736
18:36:11.208523 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) win 
65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785030736 0,sackOK,eol
18:36:11.208554 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785030736
18:36:14.208712 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785030736
18:36:14.448772 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) win 
65535 mss 1460,nop,wscale 2,nop,nop,timestamp 785033936 0,sackOK,eol
18:36:14.448802 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785033936
18:36:17.449225 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3232246011 785033936
18:36:17.689771 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) win 
65535 mss 1460,sackOK,eol
18:36:17.689801 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:20.689736 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:20.944763 IP real.ip0.60950  real.ip1.5000: S 3167071663:3167071663(0) win 
65535 mss 1460,sackOK,eol
18:36:20.944794 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol
18:36:23.945252 IP real.ip1.5000  real.ip0.60950: S 655190881:655190881(0) ack 
3167071664 win 65535 mss 1460,nop,wscale 3,sackOK,eol


Thanks all!

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Code release of ipfw NAT support for SCTP in FreeBSD-8

[Jason But]

The Centre for Advanced Internet Architectures (CAIA - 
http://caia.swin.edu.au)
is proud to announce the release of alias_sctp version 0.1, a SCTP NAT 
patch to

FreeBSD 8.x.


Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias 
suite.

It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata).
The code has been intentionally kept as separate as possible from the base
modules to aid testing and debugging, and make it easier to port to other
systems.

This project has been made possible in part by a grant from the Cisco
University Research Program Fund at Community Foundation Silicon Valley.


We welcome and value feedback and comments.
Please forward feedback to [EMAIL PROTECTED] and [EMAIL PROTECTED]

Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html

Features of alias_sctp version 0.1:

- Basic configuration through ipfw nat ... config commands.

- Forwarding of incoming SCTP associations through
 ipfw nat ... redirect_addr ... commands.

- A variety of log levels (currently #define, but sysctl in version 0.2).

- Stateful SCTP association management.

12345678901234567890123456789012345678901234567890123456789012345678901234567890
- Tested on single-homed hosts, but should work when the multi-homed 
host is on

 the global side of the NAT (same mechanism for address translation).

- Dynamic hash table size allocation (currently #define, but sysctl in
 version 0.2).

- Initial testing has been for up to 1 concurrent flows arriving and 
leaving

 at about 2000/second. Tested for periods of up to 72 hours.


Features in the pipline for further releases:

- Sysctl interface for logging, timeouts, hash table size.
 Status - mostly complete.

- Port forwarding and load sharing.
 Status - mostly complete.

- Support for, soon to be specified, enhancements of SCTP to aid 
interworking

 with NATs.

- New AddIP ASCONF chunks.
 Status - preliminary coding and investigation.
 (Requires finalised standards to be completed)

- AbortM and ErrorM NAT originated messages.
 Status - preliminary coding, with work starting on the ipfw send interface

- IPv6 support.
 Status - preliminary investigation.

- Global IP address tracing.
 Status - preliminary investigation.


Other tasks:

- Exaustive testing of the various configurations and scenarios.

- Stress and load testing.

- Performance analysis.

Jason
--

--
Dr. Jason But
Lecturer
Telecommunications Engineering Academic Group
Faculty of Information and Communication Technologies
Swinburne University of Technology
http://www.swinburne.edu.au/ict/telecommshome.htm



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/122109: ipfw nat traceroute problem

[piso]

Synopsis: ipfw nat traceroute problem

Responsible-Changed-From-To: freebsd-ipfw-piso
Responsible-Changed-By: piso
Responsible-Changed-When: Wed Mar 26 20:32:04 UTC 2008
Responsible-Changed-Why: 
Mine.

http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: bin/120734: [patch] ipfw(8): ipfw nat has problems to show multiples nat rules

[linimon]

Synopsis: [patch] ipfw(8): ipfw nat has problems to show multiples nat rules

Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Feb 16 14:08:59 UTC 2008
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=120734
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [6.x patchset] Ipfw nat and libalias modules

[Paolo Pisati]

I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release
 specifically.   Before I continue down this road, in the name of not
 re-inventing the wheel twice, does anyone already have a current patch
 which will work on 6.2 ?  Thank You!

AFAIK no.

-- 
bye,

P.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [6.x patchset] Ipfw nat and libalias modules

[Chris Bowman (Home)]

On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
 
   I was recently testing the in kernel nat patch, which is an 
absolutely  wonderful addition in my opinion.  I have however run 
into one issue, when for example I do the following :


ipfw nat 10 config ip 2.2.2.2


[snip]

Where did you get the 6.x patch? Did you find a tarball around or you 
backported the code from 7.x?


In the first case, that patch is old and buggy, and AFAIK the bug you 
encountered was due to an uninitialized conditional variable.


bye,
P.


  
  I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release 
specifically.   Before I continue down this road, in the name of not 
re-inventing the wheel twice, does anyone already have a current patch 
which will work on 6.2 ?  Thank You!


Chris Bowman


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [6.x patchset] Ipfw nat and libalias modules

[Paolo Pisati]

On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
 
I was recently testing the in kernel nat patch, which is an absolutely  
 wonderful addition in my opinion.  I have however run into one issue, when 
 for example I do the following :
 
 ipfw nat 10 config ip 2.2.2.2
[snip]

Where did you get the 6.x patch? Did you find a tarball around or 
you backported the code from 7.x?

In the first case, that patch is old and buggy, and AFAIK the bug you 
encountered 
was due to an uninitialized conditional variable.

bye,
P.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [6.x patchset] Ipfw nat and libalias modules

[Chris Bowman]

It was indeed the tarball downloaded from 
http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz  ... Thank you, 
I'll give the 7.x code a try.


Paolo Pisati wrote:

On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
  
   I was recently testing the in kernel nat patch, which is an absolutely  
wonderful addition in my opinion.  I have however run into one issue, when 
for example I do the following :


ipfw nat 10 config ip 2.2.2.2


[snip]

Where did you get the 6.x patch? Did you find a tarball around or 
you backported the code from 7.x?


In the first case, that patch is old and buggy, and AFAIK the bug you encountered 
was due to an uninitialized conditional variable.


bye,
P.


  


--
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Mysterious packets with stateful ipfw+nat

[James Halstead]

Ok, the obvious part that I think I was missing while it was late, was 
that these must be keep-alive packets generated by the firewall as the 
dynamic rules are about to expire. That being the case however, 
shouldn't these keep-alive packets take the same action as the original 
rule (skipto 1000 and be diverted through NAT for processing)?


James Halstead wrote:
Ok, this has been driving me nuts for a while. I recently noticed that 
my 5.4-RELEASE firewall was having a problem with packet leakage. I am 
seeing the occasional packet on the outside interface with an internal 
src ip. I put a hub between my firewall and cable modem and verified 
that the packets are indeed on the wire. Now I am in the process of 
setting up a new 6.1-RELEASE box and the same issue was happening on my 
test network.


So far I don't get it. I must be missing something obvious. At least 
everything still works in general.


The test setup is a clean install of 6.1-RELEASE, using GENERIC with the 
ipfw.ko and ipdivert.ko modules loaded. After searching around I was 
basing the configuration off of:


http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.html

The test box has two Ethernet interfaces, renamed to be isp0 and net0. 
isp0 is using DHCP, and receives the address 10.42.0.220/24. net0 is 
running a DHCP server, and sits on 192.168.1.1/24. There is one single 
piece of hardware on net0 which is always assigned 192.168.1.230. The 
gateway to the actual Internet sits on 10.42.0.254. A pretty simple setup.


The internal machine is just constantly connecting to an external web 
server to generate traffic. I see the same basic type of thing happen 
for other usage as well on my main network (ssh sessions, https/http 
sessions, etc). When looking at tcpdump I am occasionally seeing (on isp0):


19:35:27.591761 aa:aa:aa:5b:db:99  bb:bb:bb:1f:33:da,
192.168.1.230.2542  xx.xx.53.84.80: ., cksum 0xfade (correct), 
2295591733:2295591733(0) ack 167570634 win 0


If this packet was truly supposed to be going out on the external 
interface, it should have gone through NAT and show a src ip of 
10.42.0.220. To make it more frustrating, even if I enable ifpfw at 
layer 2, I am unable to capture these rogue packets. If I watch tcpdump 
on net0 at the same time, I see the following:


19:35:27.591767 aa:aa:aa:5b:db:98  cc:cc:cc:10:04:ce,
xx.xx.53.84.80  192.168.1.230.2542: ., cksum 0xfade (correct), 
913:913(0) ack 1256 win 0


The only other thing that I have noticed, is that the packets seem to 
show up on the external interface at about the same time as the dynamic 
rules expire. The dynamic rule would look like:


192.168.1.230 2542 - xx.xx.53.84 80

Which is pretty much what I would expect. The same setup with a 
non-stateful ipfw ruleset (using established keyword) doesn't seem to 
have this problem. Any ideas? configuration follows.



 natd.conf 
unregistered_only yes
dynamic yes
#deny_incoming yes
log_denied yes
log_ipfw_denied yes

(deny_incoming was set, turned it off to see if it helped but it works 
the same).


* ipfw.rules 
# Test stateful firewall + natd script
cmd=/sbin/ipfw add
natout=skipto 1000
oif=isp0
iif=net0
inet=192.168.1.0/24

NOROUTE=( 172.16.0.0/12 or 192.168.0.0/16 or \
0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or 
240.0.0.0/4 )



# Start with a clean ruleset
/sbin/ipfw -q -f flush


# Allow all traffic on the loopback and internal network, to keep this 
simple.

$cmd 2 allow all from any to any via lo0
$cmd 5 allow all from any to any in via $iif
$cmd 6 allow all from any to any out xmit $iif

# Translate incoming traffic here
$cmd 200 divert natd ip from any to any in via $oif
$cmd 205 check-state

# Outbound
# Use stateful inspection to allow any connection from the internal 
network.

$cmd 300 $natout tcp from any to any out via $oif setup keep-state
$cmd 305 $natout udp from any to any out via $oif keep-state
$cmd 310 $natout icmp from any to any out via $oif keep-state

# Inbound
# Prevent non-routable networks on the external interface.
$cmd 400 deny all from $NOROUTE to any in via $oif

# Allow incoming DHCP for external network address assignment.
$cmd 450 allow udp from any to any 68 in via $oif keep-state

# Allow incoming SSH to this machine
$cmd 455 allow tcp from any to me 22 in via $oif setup keep-state

# Allow incoming ICMP
$cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif

$cmd 999 deny log ip from any to any

# NAT rule for outgoing traffic.
$cmd 1000 divert natd ip from any to any out via $oif
$cmd 1005 allow ip from any to any

Thanks for any insight,

-James


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Mysterious packets with stateful ipfw+nat

[Max Laier]

On Saturday 02 December 2006 19:00, James Halstead wrote:
 Ok, the obvious part that I think I was missing while it was late,
 was that these must be keep-alive packets generated by the firewall as
 the dynamic rules are about to expire. That being the case however,
 shouldn't these keep-alive packets take the same action as the original
 rule (skipto 1000 and be diverted through NAT for processing)?

keep-alive packets are marked with M_SKIP_FIREWALL in 
netinet/ip_fw2.c::send_pkt  You could try to remove that, rebuild and see 
if it helps.  I'm not sure what the reasoning behind this setting was and 
have no idea what implications it has to change it.  If it helps your 
setup we might want to consider a sysctl to change that behavior.

 James Halstead wrote:
  Ok, this has been driving me nuts for a while. I recently noticed
  that my 5.4-RELEASE firewall was having a problem with packet
  leakage. I am seeing the occasional packet on the outside interface
  with an internal src ip. I put a hub between my firewall and cable
  modem and verified that the packets are indeed on the wire. Now I am
  in the process of setting up a new 6.1-RELEASE box and the same issue
  was happening on my test network.
 
  So far I don't get it. I must be missing something obvious. At least
  everything still works in general.
 
  The test setup is a clean install of 6.1-RELEASE, using GENERIC with
  the ipfw.ko and ipdivert.ko modules loaded. After searching around I
  was basing the configuration off of:
 
  http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.
 html
 
  The test box has two Ethernet interfaces, renamed to be isp0 and
  net0. isp0 is using DHCP, and receives the address 10.42.0.220/24.
  net0 is running a DHCP server, and sits on 192.168.1.1/24. There is
  one single piece of hardware on net0 which is always assigned
  192.168.1.230. The gateway to the actual Internet sits on
  10.42.0.254. A pretty simple setup.
 
  The internal machine is just constantly connecting to an external web
  server to generate traffic. I see the same basic type of thing happen
  for other usage as well on my main network (ssh sessions, https/http
  sessions, etc). When looking at tcpdump I am occasionally seeing (on
  isp0):
 
  19:35:27.591761 aa:aa:aa:5b:db:99  bb:bb:bb:1f:33:da,
  192.168.1.230.2542  xx.xx.53.84.80: ., cksum 0xfade (correct),
  2295591733:2295591733(0) ack 167570634 win 0
 
  If this packet was truly supposed to be going out on the external
  interface, it should have gone through NAT and show a src ip of
  10.42.0.220. To make it more frustrating, even if I enable ifpfw at
  layer 2, I am unable to capture these rogue packets. If I watch
  tcpdump on net0 at the same time, I see the following:
 
  19:35:27.591767 aa:aa:aa:5b:db:98  cc:cc:cc:10:04:ce,
  xx.xx.53.84.80  192.168.1.230.2542: ., cksum 0xfade (correct),
  913:913(0) ack 1256 win 0
 
  The only other thing that I have noticed, is that the packets seem to
  show up on the external interface at about the same time as the
  dynamic rules expire. The dynamic rule would look like:
 
  192.168.1.230 2542 - xx.xx.53.84 80
 
  Which is pretty much what I would expect. The same setup with a
  non-stateful ipfw ruleset (using established keyword) doesn't seem to
  have this problem. Any ideas? configuration follows.
 
 
   natd.conf 
  unregistered_only yes
  dynamic yes
  #deny_incoming yes
  log_denied yes
  log_ipfw_denied yes
 
  (deny_incoming was set, turned it off to see if it helped but it
  works the same).
 
  * ipfw.rules 
  # Test stateful firewall + natd script
  cmd=/sbin/ipfw add
  natout=skipto 1000
  oif=isp0
  iif=net0
  inet=192.168.1.0/24
 
  NOROUTE=( 172.16.0.0/12 or 192.168.0.0/16 or \
  0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or
  240.0.0.0/4 )
 
  
  # Start with a clean ruleset
  /sbin/ipfw -q -f flush
 
  
  # Allow all traffic on the loopback and internal network, to keep
  this simple.
  $cmd 2 allow all from any to any via lo0
  $cmd 5 allow all from any to any in via $iif
  $cmd 6 allow all from any to any out xmit $iif
 
  # Translate incoming traffic here
  $cmd 200 divert natd ip from any to any in via $oif
  $cmd 205 check-state
 
  # Outbound
  # Use stateful inspection to allow any connection from the internal
  network.
  $cmd 300 $natout tcp from any to any out via $oif setup keep-state
  $cmd 305 $natout udp from any to any out via $oif keep-state
  $cmd 310 $natout icmp from any to any out via $oif keep-state
 
  # Inbound
  # Prevent non-routable networks on the external interface.
  $cmd 400 deny all from $NOROUTE to any in via $oif
 
  # Allow incoming DHCP for external network address assignment.
  $cmd 450 allow udp from any to any 68 in via $oif keep-state
 
  # Allow incoming SSH to this machine
  $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state
 
  # Allow incoming ICMP
  $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in