[strongSwan] Not Able to Connect
Info
infosec at quantum-equities.com
Tue Mar 27 22:03:37 CEST 2018
This config is supposed to work for the remote initiators to the IPSec
gateway, but I get the error I'd fought for a month. So it does not
work. I say again: It does not work.
I did have a config where I could connect from the remote phone to the
IPSec gateway, but pings went out the LTE data route rather than through
the VPN, and so of course couldn't find the internal LAN. So that does
not work.
This is one of the three "usable" swanctl configs I've tried, none of
which work for varying and inexplicable reasons. They are not actually
"usable" configs, at least the ones specifically for IKE2 and certs.
Now I am out of usable configs. Why these usable configs do not work
has got to be an error which I am in no position and do not have the
tools to decrypt. But I'm not crapping out to PSK or ipsec.conf or L2TP
like everyone else has.
There is no perspective anywhere on the mechanisms of action these
settings are supposed to do. For some reason "remote_addrs" is
mandatory yet it is not in the usable config? "/As responder, the
initiator source address must match at least to one of the specified
addresses, subnets or ranges./" And so how do I set an address in this
range in the Android app? There is no way. Not to mention that if
"remote_addrs" is required, why is it not in the usable example?
And there are a hundred other questions which could be resolved and save
us all alot of time, if just a little perspective were given on how
these things are supposed to work, rather than a blurb here, correction
there, interspersed with ill-covered temper. If you don't want to do
this or resent it Noel, just don't. Either someone else will step in or
the project will die. But don't just slap-dash it and take out your
frustrations. Maybe this is the approach because it just makes most go
away, feeling ashamed.
I get it and accept it Noel, that you are far far smarter than I am at
this. And I have never tried to tell you the things I'm smart at. In
IRC (as here) you would lead me up to a point, then go cryptic like I've
almost reached success that I shouldn't have. I am diligent, although I
can't always put my whole mind to this as I must actually make a living
while I'm doing this. You do too, but you are not the one trying to
translate ancient Sanskrit scattered in a thousand fragments, with an
encrypted Rosetta Stone.
On 03/27/2018 12:23 PM, Noel Kuntze wrote:
> Of course not, you didn't do what I wrote.
>
> You need two conns.
> One for your host-to-host scenario and one for the initiators from the internet. What you previously had worked for the host-to-host scenario.
>
> On 27.03.2018 21:20, Info wrote:
>> Back to this from the very beginning.
>>
>> Tue, 2018-03-27 12:18 15[CFG] added vici connection: ikev2-pubkey
>> Tue, 2018-03-27 12:18 08[CFG] vici client 1 disconnected
>> Tue, 2018-03-27 12:18 11[NET] <1> received packet: from 172.58.44.91[43260] to 192.168.1.16[500] (704 bytes)
>> Tue, 2018-03-27 12:18 11[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) ]
>> Tue, 2018-03-27 12:18 11[CFG] <1> looking for an ike config for 192.168.1.16...172.58.44.91
>> Tue, 2018-03-27 12:18 11[IKE] <1> no IKE config found for 192.168.1.16...172.58.44.91, sending NO_PROPOSAL_CHOSEN
>> Tue, 2018-03-27 12:18 11[ENC] <1> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
>> Tue, 2018-03-27 12:18 11[NET] <1> sending packet: from 192.168.1.16[500] to 172.58.44.91[43260] (36 bytes)
>> Tue, 2018-03-27 12:18 11[IKE] <1> IKE_SA (unnamed)[1] state change: CREATED => DESTROYING
>>
>> connections {
>>
>> # Roadwarrior Responder: https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>
>> ikev2-pubkey {
>> version = 2
>> remote_addrs = 192.168.1.0/24
>> rekey_time = 0s
>> fragmentation = yes
>> dpd_delay = 30s
>> # dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
>> local-1 {
>> certs = 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
>> }
>> }
>> }
>> }
>>
>>
>> On 03/27/2018 12:07 PM, Noel Kuntze wrote:
>>> Use "certs", not "cert". It's a typo.
>>>
>>> On 27.03.2018 21:05, Info wrote:
>>>> Back to the old:
>>>>
>>>> Mar 27 11:54:16 cygnus.darkmatter.org charon-systemd[64014]: loaded ANY private key
>>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no authorities found, 0 unloaded
>>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: no pools found, 0 unloaded
>>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loading connection 'ikev2-pubkey' failed: unknown option: cert, config discarded
>>>> Mar 27 11:54:16 cygnus.darkmatter.org swanctl[64031]: loaded 0 of 1 connections, 1 failed to load, 0 unloaded
>>>> Mar 27 11:54:16 cygnus.darkmatter.org systemd[1]: strongswan-swanctl.service: control process exited, code=exited status=22
>>>>
>>>> Daemon won't start. And in fact in
>>>> https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
>>>> ... there is no cert directive, to go anywhere. When I comment out cert the daemon starts._
>>>>
>>>>
>>>> _
>>>>
>>>> _swanctl.conf_
>>>>
>>>> connections {
>>>>
>>>> # Roadwarrior Responder: https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples
>>>>
>>>> ikev2-pubkey {
>>>> version = 2
>>>> remote_addrs = 192.168.111.0/24
>>>> rekey_time = 0s
>>>> fragmentation = yes
>>>> dpd_delay = 30s
>>>> # dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
>>>> local-1 {
>>>> cert = zeta-Cert.pem
>>>> id = zeta.darkmatter.org
>>>> }
>>>> remote-1 {
>>>> # defaults are fine.
>>>> }
>>>> children {
>>>> ikev2-pubkey {
>>>> local_ts = 0.0.0.0/0 #,::/0
>>>> rekey_time = 0s
>>>> dpd_action = clear
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>>
>>>> On 03/27/2018 11:38 AM, Noel Kuntze wrote:
>>>>> Also: You need a second conn that is fitting to what the initiators from the Internet want:
>>>>> - Tunnel Mode
>>>>> - A virtual IP
>>>>> - Access to the Internet
>>>>>
>>>>> Take the IKEv2 related parts of the roadwarrior configurations from the UsableExamples page. And make sure you get the structure right this time.
>>>>>
>>>>> On 27.03.2018 20:32, Info wrote:
>>>>>> Nothing has worked. So starting over again, with another new config, pro forma <https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests>.
>>>>>>
>>>>>> Running CentOS 7.4 with IPSec gateway as OpenStack VM, DNATted to and SNATted from by LAN gateway. Certs only, SELinux permissive, firewall down.
>>>>>>
>>>>>> The remote Android Strongswan app (initiator) is set:
>>>>>> Server: quantum-equities.com VPN Type IKEv2 certificate
>>>>>> User certificate: aries User Identity: Default
>>>>>> CA cert: Select automatically Profile name: cygnus
>>>>>> Adv. Server ID: cygnus.darkmatter.org Send cert requests
>>>>>> Custom subnets: 192.168.1.0/24
>>>>>>
>>>>>>
>>>>>> _strongswan.conf:_
>>>>>> charon {
>>>>>> load_modular = yes
>>>>>> plugins {
>>>>>> include strongswan.d/charon/*.conf
>>>>>> }
>>>>>> }
>>>>>> include strongswan.d/*.conf
>>>>>>
>>>>>> _charon.conf_
>>>>>>
>>>>>> # Needed to avoid in journalctl "fragmented IKE message is too large"
>>>>>> max_packet = 30000
>>>>>>
>>>>>> filelog {
>>>>>> /var/log/charon.log {
>>>>>> time_format = %a, %Y-%m-%d %R
>>>>>> ike_name = yes
>>>>>> append = no
>>>>>> default = 2
>>>>>> flush_line = yes
>>>>>>
>>>>>> mgr = 0
>>>>>> net = 1
>>>>>> enc = 1
>>>>>> asn = 1
>>>>>> job = 1
>>>>>> knl = 1
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> _swanctl.conf_
>>>>>>
>>>>>> connections {
>>>>>>
>>>>>> ikev2-pubkey {
>>>>>> remote_addrs = %any
>>>>>> local {
>>>>>> }
>>>>>> remote {
>>>>>> }
>>>>>>
>>>>>> children {
>>>>>> remote_ts = 192.168.1.0/24
>>>>>> local_ts = 192.168.1.0/24
>>>>>> local_addrs = 192.168.1.16
>>>>>> remote_addrs = 192.168.1.5
>>>>>> mode = transport
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> # swanctl -L
>>>>>> ikev2-pubkey: IKEv1/2, no reauthentication, rekeying every 14400s
>>>>>> local: %any
>>>>>> remote: %any
>>>>>> local unspecified authentication:
>>>>>> remote unspecified authentication:
>>>>>> # swanctl -l
>>>>>> #
>>>>>>
>>>>>> # ip route show table all
>>>>>> default via 192.168.1.1 dev eth0
>>>>>> 169.254.0.0/16 dev eth0 scope link metric 1002
>>>>>> 192.168.111.0/24 dev eth0 proto kernel scope link src 192.168.1.16
>>>>>> broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
>>>>>> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
>>>>>> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
>>>>>> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
>>>>>> broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 192.168.1.16
>>>>>> local 192.168.1.16 dev eth0 table local proto kernel scope host src 192.168.1.16
>>>>>> broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 192.168.1.16
>>>>>> unreachable ::/96 dev lo metric 1024 error -113
>>>>>> unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113
>>>>>> unreachable 2002:a00::/24 dev lo metric 1024 error -113
>>>>>> unreachable 2002:7f00::/24 dev lo metric 1024 error -113
>>>>>> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
>>>>>> unreachable 2002:ac10::/28 dev lo metric 1024 error -113
>>>>>> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
>>>>>> unreachable 2002:e000::/19 dev lo metric 1024 error -113
>>>>>> unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113
>>>>>> fe80::/64 dev eth0 proto kernel metric 256
>>>>>> local ::1 dev lo table local proto kernel metric 0
>>>>>> local fe80::5054:ff:fec0:9330 dev lo table local proto kernel metric 0
>>>>>> ff00::/8 dev eth0 table local metric 256
>>>>>>
>>>>>>
>>>>>> # ip address
>>>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
>>>>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>>>> inet 127.0.0.1/8 scope host lo
>>>>>> valid_lft forever preferred_lft forever
>>>>>> inet6 ::1/128 scope host
>>>>>> valid_lft forever preferred_lft forever
>>>>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
>>>>>> link/ether 52:54:00:c0:93:30 brd ff:ff:ff:ff:ff:ff
>>>>>> inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
>>>>>> valid_lft forever preferred_lft forever
>>>>>> inet6 fe80::5054:ff:fec0:9330/64 scope link
>>>>>> valid_lft forever preferred_lft forever
>>>>>>
>>>>>>
>>>>>> # iptables-save
>>>>>> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
>>>>>> *nat
>>>>>> :PREROUTING ACCEPT [21:3556]
>>>>>> :INPUT ACCEPT [21:3556]
>>>>>> :OUTPUT ACCEPT [25:1200]
>>>>>> :POSTROUTING ACCEPT [25:1200]
>>>>>> COMMIT
>>>>>> # Completed on Tue Mar 27 11:19:49 2018
>>>>>> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
>>>>>> *mangle
>>>>>> :PREROUTING ACCEPT [195:20990]
>>>>>> :INPUT ACCEPT [195:20990]
>>>>>> :FORWARD ACCEPT [0:0]
>>>>>> :OUTPUT ACCEPT [143:13859]
>>>>>> :POSTROUTING ACCEPT [142:13775]
>>>>>> COMMIT
>>>>>> # Completed on Tue Mar 27 11:19:49 2018
>>>>>> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
>>>>>> *raw
>>>>>> :PREROUTING ACCEPT [195:20990]
>>>>>> :OUTPUT ACCEPT [142:13775]
>>>>>> COMMIT
>>>>>> # Completed on Tue Mar 27 11:19:49 2018
>>>>>> # Generated by iptables-save v1.4.21 on Tue Mar 27 11:19:49 2018
>>>>>> *filter
>>>>>> :INPUT ACCEPT [195:20990]
>>>>>> :FORWARD ACCEPT [0:0]
>>>>>> :OUTPUT ACCEPT [142:13775]
>>>>>> COMMIT
>>>>>> # Completed on Tue Mar 27 11:19:49 2018
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180327/2803de57/attachment-0001.html>
More information about the Users
mailing list