Skip to contentSkip to conversation

: Fix xfrm lookup after SNAT

RFC In review Patrick McHardy 3 participants 3 messages Feb 13, 2006 – Feb 15, 2006

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

RFC 1/1 : Fix xfrm lookup after SNAT

I finally got around to fixing the "ip_finish_output2: No header cache and no neighbour!" problem reported by Andi Kleen. Instead of rerouting the packet in POST_ROUTING, we reuse the original route for the xfrm_lookup. This introduces a small restriction (see changelog entry), but I think it should work.

Herbert, do you see any problems with this patch?

[NETFILTER]: Fix xfrm lookup after SNAT

To find out if a packet needs to be handled by IPsec after SNAT, packets are currently rerouted in POST_ROUTING and a new xfrm lookup is done. This breaks SNAT of non-unicast packets to non-local addresses because the packet is routed as incoming packet and no neighbour entry is bound to the dst_entry. In general, it seems to be a bad idea to replace the dst_entry after the packet was already sent to the output routine because its state might not match what's expected.

This patch changes the xfrm lookup in POST_ROUTING to re-use the original dst_entry without routing the packet again. This means no policy routing can be used for transport mode transforms (which keep the original route) when packets are SNATed to match the policy, but it looks like the best we can do for now.

---
commit 0ebf0a6fc360cf177712ed0f21f160e0ffea9f99
tree 5bef78d70573091e5055bf4e236d7d8a443d20df
parent b6d521bde1a8bcf7e3fcad139319a427c18d8012
author Patrick McHardy <[email protected]> Mon, 13 Feb 2006 18:20:04 +0100 committer Patrick McHardy <[email protected]> Mon, 13 Feb 2006 18:20:04 +0100

 include/linux/netfilter_ipv4.h         |    2 +-
 net/ipv4/netfilter.c                   |   41 ++++++++++++++++++++++++++++++++
 net/ipv4/netfilter/ip_nat_standalone.c |    6 ++---
 3 files changed, 45 insertions(+), 4 deletions(-)
include/linux/netfilter_ipv4.h +1 -1
index fdc4a95..43c09d7 100644
@@ -79,7 +79,7 @@ enum nf_ip_hook_priorities {
 
 #ifdef __KERNEL__
 extern int ip_route_me_harder(struct sk_buff **pskb);
-
+extern int ip_xfrm_me_harder(struct sk_buff **pskb);
 #endif /*__KERNEL__*/
 
 #endif /*__LINUX_IP_NETFILTER_H*/
net/ipv4/netfilter.c +41 -0

47 lines not on this page · raw message

net/ipv4/netfilter/ip_nat_standalone.c +3 -3
index 92c5499..7c3f7d3 100644
@@ -235,19 +235,19 @@ ip_nat_out(unsigned int hooknum,
 		return NF_ACCEPT;
 
 	ret = ip_nat_fn(hooknum, pskb, in, out, okfn);
+#ifdef CONFIG_XFRM
 	if (ret != NF_DROP && ret != NF_STOLEN
 	    && (ct = ip_conntrack_get(*pskb, &ctinfo)) != NULL) {
 		enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
 
 		if (ct->tuplehash[dir].tuple.src.ip !=
 		    ct->tuplehash[!dir].tuple.dst.ip
-#ifdef CONFIG_XFRM
 		    || ct->tuplehash[dir].tuple.src.u.all !=
 		       ct->tuplehash[!dir].tuple.dst.u.all
-#endif
 		    )
-			return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP;
+			return ip_xfrm_me_harder(pskb) == 0 ? ret : NF_DROP;
 	}
+#endif
 	return ret;
 }
 
#1 lore raw
Quoted 7 lines · Patrick McHardy

I finally got around to fixing the "ip_finish_output2: No header cache and no neighbour!" problem reported by Andi Kleen. Instead of rerouting the packet in POST_ROUTING, we reuse the original route for the xfrm_lookup. This introduces a small restriction (see changelog entry), but I think it should work.

Herbert, do you see any problems with this patch?

Looks perfect to me. I think the restriction makes sense since SNAT is done in post-routing so it's counter-intuitive to repeat the lookup anyway.

Quoted 1 line

Thanks,

Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
maintainer
#2 lore raw

From: Herbert Xu <[email protected]>
Date: Tue, 14 Feb 2006 12:49:24 +1100

Quoted 9 lines · Patrick McHardy
Quoted 7 lines

I finally got around to fixing the "ip_finish_output2: No header cache and no neighbour!" problem reported by Andi Kleen. Instead of rerouting the packet in POST_ROUTING, we reuse the original route for the xfrm_lookup. This introduces a small restriction (see changelog entry), but I think it should work.

Herbert, do you see any problems with this patch?

Quoted 7 lines

Looks perfect to me. I think the restriction makes sense since SNAT is done in post-routing so it's counter-intuitive to repeat the lookup anyway.

Quoted 1 line

Looks good to me too, applied to net-2.6

Thanks a lot.