Reinserted IPSEC packets and iptable rules

NinerFan · n00b Joined: 23 Jul 2003 Posts: 30 Location: California

I was having trouble with getting ipsec working after upgrading a system, and learned that once the packets are decrypted, they are re-evaluated. It is stated on the second to last checklist item from the ipsec-tools site http://ipsec-tools.sourceforge.net/checklist.html.

The problem I see now, is that once they are reprocessed, it is done in a way where the connection tracking no longer works. They appear as new packets I guess. And since the source IP's are ones that should normally be not allowed, I don't know how to tell if the packet is legitimate, or a spoof attempt.

I found a thread on the ipsec-tools mailing list located here http://sourceforge.net/mailarchive/message.php?msg_id=9538067 that talks about a policy patch to the kernel and netfilter, but the more I read it, I don't think it resolves the issue. It appears to just initially identify whether it is subject to ipsec.

When the packet is re-inserted for evaluation, is there any marker that I can check to make sure it is a valid and not a spoof attempt? I'd rather not just accept any packet on the forward chain that has that source net.

I know the answer is staring me in the face.

NinerFan · n00b Joined: 23 Jul 2003 Posts: 30 Location: California

I patched both the kernel and iptables and added the policy support, and as I suspected, it doesn't help. That is unless I'm not using it correctly.

I also forgot to mention that trying to filter the re-inserted packets via mac address doesn't work, since for whatever reason, they aren't there.

Adding a FORWARD rule to allow everything based on the remote lan (a commonly spoofed one btw) doesn't seem to me a very good solution. Is this really what people running vpn gateways on 2.6 are doing? Or have I hit some sort of conntrack bug, and the stuff that is supposed to be there indicating it is part of an established connection isn't there?