[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