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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
