Re: ipfw nat and smaller wan mtu
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(&pip->ip_sum, + &pip->ip_dst, &pip->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
Re: IPFW NAT behaviour different on 10-Stable versus 11-Stable [SOLVED]
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
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
13.01.2016, 22:56, "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); Thanks for the detailed explanation. Looks reasonable. I'll do several more tests on that and commit. > > 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, igb and hardware checksums
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
--- Original message --- From: "isp" 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
Здравствуйте, Alexander V. Chernikov! Вы писали 06.10.2011 15:16: ... svn diff -c 223835 svn://svn.freebsd.org/base/stable/8> ~/r223835.diff Can you try the patch attached (just to be sure) ? sure, I can =) I'll try and then drop you a line about the results. This is exact situation from this (and some related PRs) and this revision definitely fixes it. Sounds promising! Hope I've missed or neglected something, and that'd help. Thanks for you help once more! Now all goes as it have to; obviously that's my fault on the previous run. I suppose, wrong kernel is the most probable cause of that -- I've upgrade the system at that time. Sorry for wasting your time =( But now I wonder why this patch isn't in RELENG_8_2 branch already? As far as I can see it's in RELENG_8 only. The bug seems to be widely occured and easy to catch, especially when moving to ipfw nat from ipfw+natd. 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" !DSPAM:4e8d95cf907971471292836! ___ 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! Вы писали 06.10.2011 15:16: 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) ? sure, I can =) I'll try and then drop you a line about the results. This is exact situation from this (and some related PRs) and this revision definitely fixes it. Sounds promising! Hope I've missed or neglected something, and that'd help. Btw, what is the value of net.inet.ip.fw.one_pass sysctl ? now it's 0. As far as I remember, I've raised one_pass to 1 -- without any effect on the packets filtering (in my case) Are you sure that ipfw is the single enabled firewall on this machine ? Are you sure that system is using new kernel ? Just 10 minutes ago I was quite sure in both cases, without any doubt.. Now, as the patch you've sent to me is char-to-char the same as mine... I'll try once more. Thanx for help and directions! WBR, Oleg !DSPAM:4e8d8e75828882115423180! ___ 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
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 ___
Re: ipfw nat drops icmp packets from localhost [patch attached]
Здравствуйте, 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
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
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? -- 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: IPFW - NAT - two gateway -HELP
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 - two gateway -HELP
On 1/1/11 5:11 AM, Nima Khoramdin wrote: 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 | | | | | | | | 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"
Re: ipfw nat and localy initiated UDP traffic (bad udp cksum)
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, -- -Chuck ___ 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)
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=8843 metric 0 mtu 1500 options=9b ether 00:20:ed:91:97:93 inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active === after: === em0: flags=8843 metric 0 mtu 1500 options=98 ether 00:20:ed:91:97:93 inet 87.110.108.74 netmask 0xfe00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active === dmesg | grep em0 === em0: 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 and localy initiated UDP traffic (bad udp cksum)
On Tuesday 14 July 2009, Dmitriy Demidov wrote: > Hi list. > > I have a problems with ipfw nat. It makes me crazy (I realy have no idea > how to troubleshoot this problem). Looks like ipfw nat do not pass through > itself localy initiated UDP traffic! Is there any hint that I do not know > about ipfw nat? Any clue please :( > Update about this issue. There is somthing wrong with UDP pass through - ipfw nat makes it "bad cksum". tcpdump on ISP-side nic (tcpdump -i 2 -X -vvv -n -l ip) shows this: for localy initiated UDP/DNS trafic: 21:58:30.116680 IP (tos 0x0, ttl 64, id 6212, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum aa89!] 50277+ A? www.freebsd.org. (33) 0x: 4500 003d 1844 4011 a6d9 576e 6c4a e..=@...wnlj 0x0010: 5bc6 9c14 f39d 0035 0029 bbcd c465 0100 [..5.)...e.. 0x0020: 0001 0377 0766 7265 .www.fre 0x0030: 6562 7364 036f 7267 0100 01 ebsd.org. 21:58:35.116809 IP (tos 0x0, ttl 64, id 6239, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum aa89!] 50277+ A? www.freebsd.org. (33) 0x: 4500 003d 185f 4011 a6be 576e 6c4a e..=@...wnlj 0x0010: 5bc6 9c14 f39d 0035 0029 bbcd c465 0100 [..5.)...e.. 0x0020: 0001 0377 0766 7265 .www.fre 0x0030: 6562 7364 036f 7267 0100 01 ebsd.org. 21:58:40.117744 IP (tos 0x0, ttl 64, id 6240, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.62365 > 91.198.156.20.53: [bad udp cksum for UDP/DNS trafic that pass via nat from local network: 21:58:21.925741 IP (tos 0x0, ttl 63, id 632, offset 0, flags [none], proto UDP (17), length 61) 87.110.108.74.58124 > 91.198.156.20.53: [udp sum ok] 36465+ A? www.freebsd.org. (33) 0x: 4500 003d 0278 3f11 bda5 576e 6c4a E..=.x..?...WnlJ 0x0010: 5bc6 9c14 e30c 0035 0029 8bfd 8e71 0100 [..5.)...q.. 0x0020: 0001 0377 0766 7265 .www.fre 0x0030: 6562 7364 036f 7267 0100 01 ebsd.org. 21:58:21.932623 IP (tos 0x0, ttl 59, id 39585, offset 0, flags [none], proto UDP (17), length 165) 91.198.156.20.53 > 87.110.108.74.58124: 36465 q: A? www.freebsd.org. 1/3/0 www.freebsd.org. A 69.147.83.33 ns: freebsd.org.[| domain] 0x: 4500 00a5 9aa1 3b11 2914 5bc6 9c14 E...;.).[... 0x0010: 576e 6c4a 0035 e30c 0091 8f66 8e71 8180 WnlJ.5.f.q.. 0x0020: 0001 0001 0003 0377 0766 7265 .www.fre 0x0030: 6562 7364 036f 7267 0100 01c0 0c00 ebsd.org 0x0040: 0100 0100 000b 6600 0445 9353 21c0 1000 ..f..E.S!... 0x0050: 0200 .. ipfw config: add allow ip from any to any via fxp0 add allow udp from any 68 to any 67 add allow udp from any 67 to any 68 add count ip from any to any nat 1 config log if em0 reset same_ports deny_in nat 2 config log if em0 nat 3 config log if em0 reset same_ports deny_in add count ip from any to any add nat 1 tcp from any to any out xmit em0 add nat 2 udp from any to any out xmit em0 add nat 3 icmp from any to any out xmit em0 add nat 1 tcp from any to me in recv em0 add nat 2 udp from any to me in recv em0 add nat 3 icmp from any to me in recv em0 add count ip from any to any ipfw show 00100 1642 372640 allow ip from any to any via lo0 002000 0 deny ip from any to 127.0.0.0/8 003000 0 deny ip from 127.0.0.0/8 to any 004009990 allow ip from any to any via fxp0 005000 0 allow udp from any 68 to any dst-port 67 006000 0 allow udp from any 67 to any dst-port 68 00700 25 1404 count ip from any to any 00800 25 1404 count ip from any to any 009000 0 nat 1 tcp from any to any out xmit em0 010007427 nat 2 udp from any to any out xmit em0 011000 0 nat 3 icmp from any to any out xmit em0 01200 17812 nat 1 tcp from any to me in recv em0 013001165 nat 2 udp from any to me in recv em0 014000 0 nat 3 icmp from any to me in recv em0 015000 0 count ip from any to any 655353520 deny ip from any to any uname -a FreeBSD hius.local.home 7.2-STABLE FreeBSD 7.2-STABLE #0: Wed Jul 15 20:59:17 EEST 2009 r...@hius.local.home:/usr/obj/usr/src/sys/STABLE i386 ___ 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
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]"
Re: ipfw + nat
> 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
Hi Mufalani, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html and in particular the part 26.6.5.7 should explain how to accomplish this. Regards, Henrik On 6/8/06, 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? 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
mufalani wrote: How to redirect requisitions at 80?s port (200.X.X.X:80) > to address (192.x.x.x:80) with nat and ipfw? You can try following: # natd -alias_address 200.X.X.X -redirect_port tcp 192.x.x.x:80 80 # ipfw add divert natd tcp from any to 200.X.X.X in recv $ExtIf # ipfw add divert natd tcp from 192.x.x.x 80 to any out xmit $ExtIf $ExtIf - external interface. -- WBR, Andrey V. Elsukov ___ 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
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]"