[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