[Openswan Users] Routing problem with NETKEY

[Andy Gay]

On Fri, 2006-08-04 at 15:20 +0300, Jani Joki wrote:
> Quoting Andy Gay (andy at andynet.net):
> > On Thu, 2006-08-03 at 14:26 +0300, Jani Joki wrote:
> > > Apologies if this subject has been discussed before, but I spent a few
> > > days going through the archives, and though I found similar problems,
> > > I could not find exactly the same as mine, nor did any of the proposed
> > > solutions help me.
> > > 
> > > My setup is a simple network to network tunnel, from a openswan/netkey
> > > linux to a linksys rv042,
> > 
> > Which linux and Openswan versions?
> 
> 2.6.16-1.2122_FC5
> Openswan IPsec 2.4.4
> 
> > > routing and are passed along unencrypted. Any packets sent from the right 
> > > network to the left network do arrive at the gateway machine, but
> > > after decryption they appear in the INPUT chain, not the FORWARD chain 
> > > and thus are not passed forward. (I checked this by MARKing the packets and 
> > > then adding match rules to both forward and input, and the input counter grew).
> > > 
> > Of course the INPUT counter will grow - the encrypted packet goes
> > through it. But FORWARD should grow as well.
> 
> Unfortunately they do not. Only the icmp packets appear in the forward
> chain (I did four pings):
> 
> Chain FORWARD (policy ACCEPT 1 packets, 224 bytes)
>  pkts bytes target     prot opt in     out     source               destination 
>     4   336 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0         MARK match 0x1
> 
> The match for the mark is the very first entry, so even if later entires
> would filter the packets to oblivion, they should still be counted here.
> 
> > What linux kernel are you running? Since 2.6.16 incoming ESP packets
> > show up first in the INPUT chain as ip-in-ip (protocol 4) packets. If
> > you have a DROP policy those packets won't get any further. You have to
> > add an explicit ACCEPT for protocol 4. (I'm told it's a bug :)
> 
> I tried adding this explicitly as well, eventhough my default policy
> is ACCEPT (I have the very last rule in every chain as DROP).

Well, setting the last rule to drop everything is equivalent to a drop
policy, isn't it?
Make your second-to-last rule a LOG, then you'll see what you're
dropping.

> 
> > > To make things really bizarre, any icmp traffic sent from the right
> > > network to the left network goes through the tunnel as it should. Same
> > > is true for the other direction. Only udp and tcp traffic (the only
> > > protocols I tried) fail to go through the tunnel as they should.
> > > 
> > That could be a firewall problem as well. You should try a controlled
> > test without any iptables rules. If that fixes it some well-placed LOG
> > rules can help pin down where it's going wrong.
> 
> I'll try this when I can set it up. However, I don't quite think
> this could be it - I can't imagine what firewall rule would cause
> packets that originate from the left network and are destined for
> right network to be forwarded along normally rather than being placed
> into the tunnel like they should. If I run tcpdump on the external
> interface, I can see these packets go out just like any normal traffic.
> 
> I did some tcpdumping, and I can
> 
>  - see the esp packets coming in from eth2
> 
> 19:43:46.402321 IP 27.127.49.158 > 22.236.122.253: ESP(spi=0x8b5ff54d,seq=0x76), length 468
> 
>  - I can see the decrypted packets appear in eth2, with the correct
>    origin and destination addresses
> 
> 19:43:46.402321 IP 10.10.1.1.netinfo-local > 22.236.122.1.syslog: SYSLOG daemon.notice, length: 409
> 
>    - Still, these never appear in the forward chain
>  - and thus, I don't see them in the internal interface
> 
> Except for icmp packets. They appear everywhere just like they should.

That's why I'd suspect your iptables rules. That's really the only place
where packets get treated differently depending on their type.

Get an ipsec barf as Paul asked, please. You can sanitize the addresses
if you're shy.

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