Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jul 2002 08:03:04 +0200 (MET DST)
From:      Helge Oldach <helge.oldach@atosorigin.com>
To:        fb-stable@psconsult.nl (Paul Schenkeveld)
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: IPsec and IPfilter interaction
Message-ID:  <200207080603.IAA22096@galaxy.de.cp.philips.com>
In-Reply-To: <20020707222803.A57511@psconsult.nl> from Paul Schenkeveld at "Jul 7, 2002 10:28: 3 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Paul Schenkeveld:
>On Sun, Jul 07, 2002 at 10:16:19PM +0200, Helge Oldach wrote:
>> Paul Schenkeveld:
>> >(Not sure if this is the right list to discuss this, point me to a
>> >better list please if I'm wrong.)
>> 
>> -questions?
>> 
>> >    The configuration of the SPD for tunnel mode is very similar to that
>> >    of transport mode. The major change that is done is the use of the
>> >    gif(4) device to get the routing correct. Note that traffic is *not*
>> >    transported through the gif(4) tunnel! Instead the IPsec code in the
>> >    kernel grabs the packets according to the specified policy and wraps
>> >    them with the correct IP addresses for the IPsec tunnel.
>> 
>> Oops. I think I wrote this. :-)
>> 
>> >Tunnel traffic coming in on the external interface (fxp1) all looks
>> >like "proto ah" to IPfilter.  It looks like I cannot access the TCP,
>> >UDP or ICP payload at this point, which makes sense to me.
>> >
>> >Does this mean that I can only filter TCP, UDP, ICMP traffic coming out of
>> >the tunnel when it leaves the firewall thru the internal interface (fxp0)?
>> >
>> >So all listening sockets inside the firewall are completely open to
>> >traffice coming from the tunnel?
>> 
>> Actually you can (and want to!) filter for AH (or, if you're using
>> tunnel mode, ESP) protocols and drop any TCP, UDP and ICMP traffic.
>> Dropping ICMP completely is probably not wise - at least you want to
>> allow ICMP from the peers you are talking AH (or ESP) to. Further,
>> allowing a tcp/telnet resp. tcp/ssh to and from the remote site would
>> probably be reasonable.
>
>I know that I can filter on AH or ESP protocols but my issue is that
>every daemon on the firewall (by default, sometimes tunable) listens
>on every available interface, including the gif0 interface.
>
>So from the inside LAN at one location (behind firewall1) one can connect
>to e.g. sendmail running on firewall2 at the other location.  How can I
>(on firewall2) block incoming connections coming in thru the tunnel to a
>particular TCP or UDP port of firewall2?

For sendmail (and actually most other daemons, which is very important
if you run jails on your machine) you can specify which interface to
bind to.

Secondly you have the option to play with the IP addresses of the gif
interfaces at either side. As I wrote, the interface is not actually
used, it's more a placeholder to get routing straight. Hence the remote
address of the interface (not the local address!) is irrelevant, as long
as you have a route at either side pointing to the remote side via this
remote route. By using an address that is not reachable from the other
side you can effectively disable access to gif from remote.

BTW, you can achieve the same effect without gif: You need to set up
a static arp entry using the MAC address of your default gateway with
some arbirary address. Then set up a route to the remote side via this
address, and again all packets matching the policy will be taken by
IPsec.

>> >Or am I wrong here and is there a way to completely screen all tunnel
>> >traffic after the IPsec encapsulation is peeled off?
>> 
>> AFAIK not. I'd say this wouldn't be very sensible anyway. By setting up
>> a security association with the peer you are basically trusting him.
>
>So you mean that if one site gets compromised it's acceptable that the
>other sites get compromised as well?

IPsec's paradigm is that you either trust the remote side (according to
the specified policy) or you don't. There is conceptually no such thing
as a "maybe trust".

>> You can still do filtering on the inside interface of course.
>
>Except for traffic terminating at the firewall.

Correct, but this is a problem of ipfilter. Commercial IPsec gateways
(say Cisco routers running IPsec) will do fine. In fact they can even
filter traffic before encryption and after decryption on the external
interface.

Helge

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207080603.IAA22096>