Hi,
I'm not sure this is the right list for this type of question... as
IPSec isn't exactly routing. If someone can point me to a dedicated
IPSec list (for the 2.6 implementation) i'd be very grateful :)
Onto the actual problem...
I'm going to be using IPSec to secure a wireless access point. So far,
in my experimentation, i have the tunnel from laptop--AP-->linux_router
and back working fine, all nicely encrypted when both ends are set
up properly. The SPDs look like this on Linux router:
spdadd 192.168.0.0/24 192.168.16.2/32 any -P out ipsec
esp/tunnel/192.168.2.254-192.168.16.2/require
ah/tunnel/192.168.2.254-192.168.16.2/require;
spdadd 192.168.16.2/32 192.168.0.0/24 any -P in ipsec
esp/tunnel/192.168.16.2-192.168.2.254/require
ah/tunnel/192.168.16.2-192.168.2.254/require;
192.168.0.0/24 is an internal subnet, on another interface of the
router. 192.168.16.2 is the laptop, and 192.168.2.254 is the wireless
AP facing interface.
As i said, works great.
If on laptop, i have no SPD/SA's defined at all, and i send a totally
unencrypted ping to something in 192.168.0.0/24, it should get dropped
at the wireless facing interface of the router, right? Because of the
'require' specification in the SPD.
However... tcpdump on the wireless interface of the laptop:
2004-11-15 22:58:52.358367 IP 192.168.16.2 > 192.168.0.1: icmp 64:
echo request seq 1
Nothing wrong with that. But, <gasp>, what is this?
2004-11-15 22:58:52.362269 IP 192.168.2.254 > 192.168.16.2:
AH(spi=0x00000200,seq=0x3): IP 192.168.2.254 > 192.168.16.2:
ESP(spi=0x00000201,seq=0x03) (ipip-proto-4)
It looks like a reply from 192.168.0.1, that has been (rightfully)
encrypted by the router on the other end of the tunnel. (and indeed,
a tcpdump on 192.168.0.1 confirms this)
But 192.168.0.1 should never have replied in the first place, because
it should never have received the echo-request packet.
Am i missing something that should make IPSec drop the packet if
the require SPD isn't met? All the docs seem to suggest the above
(along with the proper SAs) is enough to stop unencrypted traffic
traversing the router's wireless facing interface.
Google, though not providing me with much, has told me that using
Netfilter here isn't the solution, and that the IPSec module should
handle the dropping of such packets itself if told to do so.
Umm... any ideas? :)
Thanks,
- Daniel