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
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,
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
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
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
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
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
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()
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
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
10 matches
Mail list logo
