[Swan] Questions about XAUTH connections

[Nels Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I can now reward Paul's hard work building 3.10 binaries with some
more... :-)  Have upgraded to 3.10 and re-tested.

On 8/29/2014 1:38 PM, Nels Lindquist wrote:
> On 8/27/2014 10:28 AM, Paul Wouters wrote:
>> On Wed, 27 Aug 2014, Nels Lindquist wrote:
> 
>>> 1.  Routing - With L2TP, the ppp[n] interface becomes active
>>> and routing is set up automatically, possibly by pppd or
>>> xl2tpd? When I bring up an IPSEC+XAUTH connection, the
>>> (Shrewsoft) client is correctly getting one of the IP addresses
>>> specified in rightaddresspool, the "leftsubnet" network is
>>> added to the local client routing table and the client is able
>>> to ping the internal private IP of the LibreSWAN endpoint.
>>> However, if I attempt to connect to anything beyond the
>>> endpoint, I don't get any response traffic from the other
>>> side.
> 
>> Your network should be routing the addresspool IP's to your VPN 
>> server.
> 
> I agree! :-) I'm used to the pluto updown script handling that, 
> though, both for site-to-site tunnels and L2TP roadwarrior
> tunnels.
> 
> I tried setting a couple of different routes manually but still
> didn't get any packets flowing, for eg:
> 
> "ip r a [active addresspool IP] dev [defaultroute interface] scope 
> link src [internal IP]"
> 
> ... but still no packets flowing.
> 
>>> I've also noticed that when the tunnel is first brought up, no 
>>> traffic to the client IP goes through until packets are first 
>>> received from the client.  eg, Bring up tunnel, try to ping 
>>> client from server; nothing.  Ping server from client;
>>> success. Ping client from server again, success.
> 
>> That might be a client feature? Do you see encrypted packets 
>> leaving the network when this happens?
> 
> I'll check that.

Okay, had a look and there are no packets leaving the server for that
IP, either encrypted or not.

I did notice some other things, though.  Immediately after the tunnel
came up, but before pinging from the client, I tried:

[root at mail ipsec.d]# ip xfrm st
[root at mail ipsec.d]# ip xfrm sh

Nothing.

So I ran:

[root at mail ipsec.d]# ip xfrm mo

And then initiated a ping from the client side:

src 216.194.67.132 dst 209.82.26.89
        proto esp spi 0xe50fbce9 reqid 16401 mode tunnel
        replay-window 32 flag 20
        auth hmac(md5) 0xf0eae4a6f8f6dac1943db3975ca33e2d
        enc cbc(aes)
0xeff6f88fc23473b01965c034af43a293fd71069f4f9060f7f2674e2b95ea431c
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
Updated src 209.82.26.89 dst 216.194.67.132
        proto esp spi 0x8be3ea33 reqid 16401 mode tunnel
        replay-window 32 flag 20
        auth hmac(md5) 0x41fca1cf00852885be6b142ec825b303
        enc cbc(aes)
0x077ffbb986ef7eb4da2fad9d9399baa7a12d4bcd609f808721b2f28bcc46160c
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
Updated src 192.168.90.111/32 dst 192.168.90.96/27
        dir in priority 2240 ptype main
        tmpl src 209.82.26.89 dst 216.194.67.132
                proto esp reqid 16401 mode tunnel
Updated src 192.168.90.111/32 dst 192.168.90.96/27
        dir fwd priority 2240 ptype main
        tmpl src 209.82.26.89 dst 216.194.67.132
                proto esp reqid 16401 mode tunnel
Updated src 192.168.90.96/27 dst 192.168.90.111/32
        dir out priority 2240 ptype main
        tmpl src 216.194.67.132 dst 209.82.26.89
                proto esp reqid 16401 mode tunnel
Async event  (0x10)  replay update
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8be3ea33
Async event  (0x10)  replay update
        src 216.194.67.132 dst 209.82.26.89  reqid 0x4011 protocol esp
 SPI 0xe50fbce9
Async event  (0x20)  timer expired
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8be3ea33
Async event  (0x20)  timer expired
        src 216.194.67.132 dst 209.82.26.89  reqid 0x4011 protocol esp
 SPI 0xe50fbce9
Async event  (0x20)  timer expired
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8be3ea33
Async event  (0x20)  timer expired
        src 216.194.67.132 dst 209.82.26.89  reqid 0x4011 protocol esp
 SPI 0xe50fbce9
Async event  (0x20)  timer expired
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8be3ea33
Async event  (0x20)  timer expired
        src 216.194.67.132 dst 209.82.26.89  reqid 0x4011 protocol esp
 SPI 0xe50fbce9
Async event  (0x20)  timer expired
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8be3ea33
Async event  (0x20)  timer expired
        src 209.82.26.89 dst 216.194.67.132  reqid 0x4011 protocol esp
 SPI 0x8b e3ea33

So it looks like the tunnel wasn't actually registered with the kernel
until traffic came in from the other end?  Could that be contributing
to my routing issues?


- -- 
Nels Lindquist
<nlindq at maei.ca>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)

iEYEARECAAYFAlQPYSUACgkQh6z5POoOLgRlxwCbBDbNr5PQBdtolKUKOZxcbMGY
fUAAnigcMIVanClPVYAgBheI7KGpcSvm
=ECiJ
-----END PGP SIGNATURE-----