[Openswan Users] Routing problem with NETKEY

[Jani Joki]

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).

> > 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.


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