Date: Sun, 25 Mar 2012 03:56:28 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Da Rock <freebsd-ipfw@herveybayaustralia.com.au> Cc: freebsd-ipfw@freebsd.org, Julian Elischer <julian@freebsd.org> Subject: Re: newbie IPFW user - when handbook examples dont work... Message-ID: <20120325013410.H2060@sola.nimnet.asn.au> In-Reply-To: <4F6D1D00.1080607@herveybayaustralia.com.au> References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1336100332-1332606636=:2060
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <20120325033051.D2060@sola.nimnet.asn.au>
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?
> 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.
> 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.
<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>
> 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.
> $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.
> $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.
> 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.
> 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.
> 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).
> 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.
> options IPFIREWALL_FORWARD
Only needed if you're using forward|fwd rules. Otherwise you can use a
GENERIC kernel, loading ipfw and ipdivert.
> 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.
> 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.
All IMHO, OC ..
cheers, Ian
--0-1336100332-1332606636=:2060--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120325013410.H2060>