# IPSec tunneling

## setagllib

I'm having really bad luck trying to get IPSec to tunnel. It does point-to-point fine, and I can ping any of the gateway's local IPs just fine, but tcpdump indicates that no packets ever leave another interface if I try to ping/etc another subnet.

For instance:

root@thor mnt # ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.34 ms

--- 192.168.1.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 2.343/2.343/2.343/0.000 ms

root@thor mnt # ping 192.168.1.3

PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.

--- 192.168.1.3 ping statistics ---

1 packets transmitted, 0 received, 100% packet loss, time 0ms

This is a real pain. Here is my ipsec.conf (keys changed for my own security of course - but those are not the problem):

#!/usr/bin/setkey -

flush;

spdflush;

add 192.168.0.1 192.168.0.142 esp 691 -m tunnel -E rijndael-cbc <crypt key> -A hmac-md5 <auth key>;

add 192.168.0.142 192.168.0.1 esp 693 -m tunnel -E rijndael-cbc <another crypt key> -A hmac-md5 <another auth key>;

spdadd 192.168.0.142 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.0.142-192.168.0.1/require;

spdadd 0.0.0.0/0 192.168.0.142 any -P in ipsec esp/tunnel/192.168.0.1-192.168.0.142/require;

I've also tried using a /24 subnet instead of the specific .142, as in some examples, but this made no difference.

Does anyone have any idea what could be wrong? I'm almost thinking of asking on the Gentoo forums but am not optimistic.

ipsec tools are 0.3.3, kernel is 2.6.10 mainline.

The attempt is to harden my wireless LAN (at least for my Linux laptop) beyond what WEP can provide, but include the internet in this; and not just traffic from the gateway to the client (which is usually just ssh and NFS).

Summary: tunneled ESP packets get unwrapped but never released into the wild.

And yes, the gateway has the in/out switched around: this is also not the problem. I have also tried everything possible with iptables on the gateway, including just allowing everything, but this also does not help. It doesn't matter if the interface to be sent to has NAT going for it or not: it even fails for LAN.

----------

## adaptr

What do the routing tables look like on the endpoints ?

Being able to reach a P-t-P link but not anything beyond it is typically a routing problem.

----------

## setagllib

```
Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth1
```

I also doubt this is the problem because it works fine if ESP encapsulation is not requested for a certain subnet, or if the rules are cleared entirely. The gateway just doesn't want to send off packets it unwrapped from ESP.

----------

## setagllib

Should I give up, then? Real shame.

----------

## adaptr

I don't see anything about a VPN tunnel in that routing table...

----------

## setagllib

Is it meant to be in there? I had to disable the ipsec rules in order to actually post. But even after setkey'ing the conf file above, nothing new appears. Nothing in any tutorial I found mentioned doing anything more than what I already did (which is what makes this so frustratingly confusing)

So what's the deal? What should appear?

----------

## think4urs11

Hi,

maybe an working example helps

i have an VPN connection to my office and use 'office-internal' addresses at home (10.x.y.0/25).

My VPN-gateway is a Gentoo box with ppp dialup connection to internet (connected to eth1).

Besides the annoying bug that the connection gets killed every 4 hours (timeout on VPN GW office) it works flawlessly.

```
/etc/racoon/racoon.conf

remote "IP VPN gateway office"

{

        exchange_mode aggressive;

        my_identifier user_fqdn "myuser";

        proposal

        {

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group 2;

        }

}

sainfo address 10.x.y.0/25 any address 10.0.0.0/8 any

{

        pfs_group 2;

        lifetime time 1 hour;

        encryption_algorithm rijndael;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

}

sainfo address 10.0.0.0/8 any address 10.x.y.0/25 any

{

        pfs_group 2;

        lifetime time 1 hour;

        encryption_algorithm rijndael;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

}
```

