Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Feb 2004 14:54:32 -0500
From:      "Matt Emmerton" <matt@gsicomp.on.ca>
To:        "John" <john@starfire.mn.org>, <freebsd-net@freebsd.org>
Subject:   Re: IPFW and NAT - blocking RFC 1918 ("unregistered") network thatmatches my own
Message-ID:  <002601c3ec21$df9dea10$1200a8c0@gsicomp.on.ca>
References:  <20040205134555.A28070@starfire.mn.org>

next in thread | previous in thread | raw e-mail | index | archive | help

----- Original Message ----- 
From: "John" <john@starfire.mn.org>
To: <freebsd-net@freebsd.org>
Sent: Thursday, February 05, 2004 2:45 PM
Subject: IPFW and NAT - blocking RFC 1918 ("unregistered") network
thatmatches my own


> I am up and running with ipfw 2 and natd, but not all is quite well.
>
> I can't figure out how to block "spoofed" packets from the outside
> that use the same RFC 1918 network as the one I'm translating to.
> When I try to put that rule on the exterior interface, it ends up
> blocking the packets after they are translated.
>
> Specifically, the network I am using falls in the 192.168.0.0/16 range.
> (I won't publish exactly which one: you only have 254 to try...)
> If, however, I put in
>     ${fwcmd} add deny ip from any to 192.168.0.0/16 via ${oif}
> then I cut off my interior network entirely, due, presumably, to
> the pass through the rules after translation.
>
> I suspect that I need some combination of "in" or "recv," but I
> would like to actually UNDERSTAND what I'm doing instead of just
> trying combinations 'til it works.  On the other hand, there are
> sysctl kernel parameters that might affect this behavior, or maybe
> other natd parameters - so maybe that's not even the ticket.

Your best resource is /etc/rc.firewall.  Look at the "simple" configuration.
It has rules for RFC1918 nets both before and after the divert rule, and
explains why.

--
Matt Emmerton



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002601c3ec21$df9dea10$1200a8c0>