Date: Tue, 21 Jan 2003 15:08:38 +0200 From: Pekka Nikander <pekka.nikander@nomadiclab.com> To: Mike Durian <durian@boogie.com> Cc: freebsd-net@freebsd.org Subject: Re: Question about IPsec and double ipfilter processing Message-ID: <3E2D4656.6000805@nomadiclab.com> In-Reply-To: <200301201731.49942.durian@boogie.com> References: <200301201731.49942.durian@boogie.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Durian wrote:
> I was looking through the FreeBSD mailing list archives trying to figure
> out why ipfilter is filtering on both encapsulated ESP packets and the
> decrypted packets (NetBSD says it should only filter on the line packets),
> when I saw a relevent posting. It looks like other people are frustrated by
> this double processing too.
>
> In a message Pekka Nikander says:
>
> From the security point of view this does not matter so much,
> since the IPsec code is taking care of the protection and
> dropping those packets.
>
> Can you clarify on this. In order to allow a peer network, 192.168.2.0/24,
> to connect to my network via a VPN, I need to pass ESP (fine) and
> then also 192.168.2.0/24 packets (I'm not so happy about this). Does
> your statement above imply the IPsec code will somehow filter non-ESP
> encapsulated packets from 192.168.2.0/24 thus protecting me from spoof
> attacks even though the firewall would appear to allow it?
Exactly, if you have the SPD settings right.
If you have an SPD setting like
192.168.2.0/24 0.0.0.0/0 any
in ipsec
esp/tunnel/XXX.XXX.XXX.XXX-YYY.YYY.YYY.YYY/require;
then the IPsec code *requires* than any received packet
that has a source address within 192.168.2.0/24 was
indeed protected by the specified tunnel, and if it wasn't,
it drops the packet.
From netinet/ip_input.c:
#ifdef IPSEC
/*
* enforce IPsec policy checking if we are seeing last header.
* note that we do not visit this with protocols with pcb layer
* code - like udp/tcp/raw ip.
*/
if ((inetsw[ip_protox[ip->ip_p]].pr_flags & PR_LASTHDR) != 0 &&
ipsec4_in_reject(m, NULL)) {
ipsecstat.in_polvio++;
goto bad;
}
#endif
ipsec4_in_reject then calls ipsec_in_reject with the corresponding
policy, and ipsec_in_reject returns non-zero if the packet was not
protected by ESP.
--Pekka
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E2D4656.6000805>