Pretty bad, isn't it.

Try to remember when you were first starting out and had everything to
learn, and had never gotten any of this working yet.  That's where I am.

I'm trying to give you everything you need to determine the problem, and
the key symptom is swanctl -L on the IPSec gateway gives nothing.  I
believe I'm setting it all up as it's supposed to be.  SELinux
Permissive.  This is why I'm wondering if it's a RedHat bug?

# /usr/sbin/swanctl --load-all
loaded certificate from '/etc/strongswan/swanctl/x509/cygnus-Cert.pem'
loaded certificate from '/etc/strongswan/swanctl/x509/hydrus-Cert.pem'
loaded certificate from '/etc/strongswan/swanctl/x509/lepus-Cert.pem'
loaded certificate from '/etc/strongswan/swanctl/x509/scorpius-Cert.pem'
loaded certificate from '/etc/strongswan/swanctl/x509ca/aries-CAcert.pem'
loaded rsa key from '/etc/strongswan/swanctl/private/cygnus-Key.pem'
no authorities found, 0 unloaded
no pools found, 0 unloaded
no connections found, 0 unloaded
# swanctl -L
#



On 03/20/2018 12:16 PM, Info wrote:
>
> On 03/20/2018 12:34 AM, Tobias Brunner wrote:
>> Hi,
>>
>>>   When my gateway must
>>> validate with machines inside the LAN (as cygnus.darkmatter.org) and
>>> outside (as quantum-equities.com), how can it prove that it's the right
>>> machine if not DNS resolvable by checking CN=? 
>> That's exactly what SANs are for and why you an use --san multiple times.
> Ah HA!  So it is the SAN which is pivotal.  I couldn't find this anywhere.
>
>
>>> And how does the phone prove it is who it is in the Android app when its
>>> IP changes and is not resolvable?  The responder has to take its word
>>> for it since it has the private key?  If so, why is --san and --dn required?
>> The server uses the trust chain to verify that the client certificate is
>> issued by a trusted CA certificate and checks the signature in the AUTH
>> payload that proves the client is in possession of the private key.  The
>> DN and SANs are used as identification of the clients (and you could
>> e.g. match them in different configs).
> Ah HA!  This is a choice nugget of info, thank you
> .
>>
>>>>> # swanctl -L
>>>>> # swanctl -l
>>>>> (no response, for some reason)
>>>> Yes, and that reason is:  No config has been loaded.  Did you run
>>>> swanctl --load-conns (-c) or --load-all (-q)?
>>> I haven't mentioned this, but I'm running CentOS7 which handles this in
>>> systemd:
>>> ExecStart=/usr/sbin/charon-systemd
>>> ExecStartPost=/usr/sbin/swanctl --load-all --noprompt
>>>
>>> ... and yet I still have nothing with
>> Then you obviously haven't added the connection configs to the right
>> file.  Did you add them to /etc/strongswan/swanctl/swanctl.conf?
> Maybe not so obvious, but yes sir, modifications only made to
> swanctl.conf and charon.conf, and daemon started with ststemctl start
> strongswan-swanctl. (CentOS7)  I've described in detail all requested
> info in the HelpRequests page
> <https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests>,
> in my email to this list of 18/03/2018 16:52.  The problem hasn't
> changed, but I'll update it here:
>
> -------------------------------------------------------------------------------------------
>
> This post is formatted as per here
> <https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests>.
>
> I'm using the bare minimum swanctl.conf and I've regenerated all my
> keys and certs again, with multiple SANs for the IPSec gateway. 
>
> The IPSec gateway, is a virtual machine in the LAN, and DNATted to by
> the LAN gateway
>
> The problem is when the phone tries to connect with the Android app,
> its log says "NO_PROPOSAL_CHOSEN".  The IPSec gateway's log shows
> likewise.  On the IPSec gateway there is no response to # swanctl -L
> nor # swanctl -l.
>
> Also I would like to set the phone and other remotes to 'initiate
> only' but there doesn't seem to be a way in the Android app.  And for
> other remote machines there no longer seems to be that option.
>
> On the IPSec gateway:
>
> Log levels are as per instructions, and charon.log is attached.
>
> strongswan.conf
> charon {
>         load_modular = yes
>         plugins {
>                 include strongswan.d/charon/*.conf
>         }
> }
>
> include strongswan.d/*.conf
>
>
> swanctl.conf
> iikev2-pubkey {
>         version = 2
>         rekey_time = 0s
>         local {
>                 cert = cygnus-Cert.pem
>                 id = quantum-equities.com
>                 id = cygnus.darkmatter.org
>         }
>         remote {
>                 # defaults are fine.
>         }
>         children {
>                 ikev2-pubkey {
>                         local_ts = 192.168.1.0/24 #,::/0
>                         mode = transport
>                 }
>         }
> }
>
>
> charon.conf
> charon {
>
> # two defined file loggers
>     filelog {
>         /var/log/charon.log {
>             time_format = %a, %Y-%m-%d %R
>             ike_name = yes
>             append = no
>             default = 2
>             flush_line = yes
>         }
>         stderr {
>                 mgr = 0
>                 net = 1
>                 enc = 1
>                 asn = 1
>                 job = 1
>                 knl = 1
>         }
>     }
>
>
> # swanctl -L
> # swanctl -l
> (no response, for some reason)
>
> # systemctl status strongswan-swanctl
> ● strongswan-swanctl.service - strongSwan IPsec IKEv1/IKEv2 daemon
> using swanctl
>    Loaded: loaded (/usr/lib/systemd/system/strongswan-swanctl.service;
> enabled; vendor preset: disabled)
>    Active: active (running) since Tue 2018-03-20 11:08:41 PDT; 2s ago
>   Process: 25749 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt
> (code=exited, status=0/SUCCESS)
>  Main PID: 25730 (charon-systemd)
>    Status: "charon-systemd running, strongSwan 5.5.3, Linux
> 4.13.0-1.el7.elrepo.x86_64, x86_64"
>    CGroup:
> /system.slice/strongswan-swanctl.service                                      
>           
>
>            └─25730
> /usr/sbin/charon-systemd                                                      
>   
>
>                                                                               
>                      
>
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: no authorities
> found, 0 unloaded                
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: no pools found, 0
> unloaded                      
> Mar 20 11:08:41 cygnus.darkmtter.org systemd[1]: Started strongSwan
> IPsec IKEv1/IKEv2 daemon using swanctl.
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: no connections
> found, 0 unloaded                
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded
> certificate from '/etc/strongswan/swanctl/x509/cygnus-Cert.pem'
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded
> certificate from '/etc/strongswan/swanctl/x509/hydrus-Cert.pem'
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded
> certificate from '/etc/strongswan/swanctl/x509/lepus-Cert.pem'
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded
> certificate from '/etc/strongswan/swanctl/x509/scorpius-Cert.pem'
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded
> certificate from '/etc/strongswan/swanctl/x509ca/aries-CAcert.pem'
> Mar 20 11:08:41 cygnus.darkmtter.org swanctl[25749]: loaded private
> key from '/etc/strongswan/swanctl/private/cygnus-Key.pem'
>
> # iptables-save
> (attached)
>
> # 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.1.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
> fe80::/64 dev ipsec0 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
> local fe80::bc44:9b91:2691:e6a2 dev lo table local proto kernel metric 0
> ff00::/8 dev eth0 table local metric 256
> ff00::/8 dev ipsec0 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:23: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
> 24: ipsec0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
> pfifo_fast state UNKNOWN qlen 500
>     link/none
>     inet6 fe80::22e9:6b12:6b8e:b558/64 scope link flags 800
>        valid_lft forever preferred_lft forever
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Reply via email to