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 

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"

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
 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"

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

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: 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: 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: ipfw + nat

[Chuck Swiger]

mufalani wrote:

Hi all,

I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 (gateway). 


How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
(192.x.x.x:80) with nat and ipfw?


echo redirect_port tcp 192.x.x.x:80 80  /etc/natd.conf

See man natd for details and variants like redirect_address.

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

Re: ipfw + nat

[Erik]

 Hi all,

 I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 
 (gateway).

 How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
 (192.x.x.x:80) with nat and ipfw?

Pretty simple if you are using natd.

In /etc/rc.conf:

### Firewall Settings ###
firewall_enable=YES
ipdivert_enable=YES
gateway_enable=YES
firewall_type=MYOWN
natd_enable=YES
natd_interface=xl0  (replace with your external interface)
natd_flags=-f /etc/rc.natd
#

In /etc/rc.natd:

#
# NATD configurationfile that supplies NATD whit parameters
#

log no
use_sockets yes
same_ports yes

# Ports redirected to the internal network

redirect_port tcp 192.168.0.100:22 222
redirect_port tcp 192.168.0.111:80 80

^ redirecting  ^ obvious^ external port
^ type of traffic^ internal port

In the /etc/rc.firewall:

divert 8668 ip from any to any via xl0 (will be your external interface)



This is all there is to it (put in a simple way...)

Regards
/Erik



 Att,
 Rodrigo Mufalani

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


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

Re: ipfw + nat

[Nick Withers]

On Wed, 7 Jun 2006 20:17:07 -0300
mufalani [EMAIL PROTECTED] wrote:

 Hi all,
 
 I have a webserver runing apache 2.3 under windows 2003, and one BSD 5.4 
 (gateway). 
 
 How to redirect requisitions at 80´s port (200.X.X.X:80) to address 
 (192.x.x.x:80) with nat and ipfw?

Assuming you're running both already, simply adding the
following line (with the appropriate IP addresses, of course) to
your natd configuration should do the trick:

redirect_port tcp 192.x.x.x:80 200.X.X.X:80

Otherwise, I'd recommend reading the FreeBSD Handbook sections
on this
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html
and
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html,
for instance).

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

This probably belongs on freebsd-questions, by the way...
-- 
Nick Withers
email: [EMAIL PROTECTED]
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]