[Swan] A Super-LAN

colony.three at protonmail.ch colony.three at protonmail.ch
Fri Jan 26 17:54:29 UTC 2018


Well I've finally failed with Libreswan.

I give up.

-------- Original Message --------
On January 12, 2018 12:12 PM, Colony.three <colony.three at protonmail.ch> wrote:

> 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.
>
> Wasn't actually planning on LAN IPSec.  I've tried to keep this inquiry limited to the gateway in the LAN and its relation to the outside.
>
> But as an aside, there's alot to be said for encrypted data in-transit both inside and outside the LAN.  It's what's starting to happen in enterprise.  And to differentiate in any way between the inside-LAN and outside-LAN when they're in the same trust zone, seems old-fashioned.
>
>>
>>
>>> 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.
>
> This would be the case if a DHCP-type internal IP assignment, as the system seems to be designed.  But I am asking, and you are trying to help, with simulating static address assignment, in which case reconfiguration wouldn't be an issue.  It comes down to remotes, connecting to a hub.
>
>>
>>
>>> - 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.
>
> I know, this is one thing you guys say, and I start by thinking this way.  But then y'all talk about one being a 'server' as if the other is a client, which is confusing.  And bleve punishes me for referring to clients and servers.
>
> 'Peers' is what they're ostensibly supposed to be, but at the same time we have to be able to designate which machine we are talking about with some solidity, and client/server is one way.
>
> I've tried referring to left/right, but as I say when you're configuring the 'left', then move to the other machine -it- is then the 'left', paradoxically.  It's as bad as quantum mechanics.  I've also tried speaking of gateway/remote and initiator/responder but these are brushed off.  I am left with no rungs on my ladder.  I think you Paul refer to client/server, which is fine, we need some kind of anchor, but bleve scolds me for that, without giving any alternative to the above paradox.
>
>>> - 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.
>
> Ok sourceip is out.  I don't understand its purpose, but it's apparently not of use here.
>
>>
>> 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.
>
> Maybe you mean the server *subnet should be 0.0.0.0/0?  I set this, removed the *sourceip line, and set leftaddresspool=100.64.1.16/32 and it errors "cannot specify both leftsubnet= and leftaddresspool=".  So I commented out leftsubnet= and it errors "bad leftaddresspool=100.64.1.16/32 [missing '-' in ip address range]"
> And I couldn't connect with the Android Ss app which usually works.
>
>>
>> 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.
>
> So in the gateway, set up separate right stanzas for each client, I think.  The Android Ss app does have a setting for 'Custom subnets', and I can set the laptops for this of course.  Then the client has to identify itself with the correct rightid?  Hope that's right, because it would be sensible.
>
>>
>> I do still recommend not leaching IPs from your LAN, but to use a
>> separate 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.
>
> I'll do whatever is necessary to get fixed and predictable IPs, whether different from the LAN or not.  But really there's no technical nor logical reason why the VPN should be differentiated from the LAN in any way if in the same trust zone, in fact quite the contrary.  The link establishment and encryption should be transparent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180126/2fae0a63/attachment.html>


More information about the Swan mailing list