[Openswan Users] Routing problem with NETKEY

[Jani Joki]

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.

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
iptables -A INPUT -p 50 -j ACCEPT
iptables -A INPUT -p 51 -j ACCEPT
iptables -A INPUT -p 4 -j ACCEPT
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, 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? 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.

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