[Swan] Questions about XAUTH connections

Nels Lindquist nlindq at maei.ca
Fri Oct 24 23:51:48 EEST 2014


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

Hi, again.

On 9/9/2014 2:21 PM, Nels Lindquist wrote:
> 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?

This behaviour also hasn't changed with 3.11.


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

iEYEARECAAYFAlRKu+EACgkQh6z5POoOLgRk+QCgnOidebixT3wsGhYL5DyQE+8O
QmYAn2mxhmRBsM3dD7wRX3rncOWh0PHt
=9d7A
-----END PGP SIGNATURE-----


More information about the Swan mailing list