From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 25 02:09:01 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF84106566B for ; Sun, 25 Mar 2012 02:09:01 +0000 (UTC) (envelope-from freebsd-ipfw@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id C2BFA8FC0C for ; Sun, 25 Mar 2012 02:08:59 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 891CD5C22 for ; Sun, 25 Mar 2012 12:22:32 +1000 (EST) Message-ID: <4F6E7E39.8080805@herveybayaustralia.com.au> Date: Sun, 25 Mar 2012 12:08:57 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> In-Reply-To: <20120325013410.H2060@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 02:09:01 -0000 On 03/25/12 02:56, Ian Smith wrote: > On Sat, 24 Mar 2012, Da Rock wrote: > > On 03/18/12 02:31, Julian Elischer wrote: > > > On 3/17/12 1:36 AM, Da Rock wrote: > > > > On 03/14/12 17:09, Rémy Sanchez wrote: > > > > > On Saturday 10 March 2012 00:39:24 Da Rock wrote: > > > > > > I'm relatively new to IPFW, not FBSD; the last time I used IPFW (I > > > > > > believe) was using 4.3. I'm now attempting to use IPFW for some tests > > > > > > (and hopefully move to production), and I'm trying to determine how I > > > > > > would setup binat using IPFW; or even if its possible at all. > > > > > > > > > > > > I've been hunting some more in depth documentation, but it appears to > > > > > > be > > > > > > scarce/not definitive. I suspect using the modes in libalias such as > > > > > > "use same ports" and "reverse" might be able to do what I'm looking > > > > > > for? > > > > > > > > > > > > Any clarity much appreciated. > [..] > > > > I want it to do something pf cant - port forward ipsec packets for > > > > Android L2TP/IPSec. Apparently (according to pfsense experts) it is > > > > impossible until Android 3.0 or 4.0. My next port of call will be > > > > ipfilter, and thats a known working solution but I want to use more > > > > robust native tools. > > > > > > you need to really explain what you want here.. do you want the IP packets > > > to still have the original ports/addesses in them or do you want to have > > > the packets untouched, but redirected? > > > > > > a picture helps too. > > > To be honest I'm not sure anyone specifically understands why pf fails. I > > think it may have to do with fragmentation reassembly. > > Can't comment; I suppose you've asked on the pf list? Yep, but not even the pfsense guys know why - and they've apparently done significant testing. They only know that it will work with Android 4.0 (and maybe 3.0). I might have brought it to their attention, but nothing else has come out of it. The frag reassembly theory I came up with because I had to clean up the packets so that VoIP would work; before that I had mysterious errors, and once I changed a few settings trying to get IPSec to work I got even more. > > > To describe in a nutshell (remembering that this is a testbed scenario atm to > > be replicated 1:1 with the real world): > > > > [WAN]<---> [EXTIF/red0][INTIF/green0]<---> [internal network/LAN] > > <---> [VPN - L2TP/IPSec] > > I'm hampered in this by not knowing exactly which ports are used, either > way, by L2TP/IPSec? This would be easier if that were explicit, same > with your other mentioned NAT need, for VoIP. A short tcpdump segment? > > To echo Julian: 'you need to really explain what you want here..' re > the addresses and ports of specific 'unusual' traffic you want NAT'd. IPSec is 500/4500. But atm I'm only trying to get NAT happening; I don't remember it being so hard, but I cant get ordinary NAT working from the system behind the firewall! The Voip I'll work on once I get VPN working- I need to know whether IPSec will work or not before I can put it to use. But for reference it uses 5060/5061 for SIP(S) (both sides, like IPSec), and a range of ports (randomly selected, which determines how many calls can be taken at a time) between 20-30k (or whatever). > > > This is in a VBox environment atm, using a virtual lan. > > > > This is turning out to be a lot harder than I thought; I've tried all kinds > > of tricks but its a complete no go! I resorted to the example in the handbook > > Oh dear. Sorry, but ipfw(8) and rc.firewall are the only decent docs, > you will find it harder if you allow yourself to be misled by that rave; > not unlike teaching structured programming to someone who learned BASIC. The rules are still the same, its how it is read that is the issue :) > > The ipfw handbook section - originally written by someone who > admitedly prefers ipfilter and has written rulesets more suitable for > it, later 'updated' by a plethora of real factual errors and illinformed > advice - is the largest factor mitigating against more widespread and > better-informed use of ipfw, in my view. Yes, I have to plead guilty of > having failed to completely rewrite it, which is its only cure. Funny thing is I seem to remember using the handbook years ago for this, but I don't remember IPFilter being in the book at the time. When I'm done I may be able to shed some light on this if I can scare up enough time. > > > for NAT, and I still cannot communicate from the VPN to the rest of the > > network. I cannot for the life of me determine the reason for this, and I now > > turn to the gurus of the IPFW :) > > > > These are the rules I'm using (for the most part a direct copy/paste of the > > handbook, with some variations such as ssh and non discriminate outbound > > traffic): > > > > #!/bin/sh > > cmd="ipfw -q add" > > skip="skipto 500" > > pif=red0 > > ks="keep-state" > > good_tcpo="22,25,37,43,53,80,443,110,119" > > > > ipfw -q -f flush > > > > $cmd 001 allow log ip from any to any ssh keep-state > > Not here; you're doing that, both in and out, before any NAT remapping. > > You'd be better off using stateful rules (later) for this, at least > while you're getting things sorted out. Ignore the handbook rave's > push to use stateful rules everywhere, often for no good reason. So this isn't a stateful rule (I thought keep-state made it stateful)? And if I put it later wont it get natted too? Or do I exclude it? > > > $cmd 002 allow log all from any to any via green0 # exclude LAN traffic > > This allows all traffic from the LAN in, but also permits all traffic > going out - on _any_ interface including your outside red0 - that came > in on green0! And doing so before any NAT mapping, which will fail. > > Unless you're really familiar with what 'via' does on both inbound and > outbound passes through the firewall (see ipfw(8)), try to always use > 'in recv' and 'out xmit' to disambiguate, especially with outbound. Then thats probably where its failing. I see now. > > > $cmd 003 allow log all from any to any via lo0 # exclude loopback traffic > > In that case 'via' IS appropriate on both passes, but see rc.firewall > for a better approach to handling loopback traffic (both IPv4 and v6). > > > $cmd 100 divert natd log ip from any to any in via $pif > > $cmd 101 check-state log > > Actually the state checking has occurred already on the first keep-state > rule encountered (rule 1). Check rc.firewall 'simple' for the correct > placement of nat/divert rules with anti-spoofing rules both before and > after NAT, some of which you're not doing till way below. > > > # Authorized outbound packets > > $cmd 120 $skip log ip from any to any in via green0 setup $ks > > 'skipto .. keep-state' rules can be very hard to follow. Drop the $ks > if you just want to separate traffic coming 'in recv green0'. > > Anyway, 'skipto 500' according to that ruleset (and the comment below) > is meant to be for _outbound_ traffic, before being NAT'd. This is > confus{ing,ed} at the best of times, but will fail if passed inbound. > > > #$cmd 121 $skip log udp from any to any 53 out via $pif $ks > > #$cmd 125 $skip log tcp from any to any $good_tcpo out via $pif setup $ks > > #$cmd 130 $skip log icmp from any to any out via $pif $ks > > #$cmd 135 $skip log udp from any to any 123 out via $pif $ks > > Argh, that example ruleset is so weird, it's hard to know where to > start. I'd scrap the lot, start with rc.firewall 'simple' with maybe > bits of 'workstation' for outbound traffic, but at least obvious flows. > > > # Deny all inbound traffic from non-routable reserved address spaces > > I think this is where you meant to skipto on _inbound_ traffic, not 500? > > > #$cmd 300 deny log all from 192.168.0.0/16 to any in via $pif #RFC 1918 > > private IP > > $cmd 301 deny log all from 172.16.0.0/12 to any in via $pif #RFC 1918 > > private IP > > $cmd 302 deny log all from 10.0.0.0/8 to any in via $pif #RFC 1918 > > private IP > > $cmd 303 deny log all from 127.0.0.0/8 to any in via $pif #loopback > > $cmd 304 deny log all from 0.0.0.0/8 to any in via $pif #loopback > > $cmd 305 deny log all from 169.254.0.0/16 to any in via $pif #DHCP > > auto-config > > $cmd 306 deny log all from 192.0.2.0/24 to any in via $pif #reserved for > > docs > > $cmd 307 deny log all from 204.152.64.0/23 to any in via $pif #Sun cluster > > $cmd 308 deny log all from 224.0.0.0/3 to any in via $pif #Class D& E > > multicast > > That takes care of spoofed inbound traffic, but doesn't stop spoofed > outbound traffic from your net. Again, refer to rc.firewall. > > > # Authorized inbound packets > > $cmd 400 allow log udp from any to me 68 in $ks > > > > $cmd 440 allow log all from me to any > > $cmd 445 allow log all from any to me > > > > $cmd 450 deny log ip from any to any > > > > # This is skipto location for outbound stateful rules > > $cmd 500 divert natd log ip from any to any out via $pif > > If you skipto 500 on inbound traffic (as above) that'll be ignored, and: > > > The default is to allow (for the moment). > > Even so, an explicit allow|deny rule at end shows counts which may help. Hmm. The main reason I shied away from the rc.firewall is because it _is_ a script (excuse the semantics for the moment), and all the if and case elements make it really hard to follow. But I think I'm going to have to separate the rulesets so I can visually see what the given ruleset does (by whatever means). What you have pointed out here has been partly confusing, but that is in response to content not knowledge, so if I go back and start from scratch with the rc rulesets I think I may have something worked out. > > > I've set the natd in the rc.conf: > > > > gateway_enable="YES" > > firewall_enable="YES" > > firewall_logging="YES" > > natd_enable="YES" > > natd_interface="red0" > > natd_flags="-dynamic -m -log -log_denied" > > Mmm. > > > So I can see the alias logs: > > > > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > > (sock=0) > > icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 > > (sock=0) > > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > > (sock=0) > > icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 > > (sock=0) > > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > > (sock=0) > > icmp=0, udp=12, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=12 > > (sock=0) > > icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 > > (sock=0) > > icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 > > (sock=0) > > icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 > > (sock=0) > > icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 > > (sock=0) > > Mmm, I've never found natd's logging of much use myself. Adding extra > 'count log' rules before and after performing NAT can be more helpful if > anything weird seems to be happening, I find. Hah! But the point was I was actually getting some! Before this the log was empty, so it showed it was working ;) > > > And the firewall logs show that the traffic *from* the VPN hits rule 3 > > quitting at rule 450, and I cannot prevent it no matter what I try. > > rule 3? loopback? 'ipfw show' is better than a verbal description. I'll get that next time. It was late and I couldn't think what other logs to include at the time... For reference I was using that for my own diags. > > > What am I missing here? Logging is verbose and unlimited. I did start with > > exactly what was in the handbook, with ssh turned on and a generic outbound > > skipto. The kernel is built with these options (although I did try without): > > It's sad to have to say, ignore the Handbook and really study ipfw(8). Actually, I was studying both. But it appeared that the two are not talking about the same thing... So in the end I went with the handbook (which is what every good FBSD user knows to do :D wrong call this time!). I will stick to the man now I think ;) > > > include GENERIC > > ident FIREWALL > > > > # IPFW for NAT > > options IPFIREWALL > > options IPFIREWALL_VERBOSE > > options IPFIREWALL_VERBOSE_LIMIT=5 > > More generally bad Handbook advice, based on a misunderstanding of how > syslogd(8) works :( Better using 'log logamount N' for different rules. I figured that, but what is the best course for this? > > > options IPFIREWALL_FORWARD > > Only needed if you're using forward|fwd rules. Otherwise you can use a > GENERIC kernel, loading ipfw and ipdivert. Yet to try with a GENERIC kernel. I started there, but when things went sour I decided to follow the handbook to the letter... I had noticed it was unnecessary from various other posts, but couldn't confirm. I did remember building a kernel in my early days, so I stuck with it. I intend to go back with a working ruleset and try it. > > > options DUMMYNET > > options IPDIVERT > > options HZ=1000 > > > > # ALTQ Support > > options ALTQ > > options ALTQ_CBQ > > options ALTQ_RED > > options ALTQ_RIO > > options ALTQ_HFSC > > options ALTQ_CDNR > > options ALTQ_PRIQ > > #options ALTQ_NOPCC > > options ALTQ_DEBUG > > > > Also, I understand the need for protection from syslog DOS when verbose > > logging is on, but is there any way to mitigate it? The logs show only the > > first hits and then nothing, but they don't count individual peers - just the > > hits. That appears to be quite a hole in the system... > > Well you've got IPFIREWALL_VERBOSE_LIMIT=5. Try 100 while testing, you > can just adjust the sysctl anytime, and add 'logamount N' where needed. > Also, traffic counted both ways under keep-state rules can be confusing. I have it set to 0 atm for testing so I do get the counts, hosts, etc. Its on a protected network, so np. I'm interested in what the recommended/best practice is for this though? What is used on heavily loaded networks? > > > TIA > > > > > > > > > > > As for being a pita - I don't know. It doesn't seem any harder to me, > > > > could even be easier; seems to be a psychological thing. I'll get back to > > > > you (the list) when I have achieved an outcome and let you know. So far I > > > > haven't had to compile a new kernel, so thats a definite plus... that > > > > could change though. More info in the next episode ;) I've just finished > > > > wrestling with certificate generation.... grr! It was easier last time, > > > > not sure what has been the issue this time. > > It is a psychological thing, or rather perhaps philosophical. If you > follow rc.firewall eg 'simple' and 'workstation' and ipfw(8) you'll have > a better clue than the convoluted monstrosities of Handbook examples. Sounds like it. As I said, if you don't have to rebuild kernel, and it can do a lot more than an ordinary firewall, than why isn't out there as the top gun in the industry? Why not an IPFWsense? I know Mac users use it all the time with a little gui frontend and so forth. Plus all the other cool addons via ng make it a real contender anywhere... The rules aren't really any different than any other firewall, the main difference is that the others say its easy: just do this this and this (rub your tummy, pat your head, and hop on one foot while singing an operatic symphony); whereas if they're told this is an advanced firewall for experienced users they're going to say "too hard" and try something else. If I'm right (and although it doesn't look like it now, it still probably is) then PF is actually harder than this; there's more hoops to jump through, and a kernel build which doesn't make sense if IPFW available and doesn't need it. The rulesets dont make quite as much sense, and the instructions on how to operate it aren't in sync, and yet a lot of users flock to it and are willing to go to great lengths to understand and use it. And yet the only advantage PF has over IPFW is the pfsync port for load balancing and failover. Just need to make it a little clearer for the average user and not say "this is going to be hard"... :) > > All IMHO, OC .. > > cheers, Ian > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 25 05:08:04 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83CBA1065672 for ; Sun, 25 Mar 2012 05:08:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 382578FC17 for ; Sun, 25 Mar 2012 05:08:04 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q2P582wG039797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Mar 2012 22:08:03 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F6EA84D.1010604@freebsd.org> Date: Sat, 24 Mar 2012 22:08:29 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Da Rock References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au> In-Reply-To: <4F6E7E39.8080805@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 05:08:04 -0000 On 3/24/12 7:08 PM, Da Rock wrote: > On 03/25/12 02:56, Ian Smith wrote: >> On Sat, 24 Mar 2012, Da Rock wrote: >> > On 03/18/12 02:31, Julian Elischer wrote: >> > > On 3/17/12 1:36 AM, Da Rock wrote: >> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >> > [everything deleted].. ok I'm going to write a little blurb here, as someone who has, 1/ contributed to ipfw 2/ written python code to manipulate ipfw real-time (for code running in cisco appliances.. guess which ones) 3/ used it for many weird things at many times. here are my rules for using ipfw.. 1/ always use a script to make your firewalls.. start by siabling everything end by re-enabing comment extensively 2/ as soon as you start, split your flows to different rule ranges. even if that means duplicating rules... Once you have a set of rules for "incoming rules on re0" you never have to spend cpu cycles testing "in recv re0" on any further rules. It also means you don't have to think of every run of rules from the perspective of several different flows. yes you may have 7 different sets of rules if you have 3 interfaces and lo0, but you won't go insane. Inside rulesets can just be "allow ip from any to any" if you trust your inside interfaces. 3/ get really familiar with all the things you can do with tables. e.g. skipto tablearg/ 4/ use skipto creatively but remember you can oly skip forwards. 5/ remember that keep-state rules, when matched will duplicate whatever the original did so .... skipto 1000 ip from a to b keep-state will skip to 1000 whenever the state matches. this can lead to some really creative rulesets. 6/ when using NAT remember that rules before and after NAT are looking at different packets and that rules before nat are in local addresses going out but external addresses coming in, and teh opposite for after NAT. I always try catch incoming sessions that are actuallydestimed for the local machien before NAT so that my incoming sessions and local services still work if NAT fails. I have not yet used the new 'subroutine' functionality in current but am looking forward to playing with it. Julian From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 25 07:26:20 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F4BD106564A for ; Sun, 25 Mar 2012 07:26:20 +0000 (UTC) (envelope-from freebsd-ipfw@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 05EEF8FC08 for ; Sun, 25 Mar 2012 07:26:19 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 9BDAF5C22 for ; Sun, 25 Mar 2012 17:39:52 +1000 (EST) Message-ID: <4F6EC899.40407@herveybayaustralia.com.au> Date: Sun, 25 Mar 2012 17:26:17 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au> <4F6EA84D.1010604@freebsd.org> In-Reply-To: <4F6EA84D.1010604@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:26:20 -0000 On 03/25/12 15:08, Julian Elischer wrote: > On 3/24/12 7:08 PM, Da Rock wrote: >> On 03/25/12 02:56, Ian Smith wrote: >>> On Sat, 24 Mar 2012, Da Rock wrote: >>> > On 03/18/12 02:31, Julian Elischer wrote: >>> > > On 3/17/12 1:36 AM, Da Rock wrote: >>> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >>> > > > [everything deleted].. > > > ok I'm going to write a little blurb here, as someone who has, > 1/ contributed to ipfw > 2/ written python code to manipulate ipfw real-time (for code running > in cisco appliances.. guess which ones) > 3/ used it for many weird things at many times. If I may ask, what kind of weird things and how? > > > here are my rules for using ipfw.. > > 1/ always use a script to make your firewalls.. > start by siabling everything > end by re-enabing > comment extensively > > 2/ as soon as you start, split your flows to different rule ranges. > even if that means duplicating rules... Once you have a set of rules for > "incoming rules on re0" you never have to spend cpu cycles testing "in > recv re0" > on any further rules. It also means you don't have to think of every > run of rules > from the perspective of several different flows. > > yes you may have 7 different sets of rules if you have 3 interfaces > and lo0, but > you won't go insane. Inside rulesets can just be "allow ip from any > to any" if you trust your inside interfaces. > > 3/ get really familiar with all the things you can do with tables. > e.g. skipto tablearg/ > > 4/ use skipto creatively but remember you can oly skip forwards. > > 5/ remember that keep-state rules, when matched will duplicate > whatever the original did > so .... skipto 1000 ip from a to b keep-state will skip to 1000 > whenever the state matches. > this can lead to some really creative rulesets. > > 6/ when using NAT remember that rules before and after NAT are looking > at different packets and > that rules before nat are in local addresses going out but external > addresses coming in, and teh opposite for after NAT. I always try > catch incoming sessions that are actuallydestimed for the local > machien before NAT so that my incoming sessions and local services > still work if NAT fails. Wow! That is really helpful. Why isn't *that* in the handbook? I had considered breaking everything up into sections and using skipto, but I _hadn't_ picked up on the fact that you can only go forwards- good catch there. I'm assuming you can use tags like in pf? Would that work well in such an environment where it is all sectioned? When you speak of sets, how are they used? Are you using the sets feature mentioned in the man ipfw(8)? I'm still a little confused on how these would be used as yet, but I intend to investigate further because the comments in the man page intrigued me in the reference to "hot swapping" sets on an attacked firewall to further close it up. As for my motto: "dont trust anyone." So I disable all and only let in what is required under strict conditions- even on the internal interfaces. This is a test scenario atm though, and I will set about locking it all up and implementing a production setup *if* IPSec works. > > > I have not yet used the new 'subroutine' functionality in current but > am looking forward > to playing with it. That sounds interesting. How would that work? Are we talking about a switch from old procedural-like to more OO-like? I'll be back with more questions I'm sure... Meanwhile I have to go and put this stuff into practice :) From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 00:36:31 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F864106564A for ; Mon, 26 Mar 2012 00:36:31 +0000 (UTC) (envelope-from taipeii120@davisandsons.net) Received: from telesp.net.br (201-95-97-10.dsl.telesp.net.br [201.95.97.10]) by mx1.freebsd.org (Postfix) with ESMTP id B6B2F8FC21 for ; Mon, 26 Mar 2012 00:36:30 +0000 (UTC) Received: from apache by freebsd.org with local (Exim 4.67) (envelope-from ) id 3945QX-77K29L-ZI for ; Sun, 25 Mar 2012 21:36:29 -0300 To: X-PHP-Script: freebsd.org/sendmail.php for 201.95.97.10 From: X-Sender: X-Mailer: PHP X-Priority: 1 Content-Type: text/plain; charset="iso-8859-2" Message-Id: Date: Sun, 25 Mar 2012 21:36:29 -0300 Cc: Subject: Job Offer - Flexible Hours X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 00:36:31 -0000 I would like to take this time to welcome you to our hiring process and give you a brief synopsis of the position's benefits and requirements. If you are taking a career break, are on a maternity leave, recently retired or simply looking for some part-time job, this position is for you. Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation Salary: Starting salary is 2000 EUR per month plus commission, paid every month. Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time). Region: Europe. Please note that there are no startup fees or deposits to start working for us. To request an application form, schedule your interview and receive more information about this position please reply to Wilbur@jobdayseu.com,with your personal identification number for this position IDNO: 2679 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 01:57:03 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D98C41065673 for ; Mon, 26 Mar 2012 01:57:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id ADE578FC1B for ; Mon, 26 Mar 2012 01:57:03 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q2Q1usCj043369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 25 Mar 2012 18:56:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F6FCD02.6040001@freebsd.org> Date: Sun, 25 Mar 2012 18:57:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Da Rock References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au> <4F6EA84D.1010604@freebsd.org> <4F6EC899.40407@herveybayaustralia.com.au> In-Reply-To: <4F6EC899.40407@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 01:57:03 -0000 On 3/25/12 12:26 AM, Da Rock wrote: > On 03/25/12 15:08, Julian Elischer wrote: >> On 3/24/12 7:08 PM, Da Rock wrote: >>> On 03/25/12 02:56, Ian Smith wrote: >>>> On Sat, 24 Mar 2012, Da Rock wrote: >>>> > On 03/18/12 02:31, Julian Elischer wrote: >>>> > > On 3/17/12 1:36 AM, Da Rock wrote: >>>> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >>>> > >> >> [everything deleted].. >> >> >> ok I'm going to write a little blurb here, as someone who has, >> 1/ contributed to ipfw >> 2/ written python code to manipulate ipfw real-time (for code >> running in cisco appliances.. guess which ones) >> 3/ used it for many weird things at many times. > If I may ask, what kind of weird things and how? some examples (I've forgotten some I'm sure) used the 'fwd' rule and tables to implement multiple routing tables, before I actually added multiple routing tables to the system. used level2 firewalling (plus some patches) to implement a transparent firewalling bridge. (a firewalling cable so to speak.) used fwd, (with some patches) to implement transparent redirection to a web proxy. >> >> >> here are my rules for using ipfw.. >> >> 1/ always use a script to make your firewalls.. >> start by siabling everything >> end by re-enabing >> comment extensively >> >> 2/ as soon as you start, split your flows to different rule ranges. >> even if that means duplicating rules... Once you have a set of >> rules for >> "incoming rules on re0" you never have to spend cpu cycles testing >> "in recv re0" >> on any further rules. It also means you don't have to think of >> every run of rules >> from the perspective of several different flows. >> >> yes you may have 7 different sets of rules if you have 3 interfaces >> and lo0, but >> you won't go insane. Inside rulesets can just be "allow ip from >> any to any" if you trust your inside interfaces. >> >> 3/ get really familiar with all the things you can do with tables. >> e.g. skipto tablearg/ >> >> 4/ use skipto creatively but remember you can oly skip forwards. >> >> 5/ remember that keep-state rules, when matched will duplicate >> whatever the original did >> so .... skipto 1000 ip from a to b keep-state will skip to >> 1000 whenever the state matches. >> this can lead to some really creative rulesets. >> >> 6/ when using NAT remember that rules before and after NAT are >> looking at different packets and >> that rules before nat are in local addresses going out but external >> addresses coming in, and teh opposite for after NAT. I always try >> catch incoming sessions that are actuallydestimed for the local >> machien before NAT so that my incoming sessions and local services >> still work if NAT fails. > Wow! That is really helpful. Why isn't *that* in the handbook? > > I had considered breaking everything up into sections and using > skipto, but I _hadn't_ picked up on the fact that you can only go > forwards- good catch there. That is in the man page.. > > I'm assuming you can use tags like in pf? Would that work well in > such an environment where it is all sectioned? I have never needed tags. But I know others that use them.. they do add some overhead per packet. > > When you speak of sets, how are they used? Are you using the sets > feature mentioned in the man ipfw(8)? I'm still a little confused on > how these would be used as yet, but I intend to investigate further > because the comments in the man page intrigued me in the reference > to "hot swapping" sets on an attacked firewall to further close it up. I have sets for each interface.. so I can switch on firewalling and nat on each interface individually for testing or if something goes wrong. A differnet NAT interface for each interface is also useful. theoretically a single natd process can do multiple contexts at once with different port numbers etc, but the one time I tried it, it didn;t work so I switched to multiple instances of natd. > > As for my motto: "dont trust anyone." So I disable all and only let > in what is required under strict conditions- even on the internal > interfaces. This is a test scenario atm though, and I will set about > locking it all up and implementing a production setup *if* IPSec works. I've used IPSEC successfully with home-grown tunnels using netgraph ksocket nodes connected to netgraph ng_iface interfaces. Now that we can have multiple stack instances it gets even more interesting, as you can forward other jails to do tunnel encapsulation and such. the variety and number of options you have to achieve any task is getting bewilderingly high. for any task you can probably get 3 or 4 completely different suggestions as to how it can be done, >> >> >> I have not yet used the new 'subroutine' functionality in current >> but am looking forward >> to playing with it. > That sounds interesting. How would that work? Are we talking about a > switch from old procedural-like to more OO-like? As I said, I haven't really looked but I gather it's like a 'skipto' except that you can 'return' > > I'll be back with more questions I'm sure... Meanwhile I have to go > and put this stuff into practice :) go read the man pages for ipfw, divert, netgraph (AND all it's module types), the route command including the 'newish' setfib stuff, the jail command with specific reference to having a separate complete networking stack in each jail (including it's own firewall), (and ifconfig vnet command), natd, ipfw nat options, mpd (a port)and ppp. and as if that wasn't enough.. pf, tun, if_bridge, epair, gif, stf, and I'm sure I forgot a bunch. there will be test next week :-) > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 11:07:07 2012 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43D61065672 for ; Mon, 26 Mar 2012 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE2D18FC0A for ; Mon, 26 Mar 2012 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2QB76OV018302 for ; Mon, 26 Mar 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2QB76Tb018300 for freebsd-ipfw@FreeBSD.org; Mon, 26 Mar 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Mar 2012 11:07:06 GMT Message-Id: <201203261107.q2QB76Tb018300@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking f kern/163873 ipfw [ipfw] ipfw fwd does not work with 'via interface' in o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 17:42:46 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CA451065678; Mon, 26 Mar 2012 17:42:46 +0000 (UTC) (envelope-from indecencyf490@momix.org) Received: from p54A6E36B.dip.t-dialin.net (p54A6E36B.dip.t-dialin.net [84.166.227.107]) by mx1.freebsd.org (Postfix) with ESMTP id 0C7CD8FC21; Mon, 26 Mar 2012 17:42:46 +0000 (UTC) Received: from apache by freebsd.org with local (Exim 4.63) (envelope-from , ) id 005S5T-WNDCDC-J6 for , ; Mon, 26 Mar 2012 18:42:44 +0100 To: , Date: Mon, 26 Mar 2012 18:42:44 +0100 From: , Message-ID: <95DDA3280F1693625E2D0A2D7E28AACA@freebsd.org> X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="windows-1250" Cc: Subject: Working Part Time X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:42:46 -0000 I would like to take this time to welcome you to our hiring process and give you a brief synopsis of the position's benefits and requirements. If you are taking a career break, are on a maternity leave, recently retired or simply looking for some part-time job, this position is for you. Occupation: Flexible schedule 2 to 8 hours per day. We can guarantee a minimum 20 hrs/week occupation Salary: Starting salary is 2000 EUR per month plus commission, paid every month. Business hours: 9:00 AM to 5:00 PM, MON-FRI, 9:00 AM to 1:00 PM SAT or part time (Europe time). Region: Europe. Please note that there are no startup fees or deposits to start working for us. To request an application form, schedule your interview and receive more information about this position please reply to Saul@jobdayseu.com,with your personal identification number for this position IDNO: 2541 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 21:25:34 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9714E106566C; Mon, 26 Mar 2012 21:25:34 +0000 (UTC) (envelope-from cupsfulja6250@twaron.com) Received: from 253.Red-81-35-70.dynamicIP.rima-tde.net (253.Red-81-35-70.dynamicIP.rima-tde.net [81.35.70.253]) by mx1.freebsd.org (Postfix) with ESMTP id 3E2F88FC0C; Mon, 26 Mar 2012 21:25:34 +0000 (UTC) Received: from apache by vevcejxdjcxeldcvcwcajv.siaminet.com with local (Exim 4.63) (envelope-from <, , , , >) id RPI5QA-O15DWW-QC for , , , , ; Mon, 26 Mar 2012 22:25:33 +0100 To: , , , , Date: Mon, 26 Mar 2012 22:25:33 +0100 From: , , , , Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-2" Cc: Subject: Job opportunity - hurry to apply! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:25:34 -0000 I would like to take this time to welcome you to our hiring process and give you a brief synopsis of the position's benefits and requirements. If you are taking a career break, are on a maternity leave, recently retired or simply looking for some part-time job, this position is for you. Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation Salary: Starting salary is 3000 EUR per month plus commission. Region: Europe Please note that there are no startup fees or deposits to start working for us. To request an application form, schedule your interview and receive more information about this position please reply to Wilford@jobdayseu.com,with your personal identification number for this position IDNO: 8604 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 26 23:12:43 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 22617106564A for ; Mon, 26 Mar 2012 23:12:43 +0000 (UTC) (envelope-from terrence@mediamonks.net) Received: from mail.mediamonks.net (mail.mediamonks.net [217.195.117.200]) by mx1.freebsd.org (Postfix) with ESMTP id A72028FC14 for ; Mon, 26 Mar 2012 23:12:42 +0000 (UTC) X-CGP-Sophos: Scanned and found clean X-Abuse-Info: Send abuse reports about this email to abuse@mediamonks.net Received: from [46.44.172.93] (account terrence@mediamonks.com) by mail.mediamonks.net (CommuniGate Pro IMAP 5.4.2) with XMIT id 8562934 for ipfw@freebsd.org; Tue, 27 Mar 2012 01:12:41 +0200 Date: Tue, 27 Mar 2012 01:12:40 +0200 Organization: MediaMonks B.V. Message-Id: MIME-Version: 1.0 Thread-Topic: Packetloss due to ipfw + kernel NAT? Priority: Normal Importance: normal X-MSMail-Priority: normal X-Priority: 3 Sensitivity: Normal Thread-Index: Ac0LpfC9h+jugILzS6qNF2k0NywH/Q== From: "Terrence Koeman" To: "ipfw@freebsd.org" X-Mailer: CommuniGate Pro MAPI Connector 1.52.54.6/1.54.0.6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Subject: Packetloss due to ipfw + kernel NAT? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 23:12:43 -0000 I was troubleshooting an intermittent network connectivity problem, and I n= oticed something weird. My situation: [internet]<->[freebsd box]<->[clients] FreeBSD box (9-STABLE) has 172.16.0.1 on int0 (mtu 1500), x.x.172.84-85 on = ng0 (pppoe via mpd, mtu 1492). Clients are assigned from 172.16.10/24{100-2= 00}. I stripped almost everything from my ruleset, so this remains: natip=3D"x.x.172.85" $cmd enable one_pass $cmd nat 10 config ip ${natip} same_ports $cmd add 04020 nat 10 all from any to ${natip} in $cmd add 04031 nat 10 all from ${intnet} to not ${intnet} out Now, I suspected a MTU issue, so I tried some different packet sizes to see= what happens: On FreeBSD box: ping -S x.x.172.84 -s 1400 mediamonks.net -> no packetloss ping -S x.x.172.84 -s 1500 mediamonks.net -> no packetloss ping -S x.x.172.84 -s 2500 mediamonks.net -> no packetloss ping -S x.x.172.84 -s 3000 mediamonks.net -> no packetloss ping -S x.x.172.84 -s 5000 mediamonks.net -> no packetloss ping -S x.x.172.85 -s 1400 mediamonks.net -> no packetloss ping -S x.x.172.85 -s 1500 mediamonks.net -> ~40% packetloss ping -S x.x.172.85 -s 2500 mediamonks.net -> ~40% packetloss ping -S x.x.172.85 -s 3000 mediamonks.net -> ~3% packetloss ping -S x.x.172.85 -s 5000 mediamonks.net -> no packetloss On client 172.16.10.101 (Windows 7 x64): ping -l 1400 mediamonks.net -> no packetloss ping -l 1500 mediamonks.net -> ~40% packetloss ping -l 2500 mediamonks.net -> ~40% packetloss ping -l 3000 mediamonks.net -> no packetloss ping -l 5000 mediamonks.net -> no packetloss If I set natip to x.x.172.84 the packetloss moves to that IP and remains th= e same for the client. Forcing the MTU on the Windows client to 1492 does n= ot change the result. I double checked the result for packetsize 3000 since= the result differs between the client and the FreeBSD box, but there is re= ally no packetloss for the client while there is some on the FreeBSD box. Does someone know what is happening here? Is this a bug in ipfw? -- Regards, T. Koeman, MTh/BSc/BPsy; Technical Monk MediaMonks B.V. (www.mediamonks.com) Please quote relevant replies in correspondence. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 27 13:34:55 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D351065670 for ; Tue, 27 Mar 2012 13:34:55 +0000 (UTC) (envelope-from freebsd-ipfw@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 36B1B8FC1D for ; Tue, 27 Mar 2012 13:34:55 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id CC1AA5C22 for ; Tue, 27 Mar 2012 23:48:28 +1000 (EST) Message-ID: <4F71C1FE.3090201@herveybayaustralia.com.au> Date: Tue, 27 Mar 2012 23:34:54 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au> <4F6EA84D.1010604@freebsd.org> <4F6EC899.40407@herveybayaustralia.com.au> <4F6FCD02.6040001@freebsd.org> In-Reply-To: <4F6FCD02.6040001@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:34:56 -0000 On 03/26/12 11:57, Julian Elischer wrote: > On 3/25/12 12:26 AM, Da Rock wrote: >> On 03/25/12 15:08, Julian Elischer wrote: >>> On 3/24/12 7:08 PM, Da Rock wrote: >>>> On 03/25/12 02:56, Ian Smith wrote: >>>>> On Sat, 24 Mar 2012, Da Rock wrote: >>>>> > On 03/18/12 02:31, Julian Elischer wrote: >>>>> > > On 3/17/12 1:36 AM, Da Rock wrote: >>>>> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >>>>> > >>> >>> [everything deleted].. >>> >>> >>> ok I'm going to write a little blurb here, as someone who has, >>> 1/ contributed to ipfw >>> 2/ written python code to manipulate ipfw real-time (for code >>> running in cisco appliances.. guess which ones) >>> 3/ used it for many weird things at many times. >> If I may ask, what kind of weird things and how? > > some examples (I've forgotten some I'm sure) > > used the 'fwd' rule and tables to implement multiple routing tables, > before I actually added multiple routing tables to the system. > > used level2 firewalling (plus some patches) to implement a transparent > firewalling bridge. > (a firewalling cable so to speak.) > > used fwd, (with some patches) to implement transparent redirection to > a web proxy. > > >>> >>> >>> here are my rules for using ipfw.. >>> >>> 1/ always use a script to make your firewalls.. >>> start by siabling everything >>> end by re-enabing >>> comment extensively >>> >>> 2/ as soon as you start, split your flows to different rule ranges. >>> even if that means duplicating rules... Once you have a set of >>> rules for >>> "incoming rules on re0" you never have to spend cpu cycles testing >>> "in recv re0" >>> on any further rules. It also means you don't have to think of >>> every run of rules >>> from the perspective of several different flows. >>> >>> yes you may have 7 different sets of rules if you have 3 interfaces >>> and lo0, but >>> you won't go insane. Inside rulesets can just be "allow ip from any >>> to any" if you trust your inside interfaces. >>> >>> 3/ get really familiar with all the things you can do with tables. >>> e.g. skipto tablearg/ >>> >>> 4/ use skipto creatively but remember you can oly skip forwards. >>> >>> 5/ remember that keep-state rules, when matched will duplicate >>> whatever the original did >>> so .... skipto 1000 ip from a to b keep-state will skip to >>> 1000 whenever the state matches. >>> this can lead to some really creative rulesets. >>> >>> 6/ when using NAT remember that rules before and after NAT are >>> looking at different packets and >>> that rules before nat are in local addresses going out but external >>> addresses coming in, and teh opposite for after NAT. I always try >>> catch incoming sessions that are actuallydestimed for the local >>> machien before NAT so that my incoming sessions and local services >>> still work if NAT fails. >> Wow! That is really helpful. Why isn't *that* in the handbook? >> >> I had considered breaking everything up into sections and using >> skipto, but I _hadn't_ picked up on the fact that you can only go >> forwards- good catch there. > That is in the man page.. Yep. But that didn't mean it registered... :) >> >> I'm assuming you can use tags like in pf? Would that work well in >> such an environment where it is all sectioned? > > I have never needed tags. But I know others that use them.. they do > add some overhead per packet. >> >> When you speak of sets, how are they used? Are you using the sets >> feature mentioned in the man ipfw(8)? I'm still a little confused on >> how these would be used as yet, but I intend to investigate further >> because the comments in the man page intrigued me in the reference to >> "hot swapping" sets on an attacked firewall to further close it up. > I have sets for each interface.. > so I can switch on firewalling and nat on each interface individually > for testing or if something goes wrong. > > A differnet NAT interface for each interface is also useful. > theoretically a single natd process can do multiple contexts at once > with different port numbers etc, > but the one time I tried it, it didn;t work so I switched to multiple > instances of natd. I have to look into how exactly that works yet. It sounds useful to my own needs in some way I haven't quite out > >> >> As for my motto: "dont trust anyone." So I disable all and only let >> in what is required under strict conditions- even on the internal >> interfaces. This is a test scenario atm though, and I will set about >> locking it all up and implementing a production setup *if* IPSec works. > I've used IPSEC successfully with home-grown tunnels using netgraph > ksocket nodes connected to netgraph ng_iface interfaces. Now that we > can have multiple stack instances it gets even more interesting, as > you can forward other jails to do tunnel encapsulation and such. > > the variety and number of options you have to achieve any task is > getting bewilderingly high. > for any task you can probably get 3 or 4 completely different > suggestions as to how it can be done, Amen to that! I'm still trying to sort through it all for my own needs. > > > >>> >>> >>> I have not yet used the new 'subroutine' functionality in current >>> but am looking forward >>> to playing with it. >> That sounds interesting. How would that work? Are we talking about a >> switch from old procedural-like to more OO-like? > > As I said, I haven't really looked but I gather it's like a 'skipto' > except that you can 'return' Hmm, I think I see that - that would be extremely useful (especially considering my thoughts on using skipto before I knew it was only pass forward). > >> >> I'll be back with more questions I'm sure... Meanwhile I have to go >> and put this stuff into practice :) > > go read the man pages for ipfw, divert, netgraph (AND all it's module > types), the route command including the 'newish' setfib stuff, the > jail command with specific reference to having a separate complete > networking stack in each jail (including it's own firewall), (and > ifconfig vnet command), natd, ipfw nat options, mpd (a port)and ppp. > and as if that wasn't enough.. pf, tun, if_bridge, epair, gif, stf, > and I'm sure I forgot a bunch. I'm still going through it all (amongst other tasks), but I did come across one thing: why nat only ip4 (simple/client/open)? Isn't nat still a possibility on ipv6 (for one of the original reasons it was used on ip4- anonymity)? > > there will be test next week :-) I'll be ready :P > > > >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 28 08:53:46 2012 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37A4106566C; Wed, 28 Mar 2012 08:53:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A6E808FC1B; Wed, 28 Mar 2012 08:53:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2S8rkn7037055; Wed, 28 Mar 2012 08:53:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2S8rkrh037051; Wed, 28 Mar 2012 08:53:46 GMT (envelope-from linimon) Date: Wed, 28 Mar 2012 08:53:46 GMT Message-Id: <201203280853.q2S8rkrh037051@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166406: [ipfw] ipfw does not set ALTQ identifier for ipv6 traffic X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:53:46 -0000 Old Synopsis: ipfw does not set ALTQ identifier for ipv6 traffic New Synopsis: [ipfw] ipfw does not set ALTQ identifier for ipv6 traffic Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 08:53:25 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166406