# Possible routing problem with IPsec

## Cygon

Hi!

I'm trying to connect my home server (Gentoo 2.6.34, ISP with dynamic IP) to an IPsec VPN using OpenSwan. The IPsec connection is established flawlessly, but I can't get any pings or other packets through to the other side (but the other side can ping me!)

Let's see if I can draw a topology diagram without proportional fonts messing it up:

```
                  +--------------+                               +-----------------+

192.168.124.0/24  |  Gentoo Box  |            Internet           |  LANCOM Router  |  192.168.248.0/24

192.168.124.1 --- | eth0    ppp0 | --- (dynamic) ... a.b.c.d --- | ext         int | --- 192.168.248.1

                  +--------------+                               +-----------------+
```

OpenSwan adds a route for 192.168.248.0/24:

```
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

217.0.118.61    *               255.255.255.255 UH    0      0        0 ppp0

192.168.248.0   *               255.255.255.0   U     0      0        0 ppp0

192.168.124.0   *               255.255.255.0   U     0      0        0 eth0

loopback        *               255.0.0.0       U     0      0        0 lo

default         217.0.118.61    0.0.0.0         UG    0      0        0 ppp0
```

I tried to capture IPsec traffic with tcpdump, but all I get are 6 packets when the connection is established. No other packets are generated (I tried pinging and accessing a web server on the other end): 

```
# tcpdump -i ppp0 -n -p udp port 500 or udp port 4500 or ah or esp

20:38:04.234719 IP 91.34.62.24.1 > a.b.c.d.500: [|isakmp]

20:38:04.408302 IP a.b.c.d.500 > 91.34.62.24.1: [|isakmp]

20:38:04.411897 IP 91.34.62.24.1 > a.b.c.d.500: [|isakmp]

20:38:04.415891 IP 91.34.62.24.1 > a.b.c.d.500: [|isakmp]

20:38:04.499685 IP a.b.c.d.500 > 91.34.62.24.1: [|isakmp]

20:38:04.525755 IP 91.34.62.24.1 > a.b.c.d.500: [|isakmp]
```

A tracepath to the other end shows the packets being sent to my ISP (217.0.118.61 is my P-t-P IP on ppp0). I think this is wrong:

```
 1:  91.34.62.24                                          0.316ms pmtu 1492

 1:  217.0.118.61                                         54.614ms asymm  2

 1:  217.0.118.61                                         51.423ms asymm  2
```

What could be the reason my packets take this route?

If you need more data (ipsec.conf, iptables rules or whatever), just ask  :Smile: 

----------

## salahx

If you're trying to connect 2 networks via ipsec tunnel mode, you may want to check out this thread:  (though this was using ipsec-tools/racoon), but the routing stuff should be good.

If you're trying to connect a single host to another network, then I need some details on the ipsec.conf config - whether you are trying to do this via tunnel,transport or IPsec+L2TP+PPP.

----------

## Cygon

I'm attempting the former, connecting 2 networks via ipsec tunnel mode. I thought it best to establish two-way communication between both VPN endpoints before taking on routing between both networks.

I'm trying to follow the setup in the link you provided, but I don't quite succeed in that (following the instructions, that is  :Razz: ). As far as I understand, the user there has two networks: 192.168.1.0/24 and 192.168.2.0/24 he is trying to connect via an IPsec tunnel. You recommended to add a route to 192.168.2.0/24 using 10.0.11.20 as gateway, which I think is intended to tell the sender to send packets destined for the network on the other end of the tunnel through the tunnel. So in my case, I'd add a route "ip route add 192.168.248.0/24 via 192.168.248.1" (does my tunnel get a virtual IP? I don't see anything like that and I was happy not having to mess with setkey spdadd in OpenSwan, so I'll just put 192.168.248.1 as the gateway...?).

My tunnel is configured like this (I've done quite a bit of experimentation with leftnexthop/rightnexthop/leftsourceip/rightsourceip, but this didn't seem to have any effect):

