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

Info infosec at quantum-equities.com
Tue Mar 20 23:58:08 CET 2018


Well, breakthrough.  I moved on from the IPSec gateway and phone to the
mailserver, and in swanctl.conf immediately discovered a:

connections {

This has been missing for a long time from the gateway's swanctl.conf,
and explains why swanctl -L wasn't returning anything.  May look dumb,
but this all could be shinola and I wouldn't see the difference.
(neither would anyone else)

So I put this in swanctl.conf on the IPSec gateway and then it
immediately objected that I have:

cert = cygnus-Cert.pem

That doesn't seem to be in the man page (per se) so I commented it out
and then the daemon started. (although it only recognized the last id=)

Now trying to establish a connection from the phone it times out for
something from 4500.  The gateway says it's sent that bundle to 4500, so
there might be something wrong with the firewalls.

This IPsec gateway is an independent OpenStack instance, which is
reached from the outside by DNAT through the LAN gateway.  SNAT in
Shorewall on the LAN gateway is handled by a special file called snat,
which is set up.  I see no firewall blockage in logs, but that's not
unusual for Shorewall to hide those.

Using /tcpdump 'tcp port 500'/(and 4500) yields nothing in the WAN
gateway and IPSec gateway on the relevant interfaces, although obviously
-something- is getting through for the connection to be substantially
negotiated.  I don't know what's wrong with that.



On 03/20/2018 02:32 PM, Info wrote:
>
> 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/fb5d71c8/attachment-0001.html>


More information about the Users mailing list