[Swan] Traffic _stops_ routing down tunnel

Paul Wouters paul at nohats.ca
Fri Mar 20 05:30:25 EET 2015


On Fri, 20 Mar 2015, Paul Moore wrote:

> 
> This is my first post to this list and I've been trying to figure out this problem for a few weeks
> without asking for help because I thought I must be doing something stupid.

to everyone: please never feel your question is too stupid. If something
is unclear after a google search, it is our problem in the
documentation. Please feel free to ask!

> me to say "me too". Just like Dave, please also forgive me if I'm doing something wrong or breaking
> mailing list etiquette.

The only etiquette is to treat others as you like to be treated
yourself.

> The basic problem is that a ping sent from the machine that initiated the tunnel (we'll call this the
> ipsec initiatiator) and to the machine at the other end (we'll call this the ipsec responder) does not
> work until a ping first comes from the ipsec responder back to the ipsec initiator. At that point, ping
> responds only if the tunnel has had traffic pass through it in the last 30 seconds. Also, while the ping
> from the ipsec initiator to the ipsec responder does not work, the ipsec initiatiator cannot even ping
> itself.

That's very odd. Did you observe if any of these pings were encrypted or
leaked in plaintext?

> # ==== Output of mdserver command: "cat /etc/ipsec.d/*conf"
> conn amazoncore
>         type=tunnel
>         authby=secret
>         auto=start
>         ike=aes256-sha1;modp1536,3des-md5;modp1024
>         forceencaps=yes
>         left=%defaultroute
>         leftid=10.1.2.2
>         leftsubnet=10.1.2.0/24
>         right=54.66.129.223
>         rightid=54.66.129.223
>         rightsourceip=10.1.0.1
>         rightsubnet=10.1.0.0/16

Does the server have one interface in the 10.1.2.0/24 network? If so,
can you add leftsourceip=10.1.2.x to that? (where 10.1.2.x is the
IP the server has in the 10.1.2.0/24 network?)

> conn forestlake
>         type=tunnel
>         authby=secret
>         auto=add
>         ike=aes256-sha1;modp1536,3des-md5;modp1024
>         forceencaps=yes
>         left=%defaultroute
>         leftid=54.66.129.223
>         leftsourceip=10.1.0.1
>         leftsubnet=10.1.0.0/16
>         right=%any
>         rightid=10.1.2.2
>         rightsubnet=10.1.2.0/24

(note normally we don't flip "left" and "right" on both ends of a
  connection. That is why we call it left/right and not source/dest :)

Also just to verify, I assume 10.1.0.1 is actually configured on the
amazon machine running libreswan, eg as alias on loopback or on an ethX device?
And not on another amazon located machine near the libreswan box?

to better understand what is happening, we would need to see the log
files produced by pluto. Running "ipsec barf" while libreswan is
running should give us the system config and the log files, so if you
can post that to a pastebin and give us the link, we could look into
this in more detail.

Paul


More information about the Swan mailing list