IPSec: tunnel established, "no" traffic going through

[Criena]

Hi,

I have a weird problem with IPSec. I searched the Internet for days now, tried different things, but all without the much desired success. I hope somebody here is able to give me a clue or little hint on it.

Currently I'm using a Raspberry Pi (RPi) to terminate an IPSec tunnel to another location. The system is running on "Raspbian" (aka Debian Wheezy). I intend to replace the system by a newly purchased Beaglebone Black (BBB). I installed Arch Linux and configured the system identical to the RPi (setkey and racoon). The tunnel is being established, no errors whatsoever, both sides say that the tunnel is up, but no traffic is going through (i.e. I see packets crossing the tunnel, but they seem to just disappear to nowhere).
I grazed the Internet for days now and haven't found any clue why this is the case. I'm close to giving up as I have no idea anymore what to do.

Based on research on the Internet I tried the following things (obviously without any luck):

• Added a route manually (even though on the RPi it works without setting any routes)
• Changed the encryption algorithm (from AES to 3DES)
• Changed the hash algorithm (from SHA1 to MD5)
• Turned off NAT traversal (I prefer having the tunnel running via UDP though)

If I ping a machine on "the other side" and sniff what is happening within the tunnel on both, the RPi and the BBB, I see the following:

RPi: ESP packets are going to "the other side" and packets are coming back. Ping and any other communication is working properly.
BBB: ESP packets are going to "the other side", but no packets are coming back.

If I start a ping from "the other side" to my side, the BBB shows ESP packets coming in, but somehow they are not processed. No answers are received back, nor are any reply packets sent. To me it looked like some ruleset might block everything. I installed iptables and ... no rules defined, default policy is "ACCEPT".

This is so unsatisfying! And I have no clue what the problem might be. I really hope someone can shed some light into this behaviour.

Thanks
Criena

[wiley]

Sorry for the necropost, but I have to +1 this. I'm guessing there's something odd about the ALARM kernel configs that's making this happen, but I have no idea.

I've been trying to set up my Dreamplug (ARMv5/Kirkwood) to function as an IPsec/L2TP VPN gateway for remote clients. I've gotten IPsec to work flawlessly using both OpenSwan and IPsec-tools/raccoon, but in both cases, no traffic seems to flow over the IPsec tunnel and xl2tpd never receives a request after IPsec is negotiated. I have IPTables set to allow all IPsec traffic, and it has never logged a packet.

So far, I haven't been able to find any recent documentation on IPsec in the Linux kernel - everything seems to date back to 2.4 or 2.6. It may be worth comparing the ALARM configs to Arch mainline or Debian.

[WarheadsSE]

Uhm.

Anyways, have you turned on the necessary forwarding at the driver level? It is not simply iptables.

[wiley]

Sorry, I should have specified a bit more about my setup.

My plug is already functioning as a NAT router. Forwarding is enabled, and that entire setup works.

As I mentioned, IPsec negotiation succeeds under both OpenSwan and IPsec-tools/raccoon, but xl2tpd never seems to receive a packet from the client, and the client eventually times out and gives up. Here are my relevant IPTables rules:

-A INPUT -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -m policy --dir in --pol ipsec -j ACCEPT

During testing of my setup, I've gone as far as allowing all UDP traffic on port 1701 and allowing all traffic with my test host's source address.

[chuckatpdo]

(If this topic is still open)

You say you are already using this as a NAT device. Are your NAT rules set to exclude the traffic you wish to send through the tunnel?