question on NAT + IPFW
smithi at nimnet.asn.au
Fri Jun 12 11:33:22 UTC 2015
On Fri, 12 Jun 2015 10:24:05 +0200, Guido Falsi wrote:
> On 06/12/15 10:07, Ian Smith wrote:
> > On Fri, 12 Jun 2015 08:59:40 +0200, Guido Falsi wrote:
> > > > looks correct, assuming xl0 is your internal interface (better put it in
> > > > a variable and use the variable in your rules imho)
> > >
> > > Forgot one thing, working around this block is as easy as changing the
> > > machine IP, teenager can learn this easily and it can be done in a lot
> > > of ways, even if they are not root(or equivalent) on their machine, they
> > > can just boot from a CD with some live OS. You could have a better block
> > > by also checking the MAC address, like this:
> > >
> > > $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0
> > >
> > > (not tested)
> > >
> > > MAC addresses can be modified too but it's somewhat more difficult.
> > While that's all true, blocking at layer 2 requires extra work that may
> > be beyond what's needed here, to have ipfw deal with layer 2 traffic.
> > sysctl net.link.ether.ipfw=1 must be set for ipfw to see layer 2 packets
> > at all, and then you'd need to follow ipfw(8) section PACKET FLOW to
> > separate the layer 2 and 3 traffic in order to look at MAC addresses on
> > the appropriate one of the extra two passes through ipfw this entails.
> Uhm, I forgot to check these details. Yes, layer 2 is a lot more work
> anyway, I avoid it if possible.
> I also did not read carefully the example given, my fault on that too :)
Those examples are so wrong on so many counts that I never know where to
even start on fixing them; I've banged on often enough about these to
annoy some folks so I won't go on .. except that the first rule quoted:
$cmd 005 allow all from any to any via xl0 # exclude LAN traffic
is crazy in the context of wanting to do NAT on packets from the LAN
bound for the outside interface. No checks, anti-spoofing, nothing.
Need icmp for path MTU discovery? Too bad. Need UDP frags for such as
zen.spamhaus.org responses, let alone DNSSEC? Tough. Expect ntpd to
work over TCP port 37, or NETBIOS on TCP ports 137,138? Good luck ..
Fortunately lev@ is working (in ipfw@) on some new stateful rule actions
to decouple state setting and checking to avoid needing such as twisty
skipto constucts for handling stateful rules, at which point updating
the handbook might also be timely; I do have a few bits half-written.
Take-away: ipfw(8) is your friend, and pretty much your only friend
apart from what's in rc.firewall (and even that lacks proper icmp).
More information about the freebsd-net