[Openswan Users] Routing problem with NETKEY

[Andy Gay]

On Mon, 2006-08-07 at 11:35 +0300, Jani Joki wrote:
> Quoting Andy Gay (andy at andynet.net):
> > > for the encapsulated packet. No real world  MTU is that low, is it :)
> > > MTU problems tend to show up as connections getting set up OK but later
> > > packets getting lost.
> > 
> > Of course there could be other big packets getting lost here, I'm sure
> > that's what you meant. But this packet certainly made it OK and shows up
> > decrypted, but we're told it's not being forwarded. Why could that be?
> > The decrypted packet looks OK. So we're looking at a routing or firewall
> > problem, aren't we. And if ICMP gets through OK, routing must be good.
> 
> First of all, thanks to everyone who has responded. I'll try to
> answer the various questions here rather than each email individually.
> 
> To check the possible MTU issue, I tried it with large icmp's to see
> if size matters,
> 
> talvi:/home/demi > ping -s 4096 10.10.1.1
> PING 10.10.1.1 (10.10.1.1) 4096(4124) bytes of data.
> 4104 bytes from 10.10.1.1: icmp_seq=1 ttl=126 time=296 ms
> 4104 bytes from 10.10.1.1: icmp_seq=2 ttl=126 time=297 ms
> 
> and it does not. Also note that my remote end is a linksys box, I'm
> not sure if I can even fiddle with the MTU in that end.
> 
> > So I'd really like to see those iptables rules...
> 
> I have a large amount (>200 rules for forward), but I hope these entries
> are enough:
> 
> This is the full INPUT chain. Note that the very first rule is the match
> against MARK. This is the counter that grows for all non-icmp traffic
> originating from the right network. Since the rule that sets
> the MARK is after this rule, I believe the only way for this first rule
> to match is that the decrypted packets appear here.

No. Different INPUT chain. You're setting the mark in the mangle table,
not the filter table. Which is correct, since that's the only table that
supports setting the mark. But you should set it in the PREROUTING
chain, not INPUT.

Packets go through mangle before they ever touch the filter table.

If you're doing complicated stuff with netfilter, you really need to
understand it first. I'd say a 200 rule forward chain qualifies as
complicated... :)
There's lots of good docs on the net - http://www.netfilter.org/ is a
good place to start. 

> 
> iptables -A INPUT -m mark --mark 1 -j ACCEPT
> iptables -A INPUT -i eth0 -j ACCEPT
> iptables -A INPUT -p udp --dport 500 -j ACCEPT
> iptables -t mangle -A INPUT --proto 50 -j MARK --set-mark 1

So change that INPUT to PREROUTING

> iptables -A INPUT -p 50 -j ACCEPT
> iptables -A INPUT -p 51 -j ACCEPT
> iptables -A INPUT -p 4 -j ACCEPT

Add a LOG rule here so you can see what's getting dropped. Didn't I
suggest that already?

> iptables -A INPUT -j DROP
> 
> This is the the very first rule in the FORWARD chain,
> 
> iptables -A FORWARD -m mark --mark 1 -j ACCEPT
> 
> This rule is only hit when I do icmp traffic. 
> 
> 
> I'd love to discover that my firewall rules are at fault,

Try a test with no firewall rules, see if that fixes it. I suggested
that before as well, IIRC. Ah well...

>  but I don't
> see I how I could craft a firewall rule that would cause traffic from
> left network to the right network be forwarded along the normal routing
> table and never enter the tunnel. Everything I see seems to point that
> the tunnel is created as a client-to-gateway, rather than gateway-to-gateway.
> However, in ipsec whack --status I see this,
> 
> 000 "futuremark-saratoga"[2]: 22.236.122.0/24===22.236.122.253---22.236.122.254...27.127.49.158[27.126.59.249]===10.10.1.0/24; erouted; eroute owner: #64
> 
> Does this not indicate at network-to-network setup? Is there any way to 
> see the netkey routing table?

There isn't a "netkey routing table". Netkey drives the security
association and policy databases. You can dump those using 'ip xfrm
state show' for the SADB and 'ip xfrm policy show' for the SPDB.

>  ip route just shows
> 
> [root at firewall ~]# ip route
> 22.236.122.254 dev eth2  scope link
> 22.236.122.252/30 dev eth2  proto kernel  scope link  src 22.236.122.253
> 22.236.122.32/27 dev eth1  proto kernel  scope link  src 22.236.122.33
> 10.10.1.0/24 via 22.236.122.254 dev eth2
> 22.236.122.0/24 dev eth0  proto kernel  scope link  src 22.236.122.252
> 169.254.0.0/16 dev eth2  scope link
> default via 22.236.122.254 dev eth2
> 
> the route to the 10.10.1.0/24 looks kinda odd, since it's forced to my
> defaultgw. But from this I can't tell if it is meant to go through the
> tunnel or not.

That route looks fine. Whether the packet enters the tunnel is a
function of the SPDB/SADB, not routing.

Having said all this, your setup involves overlapping subnets which is
not a common configuration. I've not tested any setup like that myself,
so I don't know if you need to do anything special. It's possible
netfilter is getting confused about whether packets belong in INPUT or
FORWARD.

You may want to try setting up a much simpler test network and getting
things working there first.

> 
> -- 
>         Jani Joki        Senior Technical Manager   Futuremark Corporation
> jani.joki at futuremark.com     +358 20 759 8264         www.futuremark.com
> 
> 
> 
>