[Swan] Questions about XAUTH connections

Paul Wouters paul at nohats.ca
Wed Aug 27 19:28:55 EEST 2014


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.

Check /etc/sysctl.conf ?

Possibly, your VPN needs to do SNAT/MASQ if you're planning to go out on
the internet with this. But exclude whatever local RFC1918 you use

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

Your network should be routing the addresspool IP's to your VPN server.

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

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

Support for multiple networks on the server side without using 0.0.0.0/0
is close to being supported but needs a little work still.

Paul


More information about the Swan mailing list