Re: kern/144187: [ipfw] deadlock using multiple ipfw nat and multiple limit statements
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: looking to translate SRC port as well.
In short, I have a sip server that is very restrictive on the dst port, and a sip trunk provider that is very restrictive on src ports. Naturally, its a great sip server, and a great sip trunk service, and the ports each one demands are not the same. the sip server listens on udp port 5080, and the sip trunk provider MUST send TO udp port 5060. (easy, right?) no, when the sip server sends to the sip trunk provider, the sip trunk provider must think the sip server src port is 5060 also! (and it is not) So, the sip server must think it is sending and receiving sip on port 5080, the sip trunk must think it is sending and receiving on port 5060. I have looked at ipfw/divert sockets, netawk, natd, and trying to find the easiest way to do it. I thought about writing a perl module, and have ipfw divert to it (perl has optional divert socket pm's) Hi, you can try to use Netgraph and ng_path node to alter src/dst UDP port number in outgoing/incoming packets flow. This node allows you change just *anything* in the packet. Take a look at man page for ng_path: www.freebsd.org/cgi/man.cgi?query=ng_patchapropos=0sektion=0manpath=FreeBSD+8.1-stableformat=html Good luck. ___ 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: help wanted with NAT under ipfw
On Friday 30 April 2010, Robert Huff wrote: I have been trying to get NAT working under ipfw on: FreeBSD 9.0-CURRENT #0: Fri Apr 23 11:34:17 EDT 2010 amd64 and failing. The ipfw part works fine. I'm using: ipfw_load=YES ipfw_nat_load=YES # in-kernel ipfw nat libalias_load=YES # for in-kernel ipfw nat my ipfw rules are appended. However, the moment I do this: ipfw add 5000 nat 15 all from any to any ipfw nat 15 config log same_ports if em0 the machine is cut off from the outside world. Removing that rule makes things right again. (Obviously checking whether NAT is happening is useless.) I've read the man page; I've read the Handbook. Neither are helpful. What am I doing wrong? Respectfully, Robert Huff Hi, This could happen because of old annoying bug (or feature?) that seats somethere in the middle of libalias and em driver: http://www.freebsd.org/cgi/query-pr.cgi?pr=143939cat=kern Try to turn off RXCSUM,TXCSUM on em interface: ifconfig em0 -rxcsum -txcsum -tso Good luck. ___ 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
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: 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=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: keep-state rules inadequately handles big UDP packets or fragmented IP packets?
On Thursday 02 April 2009, Paolo Pisati wrote: Luigi Rizzo wrote: Ok then we may have a plan: you could do is implement REASS as an action (not as a microinstruction), with the following behaviour: - if the packet is a complete one, the rule behaves as a count (i.e. the firewall continues with the next rule); - if the packet is a fragment and can be reassembled, the rule behaves as a count and the mbuf is replaced with the full packet; - if the packet is a fragment and cannot be reassembled, the rule behaves as a drop (i.e. processing stops) and the packet is swallowed by ipfw. This seems a useful behaviour, but it must be documented very clearly because it is not completely intuitive. Perhaps we should find a more descriptive name. committed yesterday in HEAD as reass action, and here is the 7.x patch: http://people.freebsd.org/~piso/ipfw-reass-7x.diff Hi Paolo. Thank you for this work! I think it is a good feature that will makes ipfw more clear and extends it's usability for future use. Hey, you deserve a reward for this work! Do you remember about 500WMZ bounty? Please, if you wanna to get it - contact with me outside of this list. Or I will transfer this money as a donation into FreeBSD Foundation :) Good luck! ___ 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: keep-state rules inadequately handles big UDP ?packets?or?fragmented IP packets?
On Wednesday 18 March 2009, Oliver Fromme wrote: I'm just curious ... Is it really worth the effort to add fragment reassembly to IPFW? What advantage does it have? It would be much easier to simply pass all fragments with offset 1, and drop all fragments with offset 0 that are smaller than a certain reasonable minimum length. What would be the problem with this approach? Best regards Oliver Please wait... If I got it right (and dont missing something) then this rule: ipfw add allow ip from any to me frag have dissadvantage - I'm unabled to filter data by UDP/TCP ports. All IP packets is just passing through firewall to me. No UDP/TCP filtering here? ___ 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: keep-state rules inadequately handles big UDP packets or fragmented IP packets?
On Tuesday 17 March 2009, Paolo Pisati wrote: FYI i have a patch for ipfw nat that reassemble a packet before nat[*], but if the idea of an explicit packet reassembly action sounds good, i could move the code over there. [*] actually the patch is really simple, it's just a call to ip_reass() with some glue code, but nonetheless it could be used more globally. It's sounds like the thing I'm looking for! How hard it would be to make it? If it is unacceptable to turn it on by default (for some reasons, if any) then can it be implemented as additional ipfw rule allowing to turn him on/off when needed? Something like: ipfw add 100 scrub-ip ip from any to me ___ 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: keep-state rules inadequately handles big UDP packets or fragmented IP packets?
On Sunday 15 March 2009, Sergey Matveychuk wrote: Dmitriy Demidov wrote: Hi Luigi. Thank you for answer. It is a big surprise for me that reassembling of IP datagrams is done not *before* they go into firewall, but *after* :( But what's wrong with it? A fragment got from net, pass firewall and store. After all fragments we got, OS reassembly a packet and pass it through firewall again. it is not related to dynamic rules, but to the fact that that the firewall is called before reassembling packets. The info (port numbers especially) is not available in the fragments so the firewall cannot do anything. The only solution would be to call the firewall after reassembly. I am not sure if there is any work in progress for that. If I got it right from Luigi explanation, then problem we see here happens this way: ipfw receivs fragmented IP datagrams what contains splited UDP packet insight (IP-fragment1/UDP-head) + (IP-fragment2/UDP-tail), and it can not procead second one because of lack of UDP header? IP reassembling happens after ipfw? ___ 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
keep-state rules inadequately handles big UDP packets or fragmented IP packets?
Hi list. I'm using DNS cache server Unbound-1.2.1. I want to start using DNSSEC via DLV (unbound gracefully allows it). My system is FreeBSD7-STABLE. I'm using ipfw. Original ipfw configuration: add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any /etc/sysctl.conf net.inet.ip.fw.dyn_udp_lifetime=60 The problem is that Unbound can't do DNSSEC validation using this firewall configuration. It blames some thing like this: [1236970569] unbound[9096:3] info: resolving dlv.isc.org. DNSKEY IN [1236970569] unbound[9096:3] info: failed to prime trust anchor -- could not fetch DNSKEY rrset dlv.isc.org. DNSKEY IN [1236970569] unbound[9096:3] info: Could not establish a chain of trust to keys for dlv.isc.org. DNSKEY IN Unbound starts working only then I put in ipfw this set of rules to handle all UDP packets outside from keep-state rules: add allow udp from any to any add check-state add deny icmp from any to any frag add allow icmp from any to me icmptypes 0,3,11 add allow icmp from me to any out keep-state add allow tcp from me to any out keep-state add allow udp from me to any out keep-state add deny ip from any to any It looks like dynamicaly created rules some how inadequately handles big UDP packets (DNSSEC answers are big). Is there any who can help to investigate this issue (looks like I can't do it myself)? Can it be ipfw related issue? 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
