[Openswan Users] Routing problem with NETKEY
demi at futuremark.com
Mon Aug 7 06:35:03 EDT 2006
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
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": 18.104.22.168/24===22.214.171.124---126.96.36.199...188.8.131.52[184.108.40.206]===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
220.127.116.11 dev eth2 scope link
18.104.22.168/30 dev eth2 proto kernel scope link src 22.214.171.124
126.96.36.199/27 dev eth1 proto kernel scope link src 188.8.131.52
10.10.1.0/24 via 184.108.40.206 dev eth2
220.127.116.11/24 dev eth0 proto kernel scope link src 18.104.22.168
169.254.0.0/16 dev eth2 scope link
default via 22.214.171.124 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
More information about the Users