[strongSwan] One to Many VPN (Host-Host)

Info infosec at quantum-equities.com
Tue Mar 20 22:32:23 CET 2018


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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180320/e3dfa22c/attachment.html>


More information about the Users mailing list