<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000066" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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? "<i>As
responder, the initiator source address must match at least to
one of the specified addresses, subnets or ranges.</i>" 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?</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 03/27/2018 12:23 PM, Noel Kuntze
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:009b5471-62c1-8449-3e19-192cfb6a4c1c@thermi.consulting">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">
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: <a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples">https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">Use "certs", not "cert". It's a typo.
On 27.03.2018 21:05, Info wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf">https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf</a>
... there is no cert directive, to go anywhere. When I comment out cert the daemon starts._
_
_swanctl.conf_
connections {
# Roadwarrior Responder: <a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples">https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Nothing has worked. So starting over again, with another new config, pro forma <a class="moz-txt-link-rfc2396E" href="https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests"><https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests></a>.
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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>