-----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@mail ipsec.d]# ip xfrm st [root@mail ipsec.d]# ip xfrm sh > > Nothing. > > So I ran: > > [root@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 <[email protected]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iEYEARECAAYFAlRKu+EACgkQh6z5POoOLgRk+QCgnOidebixT3wsGhYL5DyQE+8O QmYAn2mxhmRBsM3dD7wRX3rncOWh0PHt =9d7A -----END PGP SIGNATURE----- _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
