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