```
config setup

        nat_traversal=no

include /etc/ipsec/ipsec.d/examples/no_oe.conf

conn nwsi

        left=%defaultroute

        leftid=@my_id

        leftsubnet=192.168.124.0/24

        right=a.b.c.d

        rightid=@their_id

        rightsubnet=192.168.248.0/24

        rightnexthop=%direct
```

That sets up a connection that OpenSwan logs as:

```
000 "nwsi": 192.168.124.0/24===91.34.62.24[@my_id]...a.b.c.d[@their_id]===192.168.248.0/24; erouted; eroute owner: #12
```

As far as I understand it, if I send a packet to 192.168.248.1, the route set up by OpenSwan will ensure the packet is sent via ppp0. OpenSwan filters ppp0 and *should* prevent the packet from being sent to my ISP, instead encapsulating in an IPsec packet, sending it to the other end of the IPsec tunnel instead. So my tunnel doesn't require a separate subnet, the ipsec filter module (or whatever) should get the 192.168.248.1-targeting packet across to a.b.c.d where it will be routed into the remote network.

But it seems the ipsec filter module doesn't "pick up" the packet, instead it's sent out to my ISP as-is, where it will be discarded because the ISP's router is doubtlessly configured to not route private network IPs anywhere.

That at least is my theory and, if correct, leaves the question why the OpenSwan filter module doesn't capture the packets  :Smile: 

----------

## salahx

Ok so here's the situation then: Therehave 2 hosts. Host 1 has an external IP 217.0.118.61, and an internal IP of  192.168.124.1, with a /24 behind it. Host 2 has an extrnal IP of a.b.c.d and an internal IP of  192.168.248.1, with a /24 behind it.

The ipsec.conf looks sound, although I don;t think you need the rightnexthop.

It sounds like the IKE negotiation is succesful. Make sure ip forwarding is enabled, if its not already

```

echo -n 1 > /proc/sys/net/ipv4/ip_forward

```

On window 1:

```
tcpdump -I ppp0 ip proto 50 or 51
```

On window 2:

```
ping -I eth1
```

That not a typo. We want to ping on eth1 (assuming that interface has the 192.168.124.1), but sniff on ppp0. The packets will be transparently passed over the tunnel. You may not get a reply if the routing rules aren't setup properly, but that's OK, at least the outgoing packets should traverse the tunnel. If you see something appear on the tcpdump window, that's good, you have the tunnel establed.

Then you just need to set the routing rules (if traffic though ppp0 goes to the default route, you may not need this. Openswan may create it for you as well. In the previous experiment, both external ends of tunnel where on the same subnet. However in this case they are on different subnets, so I'm not sure exactly what rules, if any, may be needed)

You may need to disable reverse path filtering on ppp0. If you not sure, do

```
echo -n 1 >/proc/sys/net/ipv4/conf/tap0/log_martians
```

If, while running tests, you see message on the syslog about martians, you need to disable reverse path filtering

```
echo -n 2 >/proc/sys/net/ipv4/conf/ppp0/rp_filter
```

You can disable martian logging after confirming if its needed or not.

Note that when doing trace/ping tests, you need to specify the source IP to bind to (this is true for all applications: most bind to the interface with the default gateway, which isn't what you want: You want it to being 

So for traceroute test, you need:

```
traceroute -s 192.168.124.1 192.168.248.1
```

And you see the packet go to the other side You won't see any mention of 217.0.118.61.

Of course, the other side needs a similar setup.

----------

## Cygon

Yay! Pinging 192.168.248.1 on eth0 (that's my interface for 192.168.124.1) does indeed work and I'm seeing ESP packets flowing in tcpdump.

So OpenSwan picked my 192.168.124.1 interface (probably based on the leftsubnet parameter) but at the same time added an unworkable route for ppp0.

Thank you very, very much for your time. I'll try to go it from here  :Smile: 

----------

