Re: Kernel NAT issues
Nathan, I've gone the same way that you have, ie bunch of jails that are individually providing services& kernel Nat. It takes careful planning and the knowledge that the default route will be the first IP in your jail.conf list for each jail. Getting jails to play nice means fiddling around with all interfaces. If you can take ipfw out of the equation until you can see tcpdump traffic doing what you want; the challenge hasn't been ipfw in my experience. (& yes initially I've had three tcpdumps going at once too; along with old friends: raw ip & ping ) Enjoy the fun of getting it to work, it's well worth the effort. (And be thankful that you aren't using pf, another level of complexity but suits my needs perfectly) ;) Dewayne ___ 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: [RFC][patch] New keep-state-only option
On 4/02/2015 4:38 PM, Julian Elischer wrote: On 2/4/15 1:32 PM, Julian Elischer wrote: On 2/4/15 12:13 AM, Lev Serebryakov wrote: And variants with multiple NATs and nat global becomes as easy as this, too! No stupid skipto, no keep-state at incoming from local network parts of firewall, nothing! P.S. I HATE this all any to any part! can we get rid of it? (implied).. or just add everything also I am not sure about keep-state-only.. how about 'set-state'? or record-state as I started with.. or record-session.. (state always annoyed me) record-state seems more intuitive, while record-session suggests a wider scope involving session negotiation. Regards, Dewayne. ___ 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
Version of pf Any impact to FreeBSD re ALTQ removal from OpenBSD 5.6
Two questions: 1. With this announcement http://undeadly.org/cgi?action=articlesid=20140419151959 by the OpenBSD project concerning their dropping of ALTQ for their new bandwidth and priority mechanism, can anyone share/advise what impact, if any, this will this have for ALTQ and hence pf on FreeBSD. Will we remain with ALTQ for the next few years? After 11 years with ipfw, nat and dummynet I'm considering migrating to pf, primarily for its nat with keep-state and QOS via ALTQ-CBQ capabilities. This all started with the tribulation of enabling ftp in anything like a stateful manner. Is there any plan to track the changes that OpenBSD is taking, or for that matter is there a need to take advantage of their experience in queuing/prioritisation in the foreseeable future (say 3 years)? I suspect that it will be a major task to replace ALTQ. 2. Also could someone advise which version of pf we have from OpenBSD in FreeBSD 10 Stable. From the svn logs (ref 1) it appears that pf was last imported from OpenBSD at 4.6 and a lot of updates and changes have been applied. The Copyright notice in pf.c on FreeBSD10 Stable is dated 2012, while __FBSDID($FreeBSD: stable/10/sys/netpfil/pf/pf.c 265008 2014-04-27 09:05:34Z mm $). From 9.2-Beta2 __FBSDID($FreeBSD: stable/9/sys/contrib/pf/net/pf.c 243401 2012-11-22 12:11:32Z glebius $); There is quite a lot of documentation on pf, but it is often unclear which version I should hang my hat on. And as a newbie to pf, well - its a challenge. Ref: 1) http://svnweb.freebsd.org/base/stable/10/sys/netpfil/pf/pf.c?sortby=dateview=log [2 years, 11 months ago Update to pf from OpenBSD 4.5. Though a lot of changes have occurred since then]. 2) http://home.nuug.no/~peter/pf/newest/post47.html Regards, Dewayne ___ 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/189720: [ipfw] [patch] pps action for ipfw
What is the use case of this addition? Is this objective to limit the mischief on a certain port, for example ntp or port 53? I can appreciate the need to limit the number of packets during, say a DDOS event, but I'm struggling with why I would want less that 1 packet per second. Is the idea of pps meant to remove the need of dummynet where it is used in almost trivial cases? Though if this were the case, then bps (bits per second) may be more useful? Dewayne. ___ 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 stateful and ICMP
On 11/03/2014 2:53 PM, Julian Elischer wrote: It has annoyed me for some time that icmp packets refering ot an ongoing session can not be matched by a dynamic rule that goversn that session. For example, if you have a dynamic rule for tcp 1.2.3.4 port 80 from 5.6.7.8 port 1 then a returning icmp packet giving destination unreachable and holding the appropriate header in it's data segment should probably be allowed to go through back to the originator. Briefly looking at the code I see no sign of this and I haven't seen any sign of it in action so I hope I'm not going to get a but it already does that response. My way of approaching it would be to change the dynamic rule code so that it checks that the ICMP destination address matches the source address of the packet fragment in the 'data' section, and then match the data segment packet header with the dynamic rules instead of the icmp packet itself. I would also add a sysctl to disable this behaviour, because there is always someone who doesn't want any change you care to name. The only way you can allow get icmp packets back to the originating sender at the moment is to just allow them through without any major filtering. That leaves you open to a large attack window. anyone have violent objections? (I'm currently rewriting the firewall rules at $DAYJOB and I think I'd like to have this, but as we're on 8.0 I'll have to wait a while before I can use my own patch :-) Julian ___ 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 Julian, That's a good idea, and I appreciate the feedback opportunity. May I suggest a sysctl to enable the behaviour, rather than one to disable it. For two reasons: so that existing ipfw sites don't find the need to change or amend existing firewall rules (we typically open icmp 3 and 11); and how do you envisage ipfw show will display this compound behaviour? Regards, Dewayne. ___ 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
