Date: Mon, 7 Aug 2000 11:30:36 +0200 From: Willem Brown <willem@brwn.org> To: David Goddard <goddard@acm.org> Cc: kstewart@urx.com, freebsd-questions@FreeBSD.ORG Subject: Re: ppp and natd problems Message-ID: <20000807113036.A86037@snoopy.brwn.org> In-Reply-To: <3.0.3.32.20000806212605.0083de00@dmg.parse.net>; from goddard@acm.org on Sun, Aug 06, 2000 at 09:26:05PM %2B0100 References: <3.0.3.32.20000806173201.0085c330@dmg.parse.net> <398DBA23.39F41E5E@urx.com> <3.0.3.32.20000806212605.0083de00@dmg.parse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Sun, Aug 06, 2000 at 09:26:05PM +0100, David Goddard wrote:
> Thanks for the really prompt reply - a handy site that I wasn't aware of.
> Dan's dual homed example helped me to get NAT working OK with ppp, but I
> found that my ipfw rules were still causing problems. Specifically, the
> rules to disallow RFC1918 nets killed connections from the internal network
> (which is, oddly enough, RCF1918 ;)
>
> I tried a couple of configurations to test this and found that the rule
> that broke things was:
>
> [...]
> # Stop RFC1918 nets on the outside interface
> [...]
> $fwcmd add deny all from any to 10.0.0.0:255.0.0.0 via ${oif}
Try changing the above rule to something like the following.
$fwcmd add deny all from any to 10.0.0.0:255.0.0.0 out via ${oif}
$fwcmd add deny all from 10.0.0.0:255.0.0.0 to any in via ${oif}
The first rule should stop you from sending packets to RFC1918 nets and the
second will stop packets from RFC1918 nets coming from the outside.
ipfw seems to change the in via and out via to in recv and out xmit respectively,
but the above seems to work.
You would also add the other two RFC1918 nets, as well as a filter for the
127.0.0.0 net for packets coming in via the outside interface. Just in case...
> [...]
>
> I'm not sure why this is a problem - tcpdump still shows that private IP
> addresses aren't passing through it, but I turned logging on for the
> suspect rule and it reported the following:
>
> Aug 6 21:15:35 dmg /kernel: ipfw: 1000 Deny ICMP:0.0 195.200.0.87 10.0.0.3
> in via tun0
>
> This all *seems* logical, after all the rule does say to deny stuff for
> 10.0.0.3 coming in from outside, but I don't get why we would want the
> default rc.firewall rules to behave like this. Surely we should just be
> blocking any RFC1918 stuff if ppp tries to send it untranslated (i.e. if
> nat isn't working)?
>
> Or maybe I'm just missing something :-)
>
> Thanks,
>
> Dave
>
> At 12:18 06/08/00 -0700, Kent Stewart wrote:
> ...
> >I never found the FreeBSD examples to work on my system for ipfw. The
> >setup on http://www.mostgraveconcern.com/freebsd/ worked out of the
> >box. Ruslan's has some changes that look like they would address the
> >problem I had on my system. I also changed from one of the 169.254.x.x
> >style non-routeable networks to one of the 10.0.x.x. style RFC1918
> >internal networks. I use Dan's dual homed example ipfw setup on my
> >system plus a couple of changes. The only difference for you would be
> >your definition of the outside network.
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
>
HTH
Best regards
Willem Brown
--
/* =============================================================== */
/* Linux, FreeBSD, NetBSD, OpenBSD. The choice is yours. */
/* =============================================================== */
In case of doubt, make it sound convincing.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000807113036.A86037>