```
/etc/ipsec.conf         

#!/usr/sbin/setkey -f

flush;

spdflush;

spdadd 10.x.y.0/25 10.x.y.0/25 any -P out none;

spdadd 10.x.y.0/25 10.x.y.0/25 any -P in  none;

spdadd 10.x.y.0/25 10.0.0.0/8 any -P out ipsec esp/tunnel/"ppp0-IP"-"IP VPN gateway office"/require;

spdadd 10.0.0.0/8 10.x.y.0/25 any -P in  ipsec esp/tunnel/"IP VPN gateway office"-"ppp0-IP"/require;
```

```
netstat -rn

Kernel IP Routentabelle

Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface

217.a.b.c    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0

10.x.y.0     0.0.0.0         255.255.255.192 U         0 0          0 eth0

10.0.0.0        0.0.0.0         255.0.0.0       U         0 0          0 eth0

127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo

0.0.0.0         217.a.b.c    0.0.0.0         UG        0 0          0 ppp0
```

HTH

T.

----------

## ronaldmoes

Hi,

You should upgrade to ipsec-tools 5.0rc1 or higher, it fixes the creating of ipsec forward policy's that are needed on kernels >= 2.6.9. Unfortunately this version is not yet in portage. As a workaround you can also add this (notice the -P fwd):

```
spdadd 0.0.0.0/0 192.168.0.142 any -P fwd ipsec esp/tunnel/192.168.0.1-192.168.0.142/require;
```

to your ipsec.conf and that should work too.

I had the exact same problem you're having and this fixed it for me. The reason you don't see routes being added is that NETKEY (the 2.6 ipsec stack) doesn't use ipsec devices. The packets are picked up by the ipsec stack and encrypted/decrypted if they match one of the policies set by setkey, there's no routing involved. Good luck.

----------

## ronaldmoes

Oh, one more thing: I just noticed you use 0.0.0.0/0. I don't think that will work because that means all traffic, including ISAKMP traffic will get encrypted which is not what you want. Is it possible to specify the subnet on the remote end instead of using 0.0.0.0/0?

----------

## setagllib

No, because I really do want the whole net. I have seen an example for FreeBSD that used 0.0.0.0/0 with no complaints. There's not really a way to say "Everything but" in a single subnet and I'd hate to start making exceptions.

I'll try what you suggested, it sounds promising. Thanks. I'd like to see Linux being on par with the BSDs in IPSEC, but so far it's a letdown.

Should that go in the client or gateway's ipsec.conf? I've tried lots of combinations and mutations but my problem isn't dissolving. I am going to try getting the new tools instead.

----------

## ronaldmoes

Let me draw up what you're trying to do here:

Client Machine ===== Gateway ----- Internet

Right? And you're trying to encrypt the traffic between Client Machine and gateway, even if that traffic will be routed on to the internet,right? If that's what you want then you should not be using tunnel mode, but transport mode. This way you secure the link between your two machines so no traffic flowing between them will ever be in cleartext no matter what it's ultimate destination is. By using tunnel mode you're sending out encrypted traffic onto the internet and that's obviously not what you want.

  Btw, if you want BSD-like ipsec I suggest you look at openswan.

----------

## setagllib

I had transport mode working, but it encrypted traffic ONLY destined for the gateway, not beyond. This is virtually useless since most of the traffic to my gateway is SSH anyway (besides some insensitive NFS serving of my portage tree).

I could give that another shot of course, maybe tcpdump lied about which packets were being encrypted.

Update: No, still only to that exact IP. Even pinging local interfaces on the gateway from the client does not merit encryption.

That whole design is way overcomplicated: transport mode should include the packets that will be forwarded later. It's not hard for the kernel to look in its routing table and see if something should be encrypted or not.

I thought OpenSwan was the opposite of BSD ipsec, since ipsec-tools is essentially the same as what the BSDs have (well, setkey works the same anyway).

----------

## ronaldmoes

Hmm, ok, so apparently I was wrong, tunnel mode is needed to get what you want. I've tried both ipsec-tools and openswan and must say that openswan is a lot easier to set up. Also there you have the ability to have normal ipsecX-style interfaces and you can set routes to them etc.  And one other big advantage: SNAT actually works.

----------

