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