Date: Sun, 2 Dec 2001 13:28:04 -0800 From: "Crist J . Clark" <cristjc@earthlink.net> To: Thor Legvold <tlegvold@hotmail.com> Cc: cjc@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Firewall rules (ipfw) Message-ID: <20011202132804.A27117@blossom.cjclark.org> In-Reply-To: <F101YbZhoItg3V3Ny2A000137f7@hotmail.com>; from tlegvold@hotmail.com on Sun, Dec 02, 2001 at 01:43:34PM %2B0000 References: <F101YbZhoItg3V3Ny2A000137f7@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 02, 2001 at 01:43:34PM +0000, Thor Legvold wrote:
> Crist wrote:
>
> >These DHCP rules are a bit messed up. ITYM something more like,
>
> Duly noted. Thanks. BTW, what's ITYM mean?
>
> > > # Allow GRE & PPTP control connection
> > > ${fwcmd} add allow tcp from any to any 1723 in recv cable0 setup
> > > ${fwcmd} add allow gre from any to any via cable0
> >
> >Nothing here allows you to talk back on that TCP connection.
>
> Meaning I should allow TCP on 1723 both ways? Are both mahines using 1723,
> or only the PPTP server (client in that case on >1023?)
The TCP connection will use the same ports at both ends. Oh, and I
forgot to mention that you are only ever letting the initial SYN from
the remote machine in either. A simple rule for allowing this
connection would be,
${fwcmd} add allow tcp from any to any 1723 in recv cable0
${fwcmd} add allow tcp from any 1723 to any out xmit cable0
> > > # Stop all other traffic via cable0 - only GRE/PPTP/DHCP allowed
> > > ${fwcmd} add deny log all from any to any via cable0
> >
> >Nothing else at all is going to go in or out? OK.
>
> Well, my intention was to allow GRE only incoming to nat (as only GRE
> packets are intended for my machine over the cable0/pptp link - all else is
> garbage, or dhcp), and anything outgoing (via nat). That would reduce 80% of
> the traffic on the cable0 iface reaching nat and my LAN. Seems that's not
> really feasable though.
>
> > > # NAT
> > > ${fwcmd} add divert natd log all from any to any via tun0
> >
> >OK.
>
> Not ok. Nothing reaches nat (tried it today). I also tried allowing only GRE
> to nat (instead of all), that didn't work either (I think becuase while
> incoming packets are gre, outgoing one's arent...)
Well, nothing coming in from the cable interface is ever going to pass
this rule since only packets crossing the tun0 interface match.
> Guess I'll go back to diverting all and concentrate on getting the rules
> right when the packets appear on the tun0 iface coming in.
I think you might need to stop an thing about how this really
works. First, the packets come in via the cable0 interface. There,
they are either accepted if they are PPTP (or DHCP) related or
dropped. That's our first run through the firewall. (I'm not so sure
of this next part.) Somehow these packets now find their way to PPTP
processing. After being de-encapsulated from PPTP, they are reinjected
into the machine network's stack via tun0. So we enter the firewall a
second time. This time, the packets should go through natd(8). After
passing through natd(8), you may or may not wish to add some rules to
restrict what traffic may pass. Now, the packets that have gone
through natd(8) and passed a later rule in the firewall are processed
_again_ by the gateway machine. (I assume this machine has an
interface on a private network.) Any packets destined for machines on
the private network now go through the firewall one last time as they
leave. They obviously need to pass a firewall rule to get out.
Like I said, I'm a bit fuzzy on how the whole PPTP thing works, so
this may be a little bit off.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
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?20011202132804.A27117>