Date: Sun, 25 Mar 2012 12:08:57 +1000 From: Da Rock <freebsd-ipfw@herveybayaustralia.com.au> To: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... Message-ID: <4F6E7E39.8080805@herveybayaustralia.com.au> In-Reply-To: <20120325013410.H2060@sola.nimnet.asn.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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]<IPFW>[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 :)
>
> <rant> 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.</rant>
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6E7E39.8080805>