On Sat, Jun 07, 2003 at 01:15:40PM +0200, Lupe Christoph
wrote:> Hi!
>
> I'm trying to increase security on my FreeBSD 4.8 firewall/DSL
router/VPN
> router.
>
> My problem is with firewalling the VPN part. I'm using a tunnel to a
> RedHat 7.1 box running FreeS/WAN. This tunnel allows traffic from my
> internal net (172.17.0.0/24) to that box only:
>
> spdadd 172.17.0.0/24 $REDHAT/32 any -P out ipsec
esp/tunnel/$MYADDR-$REDHAT/unique;
> spdadd $REDHAT/32 172.17.0.0/24 any -P in ipsec
esp/tunnel/$REDHAT-$MYADDR/unique;
>
> What I want to do is prohibit traffic from $REDHAT to 172.17.0.7, the
> internal address of this FreeBSD box. I'm using IPFilter, so I inserted
> a rule like this:
>
> block in log quick from any to 172.17.0.7
>
> It is not attached to any interface, so it should supposedly work even
> for tunnelled traffic. Only it doesn't.
Not sure who told you that, but it won't affect tunneled traffic. Not
specifying an interface just means that it will be applied to all
interfaces.
[snip]
> Any hints how to resolve this are welcome. I don't think this is a
> general IPFilter problem, hence I'm asking on this mailing list rather
> than that for IPFilter.
>
> Thank you,
> Lupe Christoph
>
> PS: There was talk about the sequence IPFW/IPNat/IPFilter get invoked.
> It would be interesting to put the IPSec code in this picture. Are
> IPSec packets going through *any* of them? With/out GIF?
Here's what happens (approximately), the packets get fed to the
ip_input() routine. They pass through IPFilter then IPFW. Later they
find themselves in IPsec processing where the packets are taken out of
the tunnel. At this point, the packets are fed back into ip_input(),
BUT the reinjected packets skip all firewall processing on this
pass. With the IPSEC_FILTERGIF option set, the packets _will_ go
through the firewall, IPFilter then IPFW, after IPsec processing.
However, there may be an ugly hack to try here. I think I might try it
on one of my experimental setups at home. It may be possible to set up
some additional IPsec policies to block the traffic you want to stop.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org