Re: [strongSwan] nonce Length
On 9/14/2017 11:53 AM, Andreas Steffen wrote: Hi Jafar, the mandatory nonce plugin is a nonce generator which returns the requested number of random bytes. There are many other places in the strongSwan code where nonces of variable size are needed (e.g. for the IKE SPI or for the TLS client or server Hello). Sure, my first grep -r "nonce" returned hundreds if not thousands of results. Thanks again for the explanation, and also for the great work of StrongSwan team. Kind Regards, Jafar Kind regards Andreas On 14.09.2017 17:28, Jafar Al-Gharaibeh wrote: Hi Andreas, Thanks for the quick and thorough answer. I did not find that piece of information (nonce size) in the documentation, but as you noted about the source code, I did download and dig through the source code yesterday and came across the the 32 byte number. Thanks for confirming that. I also came across nonce plugin configuration: nonce { } Is there really any thing configurable here or is that just there for completeness? Kind Regards, Jafar On 9/14/2017 1:56 AM, Andreas Steffen wrote: Hi Jafar, section 2.10 of IKEv2 RFC 7296 [1] states that Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). However, the initiator chooses the nonce before the outcome of the negotiation is known. Because of that, the nonce has to be long enough for all the PRFs being proposed. This is why strongSwan generates nonces with a constant size of 32 bytes (256 bits) as defined in nonce_payloads.h [2] /** * Nonce size in bytes for nonces sending to other peer. */ #define NONCE_SIZE 32 Best regards Andreas [1]https://tools.ietf.org/html/rfc7296#section-2.10 [2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30 On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote: Hi, What is the default length of the nonce used to establish and rekey IKE/Child SAs? is that based on the DH group? and is the length configurable? Thanks, Jafar == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]==
Re: [strongSwan] nonce Length
Hi Jafar, the mandatory nonce plugin is a nonce generator which returns the requested number of random bytes. There are many other places in the strongSwan code where nonces of variable size are needed (e.g. for the IKE SPI or for the TLS client or server Hello). Kind regards Andreas On 14.09.2017 17:28, Jafar Al-Gharaibeh wrote: Hi Andreas, Thanks for the quick and thorough answer. I did not find that piece of information (nonce size) in the documentation, but as you noted about the source code, I did download and dig through the source code yesterday and came across the the 32 byte number. Thanks for confirming that. I also came across nonce plugin configuration: nonce { } Is there really any thing configurable here or is that just there for completeness? Kind Regards, Jafar On 9/14/2017 1:56 AM, Andreas Steffen wrote: Hi Jafar, section 2.10 of IKEv2 RFC 7296 [1] states that Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). However, the initiator chooses the nonce before the outcome of the negotiation is known. Because of that, the nonce has to be long enough for all the PRFs being proposed. This is why strongSwan generates nonces with a constant size of 32 bytes (256 bits) as defined in nonce_payloads.h [2] /** * Nonce size in bytes for nonces sending to other peer. */ #define NONCE_SIZE 32 Best regards Andreas [1]https://tools.ietf.org/html/rfc7296#section-2.10 [2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30 On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote: Hi, What is the default length of the nonce used to establish and rekey IKE/Child SAs? is that based on the DH group? and is the length configurable? Thanks, Jafar == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]== -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]== smime.p7s Description: S/MIME Cryptographic Signature
Re: [strongSwan] nonce Length
Hi Andreas, Thanks for the quick and thorough answer. I did not find that piece of information (nonce size) in the documentation, but as you noted about the source code, I did download and dig through the source code yesterday and came across the the 32 byte number. Thanks for confirming that. I also came across nonce plugin configuration: nonce { } Is there really any thing configurable here or is that just there for completeness? Kind Regards, Jafar On 9/14/2017 1:56 AM, Andreas Steffen wrote: Hi Jafar, section 2.10 of IKEv2 RFC 7296 [1] states that Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF). However, the initiator chooses the nonce before the outcome of the negotiation is known. Because of that, the nonce has to be long enough for all the PRFs being proposed. This is why strongSwan generates nonces with a constant size of 32 bytes (256 bits) as defined in nonce_payloads.h [2] /** * Nonce size in bytes for nonces sending to other peer. */ #define NONCE_SIZE 32 Best regards Andreas [1]https://tools.ietf.org/html/rfc7296#section-2.10 [2]https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/encoding/payloads/nonce_payload.h;h=ee8ad17f789ed4fe6a2e3476fc710b79d74885aa;hb=HEAD#l30 On 13.09.2017 20:37, Jafar Al-Gharaibeh wrote: Hi, What is the default length of the nonce used to establish and rekey IKE/Child SAs? is that based on the DH group? and is the length configurable? Thanks, Jafar == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[INS-HSR]==
Re: [strongSwan] 24/7/365 tunnel?
On 14 Sep 2017, at 11:23, Eric Germann wrote: > I’ve found auto=route to be much more stable in AWS. Spins up when it’s down > but needed and starts passing traffic. Ok, thanx! I’ll let it run like this for a couple of days so I get a feel for how it works and then try that if I have to.. signature.asc Description: Message signed with OpenPGP
Re: [strongSwan] strongswan not picking up traffic
Hi, You're expected to use auto=route. It is normal, by design and common with all other *swans, that auto=add does not initiate a connection. You gotta read the manual/documentation before using the software. Kind regards Noel On 14.09.2017 09:07, Chengcheng Fu wrote: > Hi, > > After I manually bring up the tunnel from the spoke side, it has started > working. > > "ipsec up host-host". > > But is this normal?? > > Regards, > > Terry > > On Sep 13, 2017, at 07:12 PM, Chengcheng Fu wrote: > >> Hi, >> >> The GRE tunnel is working on its own, it's like Strongswan is not even aware >> of it's happening, and not trying to encapsulate it. >> I must be missing something simple. >> >> Below are my configs. >> >> >> = >> hub-192.168.23.193 >> = >> # ipsec.conf # >> config setup >> >> conn %default >> ikelifetime=60m >> keylife=20m >> rekeymargin=3m >> keyingtries=1 >> authby=secret >> mobike=no >> keyexchange=ikev2 >> >> conn host-host >> left=192.168.23.193 >> leftprotoport=gre >> rightprotoport=gre >> type=transport >> auto=add >> reauth=no >> closeaction=clear >> keyexchange=ikev2 >> right=%any >> mark=%unique >> >> >> # strongswan.conf # >> charon { >> load_modular = yes >> plugins { >> include strongswan.d/charon/*.conf >> } >> filelog { >> /var/log/charon_debug.log { >> time_format = %a, %Y-%m-%d %R >> default = 2 >> mgr = 0 >> net = 1 >> enc = 1 >> asn = 1 >> job = 1 >> knl = 1 >> ike_name = yes >> append = no >> flush_line = yes >> } >> } >> } >> >> include strongswan.d/*.conf >> >> >> >> # swanctl.conf # >> include conf.d/*.conf >> >> >> >> >> # ipsec statusall # >> Status of IKE charon daemon (strongSwan 5.6.0, Linux 4.9.47, x86_64): >> uptime: 12 minutes, since Sep 14 09:52:04 2017 >> malloc: sbrk 1081344, mmap 0, used 267712, free 813632 >> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, >> scheduled: 0 >> loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 >> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem >> fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve >> socket-default stroke vici updown xauth-generic >> Listening IP addresses: >> 192.168.23.193 >> 192.168.34.1 >> Connections: >> host-host: 192.168.23.193...%any IKEv2 >> host-host: local: [192.168.23.193] uses pre-shared key authentication >> host-host: remote: uses pre-shared key authentication >> host-host: child: dynamic[gre] === dynamic[gre] TRANSPORT >> Security Associations (0 up, 0 connecting): >> none >> >> >> >> >> # iptables -L -v # >> Chain INPUT (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source destination >> 25 1876 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED >> 0 0 ACCEPT icmp -- any any anywhere anywhere >> 0 0 ACCEPT all -- lo any anywhere anywhere >> 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ssh >> >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) >> pkts bytes target prot opt in out source destination >> >> Chain OUTPUT (policy ACCEPT 13 packets, 1332 bytes) >> pkts bytes target prot opt in out source destination >> >> >> >> >> >> # ip route show table all # >> default via 192.168.23.232 dev eth0 proto static metric 20 >> default via 192.168.23.232 dev eth0 proto static metric 100 >> 192.168.23.0/24 dev eth0 proto kernel scope link src 192.168.23.193 metric >> 100 >> 192.168.34.3 dev gre1 proto kernel scope link src 192.168.34.1 >> 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.23.0 dev eth0 table local proto kernel scope link src >> 192.168.23.193 >> local 192.168.23.193 dev eth0 table local proto kernel scope host src >> 192.168.23.193 >> broadcast 192.168.23.255 dev eth0 table local proto kernel scope link src >> 192.168.23.193 >> local 192.168.34.1 dev gre1 table local proto kernel scope host src >> 192.168.34.1 >> unreachable default dev lo proto kernel metric 4294967295 error -101 pref >> medium >> unreachable ::/96 dev lo metric 1024 error -113 pref medium >> unreachable :::0.0.0.0/96 dev lo metric 1024 error -113 pref medium >> unreachable 2002:a00::/24 dev lo metric 1024 error -113 pref medium >> unreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref medium >> unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref medium >> unreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref medium >> unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref medium >> unreachable 2002:e000::/19 dev lo metric 1024 error -113 pref medium >> unreachable 3ffe:::/32 dev lo metric 1024 error -113 pref medium >> fe80::/64 dev eth0 proto kernel metr
Re: [strongSwan] 24/7/365 tunnel?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You need to use auto=route, otherwise the tunnel will not be established (anymore) if it ever gets deleted by one side, a fatal error is encountered or it can not be established in the first place. On 14.09.2017 12:23, Eric Germann wrote: > I’ve found auto=route to be much more stable in AWS. Spins up when it’s down > but needed and starts passing traffic. > > EKG > >> On Sep 14, 2017, at 6:21 > AM, Turbo Fredriksson wrote: >> >> I’ve been playing with: > >> >> type=tunnel >> auto=start >> dpdaction=restart >> dpddelay=2400s >> >> > which never worked. I’ve now changed this to: >> >> type=tunnel >> auto=start > >> dpdaction=restart >> dpddelay=10 >> dpdtimeout=60 >> >> and so far so > good. Although I haven’t waited long enough, so I’m >> going to let it be for > the next few days to see if that works in the long >> run. >> >> Would it > help to set ‘auto=route’ instead? Thing is, I need this link to >> be started > at boot AND be up 24/7/365 - I have a (bunch of) web apps >> in London that > need access to databases in Ireland to work. >> >> >> I’m considering setting > up DBs in London as well, but that will both >> cost a small fortune AND > replication/updates on the DBs will be >> problematic. So I’d prefer a > “perfect” link between them... >> >> >>> On 13 Sep 2017, at 20:16, Noel Kuntze wrote: >>> >>> Hi, >>> >>> DPD just checks if the remote peer is still "there" and reachable. It doesn't do anything with the CHILD_SAs. >>> It only helps to keep up the IKE_SA and keep it working (e.g. it wouldn't work anymore if the NAT mapping on an intermediate NAT router >>> would expire). Peers are free to delete CHILD_SAs and IKE_SAs without renegotiating new ones, destroying the tunnel. >>> >>> Use auto=route (swanctl equivalent is start_action=trap), as advised previously. >>> >>> Kind regards >>> >>> Noel >>> >>> On 13.09.2017 17:38, Michael Schwartzkopff wrote: Am 13.09.2017 um 17:33 schrieb Eric Germann: > Usually if it "takes down the tunnel" it's due to no traffic. Keep interesting traffic going and it will stay up. > > If you have the ability to set "auto = route" it will reestablish the tunnel as needed. We run several hundred tunnels this way in AWS without issue. > > EKG > > >> On Sep 13, 2017, at 09:21, Turbo Fredriksson wrote: >> >> >> I’m trying to setup a tunnel between two regions in >> >> AWS. >> >> Works fine, other than the fact that Strongswan seems >> to take >> down the tunnel automatically (?) after a few hours. >> >> >> How can I 1) make sure there’s no timeout (?) and 2) that >> IF >> the tunnel goes down, for whatever reason, that it will >> reinitiate >> the connection automatically? >> Dead Peer >> Detection (DPD) sends packets that keep the tunnel up. >> Michael Schwartzkopff Mit freundlichen Grüßen, >>> >> > >> -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEENSSTvrX3jmMTcq8t9U7kCwc5rWwFAlm6X6cACgkQ9U7kCwc5 rWy5Cg/+P02oFmCJwB9qiREw4DXCRZRCo8HAeC6mlP0P95PfvWy4Lr20LX1SMNhw PBgm7c7dQHyKjQO/fqGPTB4kbi03Or5lYtyYLc3Y1YDJ79W2OpVTCiHoaznleyW6 elVZyPBhxeZYYWI4FekcgOB9vS+ek8Jbz2FNI+16b7hfHwN3QnkU1X5DH9oVkO+J aW0ywUwKgNMMxtDEmFvUffBb/uxJ1DOq4XHaNIYNicOQ6wkbc3GMlbVh6Bz7MUbI RJutqLiZqMy7Da6VPP6Xf+Y1ogvCLPmzqDHCxhwCrw2b3BBgOSpNqMzV+37h5POh qTFabCd42PC8lNm8BGrEixvVk3GqHkIshaww0bdqrYYdYh3DQHqbBfQsWCS62r8q iSrccp4CUxSzTp5VEcGT8GFPAXT7lcsovl2iPnAodl9TMiksh9JqzwhIZy0DPiAA JgB+AwFk8mTZZXmr2WDHQo2cUI8u+ZRuh5mOYSqgBNebOUuFUBA7X/uHuKFwhugg F1QWG2QFF3CljSjZKY27YpSDh6Hf2IGk+RiKfQbVhpBMF9QjlSyXIc6wbceol9y/ 621zjVb5JpNbu7UYslCoUAQkjGFpjPGAtsiqpfPYObTmoA8rSrlbcV0y9+BrXbHV bGFQi1ktqUC5h2Lio5S0PnIRtrGOKhX23dfbUA0VKUJCqXzP+GI= =W4nf -END PGP SIGNATURE-
Re: [strongSwan] 24/7/365 tunnel?
I’ve found auto=route to be much more stable in AWS. Spins up when it’s down but needed and starts passing traffic. EKG > On Sep 14, 2017, at 6:21 AM, Turbo Fredriksson wrote: > > I’ve been playing with: > >type=tunnel >auto=start >dpdaction=restart >dpddelay=2400s > > which never worked. I’ve now changed this to: > >type=tunnel >auto=start >dpdaction=restart >dpddelay=10 >dpdtimeout=60 > > and so far so good. Although I haven’t waited long enough, so I’m > going to let it be for the next few days to see if that works in the long > run. > > Would it help to set ‘auto=route’ instead? Thing is, I need this link to > be started at boot AND be up 24/7/365 - I have a (bunch of) web apps > in London that need access to databases in Ireland to work. > > > I’m considering setting up DBs in London as well, but that will both > cost a small fortune AND replication/updates on the DBs will be > problematic. So I’d prefer a “perfect” link between them... > > >> On 13 Sep 2017, at 20:16, Noel Kuntze >> wrote: >> >> Hi, >> >> DPD just checks if the remote peer is still "there" and reachable. It >> doesn't do anything with the CHILD_SAs. >> It only helps to keep up the IKE_SA and keep it working (e.g. it wouldn't >> work anymore if the NAT mapping on an intermediate NAT router >> would expire). Peers are free to delete CHILD_SAs and IKE_SAs without >> renegotiating new ones, destroying the tunnel. >> >> Use auto=route (swanctl equivalent is start_action=trap), as advised >> previously. >> >> Kind regards >> >> Noel >> >> On 13.09.2017 17:38, Michael Schwartzkopff wrote: >>> Am 13.09.2017 um 17:33 schrieb Eric Germann: Usually if it "takes down the tunnel" it's due to no traffic. Keep interesting traffic going and it will stay up. If you have the ability to set "auto = route" it will reestablish the tunnel as needed. We run several hundred tunnels this way in AWS without issue. EKG > On Sep 13, 2017, at 09:21, Turbo Fredriksson wrote: > > I’m trying to setup a tunnel between two regions in > AWS. > > Works fine, other than the fact that Strongswan seems to take > down the tunnel automatically (?) after a few hours. > > How can I 1) make sure there’s no timeout (?) and 2) that IF > the tunnel goes down, for whatever reason, that it will reinitiate > the connection automatically? > >>> Dead Peer Detection (DPD) sends packets that keep the tunnel up. >>> >>> >>> Michael Schwartzkopff >>> >>> Mit freundlichen Grüßen, >>> >> > signature.asc Description: Message signed with OpenPGP
Re: [strongSwan] 24/7/365 tunnel?
I’ve been playing with: type=tunnel auto=start dpdaction=restart dpddelay=2400s which never worked. I’ve now changed this to: type=tunnel auto=start dpdaction=restart dpddelay=10 dpdtimeout=60 and so far so good. Although I haven’t waited long enough, so I’m going to let it be for the next few days to see if that works in the long run. Would it help to set ‘auto=route’ instead? Thing is, I need this link to be started at boot AND be up 24/7/365 - I have a (bunch of) web apps in London that need access to databases in Ireland to work. I’m considering setting up DBs in London as well, but that will both cost a small fortune AND replication/updates on the DBs will be problematic. So I’d prefer a “perfect” link between them... > On 13 Sep 2017, at 20:16, Noel Kuntze > wrote: > > Hi, > > DPD just checks if the remote peer is still "there" and reachable. It doesn't > do anything with the CHILD_SAs. > It only helps to keep up the IKE_SA and keep it working (e.g. it wouldn't > work anymore if the NAT mapping on an intermediate NAT router > would expire). Peers are free to delete CHILD_SAs and IKE_SAs without > renegotiating new ones, destroying the tunnel. > > Use auto=route (swanctl equivalent is start_action=trap), as advised > previously. > > Kind regards > > Noel > > On 13.09.2017 17:38, Michael Schwartzkopff wrote: >> Am 13.09.2017 um 17:33 schrieb Eric Germann: >>> Usually if it "takes down the tunnel" it's due to no traffic. Keep >>> interesting traffic going and it will stay up. >>> >>> If you have the ability to set "auto = route" it will reestablish the >>> tunnel as needed. We run several hundred tunnels this way in AWS without >>> issue. >>> >>> EKG >>> >>> On Sep 13, 2017, at 09:21, Turbo Fredriksson wrote: I’m trying to setup a tunnel between two regions in AWS. Works fine, other than the fact that Strongswan seems to take down the tunnel automatically (?) after a few hours. How can I 1) make sure there’s no timeout (?) and 2) that IF the tunnel goes down, for whatever reason, that it will reinitiate the connection automatically? >> Dead Peer Detection (DPD) sends packets that keep the tunnel up. >> >> >> Michael Schwartzkopff >> >> Mit freundlichen Grüßen, >> > signature.asc Description: Message signed with OpenPGP
Re: [strongSwan] Strongswan. Address definition/Routing.
Hello, Noel. Thanks for the answer. Unfortunately, there is no way to bypass.As a solution we can use the second white IP for Strongswan, and the web server on the 1st IP. 2017-09-13 22:17 GMT+03:00 Noel Kuntze < noel.kuntze+strongswan-users-ml@thermi.consulting>: > Hi, > > That is because Windows and MacOS implement crappy route based IPsec which > conceptually can not protect traffic to the IKE peer's > address (unless policy based routing is used, which neither Windows nor > MacOS implement). > > Kind regards > > Noel > > On 13.09.2017 17:14, Aleksey Kravchenko wrote: > > Hello.I need your advice. > > The work of Strongswan + IKEv2 is configured. Everything works fine (on > iOS, macOS, windows, linux), but I noticed strange behavior in VPN's work. > There is a server on which Strongswan and Nginx are installed.When you > connect to the VPN and go to the site which is located in the same place as > the strongswan daemon, the nginx log shows different addresses for > connections. For instance:android / linux -> login from the address issued > by the VPN (for example, 192.168.1.2). > > windows / macos -> login from the usual address (provider address). > > But if you go to the IP detection server, the result for all devices is > the same: you logged in from the VPN server.Maybe you have any thoughts > about this? Thank you! > >
Re: [strongSwan] strongswan not picking up traffic
Hi,After I manually bring up the tunnel from the spoke side, it has started working."ipsec up host-host".But is this normal??Regards,TerryOn Sep 13, 2017, at 07:12 PM, Chengcheng Fu wrote:Hi,The GRE tunnel is working on its own, it's like Strongswan is not even aware of it's happening, and not trying to encapsulate it.I must be missing something simple.Below are my configs.= hub-192.168.23.193=# ipsec.conf #config setupconn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 authby=secret mobike=no keyexchange=ikev2conn host-host left=192.168.23.193 leftprotoport=gre rightprotoport=gre type=transport auto=add reauth=no closeaction=clear keyexchange=ikev2 right=%any mark=%unique# strongswan.conf #charon { load_modular = yes plugins { include strongswan.d/charon/*.conf } filelog { /var/log/charon_debug.log { time_format = %a, %Y-%m-%d %R default = 2 mgr = 0 net = 1 enc = 1 asn = 1 job = 1 knl = 1 ike_name = yes append = no flush_line = yes } }}include strongswan.d/*.conf# swanctl.conf #include conf.d/*.conf# ipsec statusall #Status of IKE charon daemon (strongSwan 5.6.0, Linux 4.9.47, x86_64): uptime: 12 minutes, since Sep 14 09:52:04 2017 malloc: sbrk 1081344, mmap 0, used 267712, free 813632 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0 loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown xauth-genericListening IP addresses: 192.168.23.193 192.168.34.1Connections: host-host: 192.168.23.193...%any IKEv2 host-host: local: [192.168.23.193] uses pre-shared key authentication host-host: remote: uses pre-shared key authentication host-host: child: dynamic[gre] === dynamic[gre] TRANSPORTSecurity Associations (0 up, 0 connecting): none# iptables -L -v #Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 25 1876 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- any any anywhere anywhere 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:sshChain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 13 packets, 1332 bytes) pkts bytes target prot opt in out source destination # ip route show table all #default via 192.168.23.232 dev eth0 proto static metric 20 default via 192.168.23.232 dev eth0 proto static metric 100 192.168.23.0/24 dev eth0 proto kernel scope link src 192.168.23.193 metric 100 192.168.34.3 dev gre1 proto kernel scope link src 192.168.34.1 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.23.0 dev eth0 table local proto kernel scope link src 192.168.23.193 local 192.168.23.193 dev eth0 table local proto kernel scope host src 192.168.23.193 broadcast 192.168.23.255 dev eth0 table local proto kernel scope link src 192.168.23.193 local 192.168.34.1 dev gre1 table local proto kernel scope host src 192.168.34.1 unreachable default dev lo proto kernel metric 4294967295 error -101 pref mediumunreachable ::/96 dev lo metric 1024 error -113 pref mediumunreachable :::0.0.0.0/96 dev lo metric 1024 error -113 pref mediumunreachable 2002:a00::/24 dev lo metric 1024 error -113 pref mediumunreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref mediumunreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref mediumunreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref mediumunreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref mediumunreachable 2002:e000::/19 dev lo metric 1024 error -113 pref mediumunreachable 3ffe:::/32 dev lo metric 1024 error -113 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev gre1 proto kernel metric 256 pref mediumunreachable default dev lo proto kernel metric 4294967295 error -101 pref mediumlocal ::1 dev lo table local proto none metric 0 pref mediumlocal fe80:: dev lo table local proto none metric 0 pref mediumlocal fe80:: dev lo table local proto none metric 0 pref mediumlocal fe80::5efe:c0a8:17c1 dev lo table local proto none metric 0 pref mediumlocal fe80::5054:ff:fecb:abeb dev lo table local proto none metric 0 pref mediumff00::/8 dev eth1 table local metric 256 pref mediumff00::/8 dev eth2 table local metric 256 pref mediumff00::/8 dev eth0 table local metric 256 pref mediumff00::/8 dev gre1 table local metric 256 pref mediumunreachable default dev lo proto kernel metric 4294967295 error -101 pref medium# ip