-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Alan,
Your configuration makes no sense. You request configuration options (dns servers, IP address) from the remote peer, but you then you override the sensical traffic selector of $virtualIP == 10.0.0.0/8 with a nonsensical traffic selector of 10.0.0.0/8 == 10.0.0.0/8. Remove leftsubnet and I figure it will work. Furthermore, your configuration for the IKE and ESP ciphers is wrong. Read the man page for ipsec.conf for a correct format of those lines. Furthermore, IKev1 in aggressive mode with PSK authentication is a horrible idea, as it allows an attacker to perform an offline dictionary attack on the PSK! You are strongly encouraged to switch to a safer combination. Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 31.05.2015 um 23:39 schrieb Alan Tu: > Noel, Starting from a working tunnel, the only remaining issue was to > not send Internet packets to the VPN. You state I need to write > passthrough connections for all combinations of IP addresses that I > don't want to route to the VPN. Those combinations are literally > everything, except destination 10/8. I would rather write the one > combination that I do want to route to the VPN. > > I just don't know how to do that, besides modifying routing table 220. > I said I tried different combinations of leftsubnet and rightsubnet. > Eventually the daemon reports > establishing connection 'vpn' failed > > Here is my ipsec.conf file [1], basically I specify leftsubnet and > rightsubnet to be the VPN subnet, 10/8. This version of ipsec.conf > fails, here are the syslog messages [2]. > > Alan > > [1] ipsec.conf > conn %default > ikelifetime=20 > reauth=yes > rekey=yes > keylife=10m > rekeymargin=3m > rekeyfuzz=0% > keyingtries=1 > type=tunnel > > conn vpn > keyexchange=ikev1 > ikelifetime=1440m > keylife=60m > aggressive=yes > ike=aes-sha1-modp1024,aes256 > esp=aes-sha1 > xauth=client > left=%any > leftid=keyid:[redacted] > leftsourceip=%modeconfig > leftauth=psk > rightauth=psk > leftauth2=xauth > right=[redacted gateway public IP] > leftsubnet=10.0.0.0/8 > rightsubnet=10.0.0.0/8 > xauth_identity=[redacted] > auto=add > > conn lan > leftsubnet=172.31.0.0/16 > rightsubnet=172.31.0.0/16 > authby=never > type=passthrough > auto=route > > [2] syslog: > May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] received stroke: add > connection 'corporate' > May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] left nor right host > is our side, assuming left=local > May 31 20:46:24 ip-172-31-37-117 charon: 10[CFG] added configuration > 'corporate' > May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] received stroke: add > connection 'lan' > May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] left nor right host > is our side, assuming left=local > May 31 20:46:24 ip-172-31-37-117 charon: 05[CFG] added configuration 'lan' > May 31 20:46:24 ip-172-31-37-117 charon: 13[CFG] received stroke: route 'lan' > May 31 20:46:30 ip-172-31-37-117 cloud-init[964]: Starting strongSwan > 5.3.0 IPsec [starter]... > May 31 20:51:10 ip-172-31-37-117 charon: 04[CFG] received stroke: > initiate 'corporate' > May 31 20:51:10 ip-172-31-37-117 charon: 03[IKE] initiating Aggressive > Mode IKE_SA corporate[1] to [VPN public gateway] > May 31 20:51:10 ip-172-31-37-117 charon: 03[ENC] generating AGGRESSIVE > request 0 [ SA KE No ID V V V V ] > May 31 20:51:10 ip-172-31-37-117 charon: 03[NET] sending packet: from > 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] received packet: from > [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] parsed AGGRESSIVE > response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received XAuth vendor ID > May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received NAT-T (RFC > 3947) vendor ID > May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] received DPD vendor ID > May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] received unknown > vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > May 31 20:51:10 ip-172-31-37-117 charon: 02[IKE] local host is behind > NAT, sending keep alives > May 31 20:51:10 ip-172-31-37-117 charon: 02[ENC] generating AGGRESSIVE > request 0 [ NAT-D NAT-D HASH ] > May 31 20:51:10 ip-172-31-37-117 charon: 02[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] received packet: from > [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] parsed TRANSACTION > request 1621027542 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > May 31 20:51:11 ip-172-31-37-117 charon: 01[ENC] generating > TRANSACTION response 1621027542 [ HASH CPRP(X_USER X_PWD) ] > May 31 20:51:11 ip-172-31-37-117 charon: 01[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] received packet: from > [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] parsed TRANSACTION > request 582705483 [ HASH CPS(X_STATUS) ] > May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] XAuth authentication > of 'user' (myself) successful > May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] IKE_SA corporate[1] > established between 172.31.50.238[cs-users]...[VPN public > gateway][[VPN public gateway]] > May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] scheduling > reauthentication in 86220s > May 31 20:51:19 ip-172-31-37-117 charon: 10[IKE] maximum IKE_SA lifetime > 86400s > May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > TRANSACTION response 582705483 [ HASH CPA(X_STATUS) ] > May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > May 31 20:51:19 ip-172-31-37-117 charon: 10[ENC] generating > TRANSACTION request 1981149928 [ HASH CPRQ(ADDR DNS) ] > May 31 20:51:19 ip-172-31-37-117 charon: 10[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (76 bytes) > May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] received packet: from > [VPN public gateway][4500] to 172.31.50.238[4500] (92 bytes) > May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] parsed TRANSACTION > response 1981149928 [ HASH CPRP(ADDR DNS DNS) ] > May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS server > 10.100.15.5 via resolvconf > May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing DNS server > 10.100.24.250 via resolvconf > May 31 20:51:19 ip-172-31-37-117 charon: 12[IKE] installing new > virtual IP 10.100.4.69 > May 31 20:51:19 ip-172-31-37-117 charon: 12[ENC] generating QUICK_MODE > request 2857000903 [ HASH SA No ID ID ] > May 31 20:51:19 ip-172-31-37-117 charon: 12[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:51:23 ip-172-31-37-117 charon: 16[IKE] sending retransmit 1 > of request message ID 2857000903, seq 4 > May 31 20:51:23 ip-172-31-37-117 charon: 16[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:51:30 ip-172-31-37-117 charon: 03[IKE] sending retransmit 2 > of request message ID 2857000903, seq 4 > May 31 20:51:30 ip-172-31-37-117 charon: 03[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:51:43 ip-172-31-37-117 charon: 11[IKE] sending retransmit 3 > of request message ID 2857000903, seq 4 > May 31 20:51:43 ip-172-31-37-117 charon: 11[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:52:03 ip-172-31-37-117 charon: 05[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:52:07 ip-172-31-37-117 charon: 14[IKE] sending retransmit 4 > of request message ID 2857000903, seq 4 > May 31 20:52:07 ip-172-31-37-117 charon: 14[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:52:26 ip-172-31-37-117 charon: 13[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:52:46 ip-172-31-37-117 charon: 15[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:52:49 ip-172-31-37-117 charon: 16[IKE] sending retransmit 5 > of request message ID 2857000903, seq 4 > May 31 20:52:49 ip-172-31-37-117 charon: 16[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (204 bytes) > May 31 20:53:08 ip-172-31-37-117 charon: 02[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:53:28 ip-172-31-37-117 charon: 01[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:53:48 ip-172-31-37-117 charon: 11[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:54:04 ip-172-31-37-117 charon: 10[KNL] creating delete job > for CHILD_SA ESP/0xcf4ca247/172.31.50.238 > May 31 20:54:04 ip-172-31-37-117 charon: 10[JOB] CHILD_SA > ESP/0xcf4ca247/172.31.50.238 not found for delete > May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] giving up after 5 retransmits > May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] installing new > virtual IP 10.100.4.69 > May 31 20:54:04 ip-172-31-37-117 charon: 14[IKE] initiating Aggressive > Mode IKE_SA corporate[2] to [VPN public gateway] > May 31 20:54:04 ip-172-31-37-117 charon: 14[ENC] generating AGGRESSIVE > request 0 [ SA KE No ID V V V V ] > May 31 20:54:04 ip-172-31-37-117 charon: 14[NET] sending packet: from > 172.31.50.238[500] to [VPN public gateway][500] (416 bytes) > May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] received packet: from > [VPN public gateway][500] to 172.31.50.238[500] (396 bytes) > May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] parsed AGGRESSIVE > response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ] > May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received XAuth vendor ID > May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received NAT-T (RFC > 3947) vendor ID > May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] received DPD vendor ID > May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] received unknown > vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9 > May 31 20:54:04 ip-172-31-37-117 charon: 12[IKE] local host is behind > NAT, sending keep alives > May 31 20:54:04 ip-172-31-37-117 charon: 12[ENC] generating AGGRESSIVE > request 0 [ NAT-D NAT-D HASH ] > May 31 20:54:04 ip-172-31-37-117 charon: 12[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] received packet: from > [VPN public gateway][4500] to 172.31.50.238[4500] (76 bytes) > May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] parsed TRANSACTION > request 2330652074 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] > May 31 20:54:05 ip-172-31-37-117 charon: 13[ENC] generating > TRANSACTION response 2330652074 [ HASH CPRP(X_USER X_PWD) ] > May 31 20:54:05 ip-172-31-37-117 charon: 13[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (108 bytes) > May 31 20:54:28 ip-172-31-37-117 charon: 02[IKE] sending keep alive to > [VPN public gateway][4500] > May 31 20:54:34 ip-172-31-37-117 charon: 01[JOB] peer did not initiate > expected exchange, reestablishing IKE_SA > May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] reinitiating IKE_SA > corporate[2] > May 31 20:54:34 ip-172-31-37-117 charon: 01[IKE] initiating Aggressive > Mode IKE_SA corporate[2] to [VPN public gateway] > May 31 20:54:34 ip-172-31-37-117 charon: 01[ENC] generating AGGRESSIVE > request 0 [ SA KE No ID V V V V ] > May 31 20:54:34 ip-172-31-37-117 charon: 01[NET] sending packet: from > 172.31.50.238[4500] to [VPN public gateway][4500] (416 bytes) > > > On 5/31/15, Noel Kuntze <[email protected]> wrote: >> > Hello Alan, > > You need to write a passthrough/bypass > policy for all source and destination combinations > which should not get handled by IPsec. > Might that be non-LAN traffic, but traffic to google, or any other > traffic. > > "tunnel doesn't come up" is a very generic error. > What error did you encounter? > What is your complete ipsec.conf? > Also, you always need to specify leftsubnet and rightsubnet in a > passthrough/bypass policy! > > Mit freundlichen Grüßen/Kind Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > Am 31.05.2015 um 20:59 schrieb Alan Tu: > >>> Hi Noel, I'm trying really hard to learn, please bare with me. > >>> Specifying passthrough for the local network does work, I solved that > >>> problem thanks to your tip. My question is about non-LAN, non-VPN > >>> traffic going to the Internet, such as to Google. The examples don't > >>> seem to cover this, and in fact the Strongswan split tunneling page > >>> states IKE v1 support for specifying one's subnets is, basically, hit > >>> or miss. Nevertheless I do try to learn from the configurations. > >>> > >>> Is the idea to use some combination of leftsubnet and rightsubnet in > >>> ipsec.conf? Or, is the idea to modify the XFRM policy (or state) > >>> tables? If the former, I have in fact tried several combinations, none > >>> work [1]. > >>> > >>> To abbreviate, I'm setting aside the XFRM policies related to local > >>> LAN passthrough. They work. > >>> # ip xfrm policy show > >>> # Policy 1 > >>> src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32 > >>> dir fwd priority 2947 > >>> tmpl src [public_VPN_gateway] dst [LAN_IP] > >>> proto esp reqid 1 mode tunnel > >>> > >>> # Policy 2 > >>> src 0.0.0.0/0 dst [VPN_virtual_private_IP]/32 > >>> dir in priority 2947 > >>> tmpl src [public_VPN_gateway] dst [LAN_IP] > >>> proto esp reqid 1 mode tunnel > >>> > >>> # Policy 3 > >>> src [VPN_virtual_private_IP]/32 dst 0.0.0.0/0 > >>> dir out priority 2947 > >>> tmpl src [LAN_IP] dst [public_VPN_gateway] > >>> proto esp reqid 1 mode tunnel > >>> > >>> Let me focus on policy 3. I think it says any traffic starting with my > >>> VPN private IP (in the 10/8 net), going to anywhere, re-assign it to > >>> the ipsec tunnel with my physical LAN IP and the VPN gateway Internet > >>> IP as the endpoint. This makes sense. > >>> > >>> But if I claim that as it stands, all the local -> Internet traffic is > >>> going through the VPN, the only way I can explain that is if the local > >>> -> Internet traffic was already rewritten to source from the VPN > >>> virtual address. That's the only way I can see the local -> Internet > >>> traffic hitting this policy. > >>> > >>> If that is the case, would not the routing table modification be > >>> better, to prevent this "rewriting", to avoid hitting this tunnel > >>> policy? > >>> > >>> What I think you are telling me is to rewrite XFRM policy 3 so that it > >>> reads something like: > >>> src [VPN_virtual_private_IP]/32 dst [VPN_subnet]/8 > >>> dir out priority 2947 > >>> tmpl src [LAN_IP] dst [public_VPN_gateway] > >>> proto esp reqid 1 mode tunnel > >>> > >>> Is that right? > >>> > >>> Alan > >>> > >>> Note: > >>> [1] Combinations attempted: > >>> leftsubnet not specified > >>> rightsubnet=0.0.0.0/0 > >>> Result: connection works, but Internet traffic is routed through the VPN > >>> gateway > >>> > >>> leftsubnet not specified > >>> rightsubnet=10.0.0.0/8 > >>> Result: tunnel doesn't come up > >>> > >>> leftsubnet=10.0.0.0/8 > >>> rightsubnet=10.0.0.0/8 > >>> Result: tunnel doesn't come up > >>> > >>> leftsubnet=172.31.0.0/16 > >>> rightsubnet=10.0.0.0/8 > >>> Result: tunnel doesn't come up > >>> > >>> > >>> On 5/31/15, Noel Kuntze <[email protected]> wrote: > >>>> > >>> Hello Alan, > >>> > >>> IPsec on Linux nowadays is policy based, not route based. > >>> You need to write bypass/passthrough policies that define what > >>> traffic should not be subject to IPsec processing > >>> > >>> Look at the test scenarios[1][2] for that to get an idea on > >>> how to define it. > >>> > >>> [1]https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html > >>> [2]https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html > >>> > >>> > >>> Mit freundlichen Grüßen/Kind Regards, > >>> Noel Kuntze > >>> > >>> GPG Key ID: 0x63EC6658 > >>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > >>> > >>> Am 31.05.2015 um 17:08 schrieb Alan Tu: > >>>>>> Hello, I'm still new to ipsec VPNs and Strongswan, and I'd like to > >>>>>> run > >>>>>> the scenario by the group, with potentially a feature suggestion. > >>>>>> > >>>>>> I'm trying to implement what seems to be called split tunneling, > >>>>>> without the cooperation or configuration of the remote VPN gateway. > >>>>>> > >>>>>> I'm a road warrior connecting to a VPN over the Internet, with the > >>>>>> following pertinent configuration settings: > >>>>>> conn vpn > >>>>>> type=tunnel > >>>>>> keyexchange=ikev1 > >>>>>> aggressive=yes > >>>>>> left=%any > >>>>>> leftsourceip=%modeconfig > >>>>>> right=[public IP VPN gateway] > >>>>>> rightsubnet=0.0.0.0/0 > >>>>>> > >>>>>> Other users using proprietary VPN clients or VPNC still have their > >>>>>> non-VPN-LAN traffic (browsing, etc) routed over the users' local WAN, > >>>>>> but I noticed all of my Internet traffic was going through the VPN. > >>>>>> According to the Strongswan split tunneling page [1], IKE v1 doesn't > >>>>>> easily support split tunneling. But after reading and thinking, I > >>>>>> realized altering the routing table might achieve the effect I want. > >>>>>> > >>>>>> Post-VPN routing table 220: > >>>>>> $ ip route show table 220 > >>>>>> default via [WAN gateway IP] dev eth0 proto static src [VPN virtual > >>>>>> private IP] > >>>>>> > >>>>>> So I did: > >>>>>> # ip route add table 220 [VPN subnet] via [WAN gateway IP] dev eth0 > >>>>>> proto static src [VPN virtual private IP] > >>>>>> > >>>>>> This told the kernel, I hoped, to direct traffic going to the VPN > >>>>>> subnet to the ipsec tunnel. XFRM policies and states would then take > >>>>>> over. > >>>>>> > >>>>>> Next, I wanted to change the default route so that non-VPN traffic > >>>>>> would go through the local WAN/Internet connection: > >>>>>> # ip route change table 220 default via [WAN gateway IP] src > >>>>>> [original > >>>>>> eth0 IP] > >>>>>> > >>>>>> And so far, things seem to work the way I intend. I can still access > >>>>>> the VPN subnet, but connections going to the Internet originate from > >>>>>> my original network connection's address. > >>>>>> > >>>>>> Am I missing anything? And if this is a valid scenario, is there any > >>>>>> way I can set this up more intuitively in ipsec.conf? And if not, I'm > >>>>>> wondering if it might be beneficial to have the capability to > >>>>>> configure a connection like this in ipsec.conf. Most of the variables > >>>>>> are more easily available to the Strongswan daemon when a connection > >>>>>> is brought up, and it would seemingly give users an easy way to > >>>>>> configure a form of "split tunneling". > >>>>>> > >>>>>> Alan > >>>>>> > >>>>>> Note: > >>>>>> [1] > >>>>>> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling > >>>>>> _______________________________________________ > >>>>>> Users mailing list > >>>>>> [email protected] > >>>>>> https://lists.strongswan.org/mailman/listinfo/users > >>> > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> [email protected] > >>>> https://lists.strongswan.org/mailman/listinfo/users > >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVa4FrAAoJEDg5KY9j7GZY3kwP/i6Dtzodx5/bQbLEOsrhEPE2 yidOwCcxXao4AX92K+L0rg/PxqlGUid4i7HoVispa7aIKBRzkkjZg4RgFZ08xh32 Ef3MnMekwQu5jPmmmP3B0YhDVursdibz1BJtgO8pJbKJh3Hpd0eLw32E7Hx2BUWL QFvnub4bPaMEGBY8bUnpFLXdjWegnn+UUDbhPmqALQguYMav+9iOzkCMTU1S3p79 juXFfrRHiyvnEvXRbwnBbyWRy7fnT37ul/oD7AcrRZWpCp//QlZz96g2F5DxtIEl pKfMWY8xfvLQZzCRZNdhh7Pk/8CsKXa346eyaswTPXzM4yzuNJ0O6QyXms+pnv39 Jrl8YkXeW8hOnhUp8c2s2B2hFeVppPr4S8iLmmr5qHUZOHK4wJByiCj3ljHXDlvs 6nznq/Z0rfAPJRTDZLrU/Vslt48IsJv28SRDt1swwxwgQ1GwruRmzQ+gj+cQFqDe qp0Nd/aSya9/ymR5HApcO+/dTyYpfgDpD7rb7b4KIQOBqM+CVrJ7Ltb+zCtJc36/ PdBH/48z9S4MU6+NAJ3Egd9SFUowJSItVvwdp6a4Ks6xzn67FpPsH4oVLfD3fMP8 6LZen7W9DfPh7F1bt4aD3CZT4n28+l+UG8+TESUr5LUW8F+Sd5LI3ZsLacoWvGho Has49Bx8pyx57umGdNAg =fVgb -----END PGP SIGNATURE----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
