[Swan] A Super-LAN

[Paul Wouters]

On Thu, 11 Jan 2018, Colony.three wrote:

> My goal is to have all machines commoned together on the VPN. (they are all trusted)  The LAN class C is 192.168.1.0/24 and it would
> be ideal to assign remote machines a -known- IP in this range.  This way I'll know where everyone is.  If this is not possible then
> I'd like to have a VPN-internal range such as 10.1.1.0/24, but again to have each peer be assigned a -known- IP, so I know where
> each is.

It's better to think of the LAN IPsec separate from the Remote Access IPsec.

> All connexions must be mutual, IOW peer A can scp files from peer B, and peer B can scp files from peer A.
> 
> To set up a commoned system like this I suspect I'd need to set up individual segments between each peer and the gateway, in a
> hub-and-spoke.  Maybe I'd need a connexion one way, and a second one the other way? 

You don't do hub-spoke, but Opportunistic IPsec, if you want all nodes
in a LAN to do IPsec. That way when adding nodes, you don't need to
reconfigure the existing nodes. Again, remote access is a different
kind of IPsec.

> - How does the ipsec.conf differ between left and right?  I read some examples where they are identical, and some where their roles
> are reversed.  When system A is the LAN gateway and system B is a remote laptop, in systemA's ipsec.conf it is the left and B is the
> right.  But on system B's ipsec.conf is it the left and system A the right?  If so, what other ipsec.conf differences are there?  I
> can't find anything in the docs even showing a right ipsec.conf.

As Nick said, "left" is arbitrary. It is the left side of the diagram on
your paper. If you turn it over, that left is right. on startup,
libreswan figured out if it is left or right based on the IP addresses
of the system. The exceptions are %any which implies that end is not
local, and %defaultroute, which implies it is local.

> - Is it possible to assign a -known- IP to peers?  I find in the man there is a  leftsourceip= but this seems to apply in only one
> direction, from left to right.  Is this the case?  Or is there another way to assign known IPs to peers?  And is there a way to
> record them in a hosts file in some way.

*sourceip is ONLY used to add routes or add IP's to interfaces. It does
not define the network range like leftsubnet/rightsubnet does.

For hosts within a LAN, you dont use *subnet and you don't use
*sourceip, since those are all host-to-host connections. For
Remote Access, you want the server side to be 0.0.0.0/0 or
your LAN/MASK. This is why I keep saying Remote Access and
LAN/mesh encryption are different things altogether.

I understand your need to want static IP's on the client. Currently
our adddresspool does not support that. And so you have to use
seperate conns per client, using clearly distinct client ID's (eg
rightid=@client1 rightid=@client2 on the server side. Then on the
client side define a local ip/32 as the leftsubnet. I'm not sure
your client (android, strongswan?) can do that.

The addresspool does assign the same IP to the same ID when possible,
so quick reconnects get the same IP. And on the server in the updown
script, you can add DNS updates other scripting for /etc/hosts files
that write down the newly assigned IP to the ID. If the ID matches
a subjectaltname on the cert, then you have FQDN and IP, enough for
an /etc/hosts or DNS entry to update.

I do still recommend not leaching IPs from your LAN, but to use a
seprate address range, eg 100.64.0.0/24 or something for the client
configurations and ensure the LAN machines have a route for that
to the VPN server.

In the future we will extend the addresspool code with a hook where
it can ask some external party for an IP based on a received ID.

Paul