[Swan] Questions about XAUTH connections

[Nels Lindquist]

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

Rise of the zombie thread!

I'm replying to this for the edification of anyone searching for this
later.

On 2014/08/27 10:21 AM, Nels Lindquist wrote:
> In experimenting with XAUTH connections as an alternative to L2TP, 
> I've run into a couple of things.
> 
> 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.
> 
> I verified my firewall rules and the client packets are being
> passed to the internal interface, but a tcpdump shows only repeated
> arp requests from the target IP asking for the location of the
> client, with no answers provided.  As the target can't find the
> client's location, no response traffic is forthcoming.  I feel that
> I've missed a simple option somewhere...

And that turns out to be the case.

Adding 'leftupdown="ipsec _updown --route yes"' to the connection
definition creates a host route for the connected peer, and this seems
to be working the way I hoped. Mostly. Will be starting a new thread
to discuss IP address pool peer allocation.

> 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.

This issue was actually resolved by a setting in the Shrew Soft
client; on the "Policy" tab, checking the "Maintain Persistent
Security Associations" box brings up the tunnel immediately rather
than on-demand from the Shrew Soft client side.

> 2.  Multinet - I'd prefer not to use leftsubnet=0.0.0.0/0 as I'd
> like the local default routes, etc. to remain on the clients.
> However it would be nice to provide access in some instances to
> multiple private networks behind the endpoint.  I tried replacing
> leftsubnet= with leftsubnets= and variants of { 192.168.0.0/24
> 172.16.0.0/24 } or "192.168.0.0/24, 172.16.0.0/24" as per the
> manpages/multinet samples I could find, but in either instance when
> I attempt to replace the connection I receive:

I've come up with a workaround for this, though there may still be a
better way.  In the Shrew Soft client, on the "Policy" tab uncheck the
"Obtain Topology Automatically or Tunnel All" checkbox.  Then populate
the "Remote Network Resource" table with the desired remote subnets.
As long as "leftsubnet=0.0.0.0/0" is present in the libreswan
definition, traffic will come through the tunnel according to the
Shrew Soft client configuration.  Restrictions at the libreswan end
are still possible with standard routing/firewall configurations.

Nels Lindquist
- ----
<nlindq at maei.ca>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAljBic4ACgkQh6z5POoOLgQ+UQCfYRaoppNVV5dqCuRTkGzA5UqA
NJ8AnRPBva2eITMlDryvTWV7PpoMSiE+
=EuVH
-----END PGP SIGNATURE-----