[strongSwan] Not Able to Connect
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Tue Mar 27 21:23:02 CEST 2018
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 --------------
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/20180327/5dc19c16/attachment.sig>
More information about the Users
mailing list