[strongSwan] separate routes for VPN and Internet traffic: can this form of "split tunneling" be configured in ipsec.conf?
Noel Kuntze
noel at familie-kuntze.de
Sun May 31 23:47:33 CEST 2015
-----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 <noel at familie-kuntze.de> 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 <noel at familie-kuntze.de> 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
> >>>>>> Users at lists.strongswan.org
> >>>>>> https://lists.strongswan.org/mailman/listinfo/users
> >>>
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at lists.strongswan.org
> >>>> 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-----
More information about the Users
mailing list