[strongSwan] One to Many VPN (Host-Host)
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Sun Mar 18 14:03:31 CET 2018
I'm merging three different mails here.
> No one seems to be using swanctl judging from no response on #IRC. It's a far better system than ipsec.conf.
>
Just nobody bothers answering you. There are plenty people using it.
>
> I've given up on my complete LAN using VPN as some devices can not do IPSec, and I can't figure out how to make them interoperate with machines running IPSec.
>
Use passthrough policies for those hosts.
>
> So I've relegated myself to using an IPSec gateway in the LAN to link with outside machines.
>
> I still don't understand the language of swanctl.conf. For example my best guess is this is correct for the gateway, and the gateway can still communicate with all non-IPSec machines in the LAN while running strongswan-swanctl, and I've fixed the SELinux problems, but it does not work with my remote machines. The daemon starts just fine and loads all the certs and keys of course.
>
> ikev2-pubkey {
> version = 2
> # proposals = aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
> rekey_time = 0s
> pools = primary-pool-ipv4 #, primary-pool-ipv6
> fragmentation = yes
> dpd_delay = 30s
> # dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
> local-1 {
> cert = cygnus-Cert.pem
> id = cygnus.darkmatter.org
> }
> remote-1 {
> # defaults are fine.
> }
> children {
> ikev2-pubkey {
> local_ts = 0.0.0.0/0 #,::/0
> rekey_time = 0s
> dpd_action = clear
> # esp_proposals = aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
> }
> }
> }
>
Why would you want to propose the local_ts to be all hosts in your use case? That makes no sense.
> So each end should take the other end's public cert, combine it with its private key, and come up with a symmetric key to communicate with.
>
No. That is completely wrong. Each host uses its certificate's private key to sign a piece of data that is part of the key exchange. The signature can be checked with the corresponding certificate. As soon as both sides have verified the authenticity, the transmitted data is used to negotiate the shared key, from which keys for encryption and MAC algorithms are derived for this IKE SA. A host only ever has its own private key. Nobody else has that particular private key.
> The local_ts determines what traffic is to go in to IPSec, but that would be all of it.
>
No. The local_ts configures the proposed local part of the traffic selector. That is/are, for traffic coming from you side over the tunnel, the subnet(s) which are allowed to appear in the source IP field.
For packets coming from the other peer over the tunnel, that is/are the subnet(s) which are allowed to appear in the destination IP field.
The remote_ts configures proposed remote part of the traffic selector. That is/are , for traffic coming from your side over the tunnel, the subnet(s) which are allowed to appear in the destination IP field.
For packets coming from the other peer over the tunnel, that is/are the subnet(s) which are allowed to appear in the source IP field. That is applied vice-versa for the other peer (your local_ts is their remote_ts).
The proposed traffic selectors are narrowed by the two sides to a biggest common set. That is called traffic selector narrowing. strongSwna implements it for IKEv1 and IKEv2, but it is only part of the standard for IKEv2. It allows greater flexibility with peers that implement it for IKEv1, too.
A negotiated(!) traffic selector is always symmetric for the two peers. Meaning that the negotiated local_ts is the remote's remote_ts and vice-versa. The particualr exception on Linux is the mark field of a policy or state. The idea is that the local configured mark can be used to determin which traffic exactly is to be tunneled and be able to use the full flexibility of netfilter for that. The mark is not transmitted to the other peer.
> So from another machine in the LAN I aim at the mailserver outside at 72.251.232.108, if I can somehow make the LAN direct traffic to the IPSec gateway (which is different from the LAN gateway), the IPSec gateway should somehow aim it at the mailserver rather than the remote phone or tablet.
>
> And somehow the IPSec gateway should be able to carry on simultaneous conversations with the mailserver and phone/tablet, but surely that means two point-to-point connections..
Yes.
> The IPSec gateway is a virtual machine dedicated to being the IPSec gateway for the LAN. All port 500 and 4500 traffic is directed to it by the LAN gateway using DNAT, and the LAN gateway has a public IP. No special measures have been taken on the LAN gateway for routing ESP.
>
ESP shouldn't really matter for your peers, because every one of them is supposed to switch to UDP encapsulation as soon as the NAT on your router is detected.
>
> On the remote phone, which runs the Strongswan app and has a public IP, an attempt to connect results in my old friend "NO_PROPOSAL_CHOSEN".
>
> In the IPSec gateway's log is:
>
> Mar 16 17:57:08 12[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
> Mar 16 17:57:08 12[CFG] <1> looking for an ike config for 192.168.1.16...192.168.1.6
> Mar 16 17:57:08 12[IKE] <1> no IKE config found for 192.168.1.16...192.168.1.6, sending NO_PROPOSAL_CHOSEN
>
What did you configure there?
> Well both the IPSec gateway and remote phone, are using their static LAN IP rather than any reference to a public IP, for some reason. That seems pretty queer.
>
> 'No IKE config found' might imply that remote_ts has to have 192.168.1.0/24, although extensive past experience shows that I can fiddle with infinite permutations in this and fail indefinitely. I just don't understand the language -meaning- of the config files settings yet, in terms of plain English.
>
The listed IP is what is in the IP packet's source and destination address and it's probably not the problem right now.
On 17.03.2018 21:14, Info wrote:
>
> Of course it's wrong to add
>
> remote_ts = 192.168.1.0/24
> below
> local_ts = 0.0.0.0/0 #,::/0
>
> ... I'd successfully predicted that...
>
> Mar 17 13:05:08 10[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
> Mar 17 13:05:08 10[CFG] <1> looking for an ike config for 192.168.1.16...192.168.1.6
> Mar 17 13:05:08 10[IKE] <1> no IKE config found for 192.168.1.16...192.168.1.6, sending NO_PROPOSAL_CHOSEN
> Mar 17 13:05:08 10[ENC] <1> added payload of type NOTIFY to message
> Mar 17 13:05:08 10[ENC] <1> order payloads in message
> Mar 17 13:05:08 10[ENC] <1> added payload of type NOTIFY to message
> Mar 17 13:05:08 10[ENC] <1> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
> Mar 17 13:05:08 10[ENC] <1> not encrypting payloads
> Mar 17 13:05:08 10[ENC] <1> generating payload of type HEADER
> Mar 17 13:05:08 10[ENC] <1> generating rule 0 IKE_SPI
> Mar 17 13:05:08 10[ENC] <1> generating rule 1 IKE_SPI
> Mar 17 13:05:08 10[ENC] <1> generating rule 2 U_INT_8
> Mar 17 13:05:08 10[ENC] <1> generating rule 3 U_INT_4
> Mar 17 13:05:08 10[ENC] <1> generating rule 4 U_INT_4
> Mar 17 13:05:08 10[ENC] <1> generating rule 5 U_INT_8
> Mar 17 13:05:08 10[ENC] <1> generating rule 6 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 7 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 8 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 9 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 10 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 11 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 12 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 13 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 14 U_INT_32
> Mar 17 13:05:08 10[ENC] <1> generating rule 15 HEADER_LENGTH
> Mar 17 13:05:08 10[ENC] <1> generating HEADER payload finished
> Mar 17 13:05:08 10[ENC] <1> generating payload of type NOTIFY
> Mar 17 13:05:08 10[ENC] <1> generating rule 0 U_INT_8
> Mar 17 13:05:08 10[ENC] <1> generating rule 1 FLAG
> Mar 17 13:05:08 10[ENC] <1> generating rule 2 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 3 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 4 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 5 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 6 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 7 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 8 RESERVED_BIT
> Mar 17 13:05:08 10[ENC] <1> generating rule 9 PAYLOAD_LENGTH
> Mar 17 13:05:08 10[ENC] <1> generating rule 10 U_INT_8
> Mar 17 13:05:08 10[ENC] <1> generating rule 11 SPI_SIZE
> Mar 17 13:05:08 10[ENC] <1> generating rule 12 U_INT_16
> Mar 17 13:05:08 10[ENC] <1> generating rule 13 SPI
> Mar 17 13:05:08 10[ENC] <1> generating rule 14 CHUNK_DATA
> Mar 17 13:05:09 10[ENC] <1> generating NOTIFY payload finished
> Mar 17 13:05:09 10[NET] <1> sending packet: from 192.168.1.16[500] to 192.168.1.6[40976] (36 )
> Mar 17 13:05:09 10[MGR] <1> checkin and destroy IKE_SA (unnamed)[1]
> Mar 17 13:05:09 10[IKE] <1> IKE_SA (unnamed)[1] state change: CREATED => DESTROYING
> Mar 17 13:05:09 10[MGR] checkin and destroy of IKE_SA successful
> Mar 17 13:05:09 04[NET] sending packet: from 192.168.1.16[500] to 192.168.1.6[40976]
>
> 'Read the docs'? I've done that for a month, and it turns out that most pertain to the old way, and so I am quite confused at this point.
>
Your logging configuration is too verbose and the problem is that there is no matching IKE SA configuration found for what the peer wants. What is configured on it?
>
> On 03/16/2018 06:11 PM, Info wrote:
>>
>> The IPSec gateway is a virtual machine dedicated to being the IPSec gateway for the LAN. All port 500 and 4500 traffic is directed to it by the LAN gateway using DNAT, and the LAN gateway has a public IP. No special measures have been taken on the LAN gateway for routing ESP.
>>
>> On the remote phone, which runs the Strongswan app and has a public IP, an attempt to connect results in my old friend "NO_PROPOSAL_CHOSEN".
>>
>> In the IPSec gateway's log is:
>>
>> Mar 16 17:57:08 12[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>> Mar 16 17:57:08 12[CFG] <1> looking for an ike config for 192.168.1.16...192.168.1.6
>> Mar 16 17:57:08 12[IKE] <1> no IKE config found for 192.168.1.16...192.168.1.6, sending NO_PROPOSAL_CHOSEN
>>
>> Well both the IPSec gateway and remote phone, are using their static LAN IP rather than any reference to a public IP, for some reason. That seems pretty queer.
>>
>> 'No IKE config found' might imply that remote_ts has to have 192.168.1.0/24, although extensive past experience shows that I can fiddle with infinite permutations in this and fail indefinitely. I just don't understand the language -meaning- of the config files settings yet, in terms of plain English.
>>
>>
>> On 03/16/2018 05:52 PM, Info wrote:
>>>
>>> Granted, and actually I'm much further than this now, thanks in part to your help.
>>>
>>> I was seeing whether it's worth bothering here.
>>>
>>> No one seems to be using swanctl judging from no response on #IRC. It's a far better system than ipsec.conf.
>>>
>>> I've given up on my complete LAN using VPN as some devices can not do IPSec, and I can't figure out how to make them interoperate with machines running IPSec. So I've relegated myself to using an IPSec gateway in the LAN to link with outside machines.
>>>
>>> I still don't understand the language of swanctl.conf. For example my best guess is this is correct for the gateway, and the gateway can still communicate with all non-IPSec machines in the LAN while running strongswan-swanctl, and I've fixed the SELinux problems, but it does not work with my remote machines. The daemon starts just fine and loads all the certs and keys of course.
>>>
>>> ikev2-pubkey {
>>> version = 2
>>> # proposals = aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
>>> rekey_time = 0s
>>> pools = primary-pool-ipv4 #, primary-pool-ipv6
>>> fragmentation = yes
>>> dpd_delay = 30s
>>> # dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
>>> local-1 {
>>> cert = cygnus-Cert.pem
>>> id = cygnus.darkmatter.org
>>> }
>>> remote-1 {
>>> # defaults are fine.
>>> }
>>> children {
>>> ikev2-pubkey {
>>> local_ts = 0.0.0.0/0 #,::/0
>>> rekey_time = 0s
>>> dpd_action = clear
>>> # esp_proposals = aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
>>> }
>>> }
>>> }
>>>
>>> So each end should take the other end's public cert, combine it with its private key, and come up with a symmetric key to communicate with.
>>>
>>> The local_ts determines what traffic is to go in to IPSec, but that would be all of it. So from another machine in the LAN I aim at the mailserver outside at 72.251.232.108, if I can somehow make the LAN direct traffic to the IPSec gateway (which is different from the LAN gateway), the IPSec gateway should somehow aim it at the mailserver rather than the remote phone or tablet.
>>>
>>> And somehow the IPSec gateway should be able to carry on simultaneous conversations with the mailserver and phone/tablet, but surely that means two point-to-point connections..
>>>
>>>
>>> On 03/16/2018 05:24 PM, Noel Kuntze wrote:
>>>> We two talked about this on IRC about two weeks ago. Use the Host-To-Host transport mode configuration on the bottom of the UsableExamples page.
>>>> How you authenticate the hosts is up to you. Preferably, you want to have some central PKI that you use. Maybe put the keys in DNS using the ipseckey plugin, but I haven't tested that yet.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180318/0987fc45/attachment.sig>
More information about the Users
mailing list