[strongSwan] separate routes for VPN and Internet traffic: can this form of "split tunneling" be configured in ipsec.conf?
Alan Tu
8libra at gmail.com
Mon Jun 1 21:12:16 CEST 2015
Hi Noel, I have rightsubnet=10.0.0.0/8 and no leftsubnet entry.
Fresh tested from scratch, pristine VM image, downloaded, compiled and
installed Strongswan. ipsec.conf [1] and syslog [2] are below. We have
an out of band two factor authentication mechanism, which I did
successfully authenticate to.
Perhaps this VPN software/appliance vendor implementation isn't
compatible with what I want to do? Or at least the way I'm specifying
it in the client configuration.
Alan
Notes:
[1]
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
esp=aes-sha1
xauth=client
left=%any
leftid=keyid:[redacted]
leftsourceip=%modeconfig
leftauth=psk
rightauth=psk
leftauth2=xauth
right=[redacted]
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
Jun 1 18:53:40 ip-172-31-37-117 charon: 03[CFG] received stroke: initiate 'vpn'
Jun 1 18:53:40 ip-172-31-37-117 charon: 01[IKE] initiating Aggressive
Mode IKE_SA vpn[1] to [VPN_gateway]
Jun 1 18:53:40 ip-172-31-37-117 charon: 01[ENC] generating AGGRESSIVE
request 0 [ SA KE No ID V V V V ]
Jun 1 18:53:40 ip-172-31-37-117 charon: 01[NET] sending packet: from
172.31.36.65[500] to [VPN_gateway][500] (384 bytes)
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[NET] received packet: from
[VPN_gateway][500] to 172.31.36.65[500] (396 bytes)
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] parsed AGGRESSIVE
response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ]
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received XAuth vendor ID
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received NAT-T (RFC
3947) vendor ID
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] received DPD vendor ID
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] received unknown
vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[IKE] local host is behind
NAT, sending keep alives
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[ENC] generating AGGRESSIVE
request 0 [ NAT-D NAT-D HASH ]
Jun 1 18:53:40 ip-172-31-37-117 charon: 10[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
Jun 1 18:53:41 ip-172-31-37-117 charon: 11[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
Jun 1 18:53:41 ip-172-31-37-117 charon: 11[ENC] parsed TRANSACTION
request 783318293 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
Jun 1 18:53:41 ip-172-31-37-117 charon: 11[ENC] generating
TRANSACTION response 783318293 [ HASH CPRP(X_USER X_PWD) ]
Jun 1 18:53:41 ip-172-31-37-117 charon: 11[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] parsed TRANSACTION
request 703099895 [ HASH CPS(X_STATUS) ]
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] XAuth authentication
of 'user' (myself) successful
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] IKE_SA vpn[1]
established between 172.31.36.65[group]...[VPN_gateway][[VPN_gateway]]
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] scheduling
reauthentication in 86220s
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[IKE] maximum IKE_SA lifetime 86400s
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] generating
TRANSACTION response 703099895 [ HASH CPA(X_STATUS) ]
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[ENC] generating
TRANSACTION request 4226299460 [ HASH CPRQ(ADDR DNS) ]
Jun 1 18:53:49 ip-172-31-37-117 charon: 05[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (92 bytes)
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[ENC] parsed TRANSACTION
response 4226299460 [ HASH CPRP(ADDR DNS DNS) ]
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing DNS server
10.100.15.5 via resolvconf
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing DNS server
10.100.24.250 via resolvconf
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[IKE] installing new
virtual IP 10.100.4.5
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[ENC] generating QUICK_MODE
request 675444149 [ HASH SA No ID ID ]
Jun 1 18:53:49 ip-172-31-37-117 charon: 13[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:53:53 ip-172-31-37-117 charon: 02[IKE] sending retransmit 1
of request message ID 675444149, seq 4
Jun 1 18:53:53 ip-172-31-37-117 charon: 02[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:54:01 ip-172-31-37-117 charon: 10[IKE] sending retransmit 2
of request message ID 675444149, seq 4
Jun 1 18:54:01 ip-172-31-37-117 charon: 10[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:54:14 ip-172-31-37-117 charon: 05[IKE] sending retransmit 3
of request message ID 675444149, seq 4
Jun 1 18:54:14 ip-172-31-37-117 charon: 05[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:54:33 ip-172-31-37-117 charon: 15[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:54:37 ip-172-31-37-117 charon: 13[IKE] sending retransmit 4
of request message ID 675444149, seq 4
Jun 1 18:54:37 ip-172-31-37-117 charon: 13[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:54:56 ip-172-31-37-117 charon: 16[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:55:16 ip-172-31-37-117 charon: 02[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:55:19 ip-172-31-37-117 charon: 01[IKE] sending retransmit 5
of request message ID 675444149, seq 4
Jun 1 18:55:19 ip-172-31-37-117 charon: 01[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:55:38 ip-172-31-37-117 charon: 11[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:55:58 ip-172-31-37-117 charon: 12[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:56:18 ip-172-31-37-117 charon: 05[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:56:34 ip-172-31-37-117 charon: 14[KNL] creating delete job
for CHILD_SA ESP/0xc6eb89db/172.31.36.65
Jun 1 18:56:34 ip-172-31-37-117 charon: 14[JOB] CHILD_SA
ESP/0xc6eb89db/172.31.36.65 not found for delete
Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] giving up after 5 retransmits
Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] installing new
virtual IP 10.100.4.5
Jun 1 18:56:34 ip-172-31-37-117 charon: 13[IKE] initiating Aggressive
Mode IKE_SA vpn[2] to [VPN_gateway]
Jun 1 18:56:34 ip-172-31-37-117 charon: 13[ENC] generating AGGRESSIVE
request 0 [ SA KE No ID V V V V ]
Jun 1 18:56:34 ip-172-31-37-117 charon: 13[NET] sending packet: from
172.31.36.65[500] to [VPN_gateway][500] (384 bytes)
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[NET] received packet: from
[VPN_gateway][500] to 172.31.36.65[500] (396 bytes)
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] parsed AGGRESSIVE
response 0 [ SA KE No ID HASH V V NAT-D NAT-D V V ]
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received XAuth vendor ID
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received NAT-T (RFC
3947) vendor ID
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] received DPD vendor ID
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] received unknown
vendor ID: a9:b9:b1:03:4f:7e:50:a2:51:3b:47:b1:00:bb:85:a9
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[IKE] local host is behind
NAT, sending keep alives
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[ENC] generating AGGRESSIVE
request 0 [ NAT-D NAT-D HASH ]
Jun 1 18:56:34 ip-172-31-37-117 charon: 04[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
Jun 1 18:56:35 ip-172-31-37-117 charon: 16[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
Jun 1 18:56:35 ip-172-31-37-117 charon: 16[ENC] parsed TRANSACTION
request 260202080 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
Jun 1 18:56:35 ip-172-31-37-117 charon: 16[ENC] generating
TRANSACTION response 260202080 [ HASH CPRP(X_USER X_PWD) ]
Jun 1 18:56:35 ip-172-31-37-117 charon: 16[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (108 bytes)
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (76 bytes)
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] parsed TRANSACTION
request 1809935207 [ HASH CPS(X_STATUS) ]
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] XAuth authentication
of 'user' (myself) successful
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] IKE_SA vpn[2]
established between 172.31.36.65[group]...[VPN_gateway][[VPN_gateway]]
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] scheduling
reauthentication in 86220s
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[IKE] maximum IKE_SA lifetime 86400s
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] generating
TRANSACTION response 1809935207 [ HASH CPA(X_STATUS) ]
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[ENC] generating
TRANSACTION request 150801322 [ HASH CPRQ(ADDR DNS) ]
Jun 1 18:56:45 ip-172-31-37-117 charon: 10[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (76 bytes)
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[NET] received packet: from
[VPN_gateway][4500] to 172.31.36.65[4500] (92 bytes)
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[ENC] parsed TRANSACTION
response 150801322 [ HASH CPRP(ADDR DNS DNS) ]
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing DNS server
10.100.15.5 via resolvconf
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing DNS server
10.100.24.250 via resolvconf
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[IKE] installing new
virtual IP 10.100.4.2
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[ENC] generating QUICK_MODE
request 1932673650 [ HASH SA No ID ID ]
Jun 1 18:56:45 ip-172-31-37-117 charon: 11[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:56:49 ip-172-31-37-117 charon: 16[IKE] sending retransmit 1
of request message ID 1932673650, seq 4
Jun 1 18:56:49 ip-172-31-37-117 charon: 16[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:56:57 ip-172-31-37-117 charon: 01[IKE] sending retransmit 2
of request message ID 1932673650, seq 4
Jun 1 18:56:57 ip-172-31-37-117 charon: 01[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:57:10 ip-172-31-37-117 charon: 05[IKE] sending retransmit 3
of request message ID 1932673650, seq 4
Jun 1 18:57:10 ip-172-31-37-117 charon: 05[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
Jun 1 18:57:29 ip-172-31-37-117 charon: 15[IKE] sending keep alive to
[VPN_gateway][4500]
Jun 1 18:57:33 ip-172-31-37-117 charon: 03[IKE] sending retransmit 4
of request message ID 1932673650, seq 4
Jun 1 18:57:33 ip-172-31-37-117 charon: 03[NET] sending packet: from
172.31.36.65[4500] to [VPN_gateway][4500] (204 bytes)
On 6/1/15, Noel Kuntze <noel at familie-kuntze.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello Alan,
>
> I can't figure out your problem, because your description does not fit
> the current state of your ipsec.conf. Did you delete leftsubnet=10.0.0.0/8
> before changing rightsubnet to 10.0.0.0/8?
>
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 01.06.2015 um 01:45 schrieb Alan Tu:
>> Hi Noel, I fixed the ike and esp lines in ipsec.conf [1]. Specifying
>> rightsubnet=10.0.0.0/8, I think that was the suggestion, failed to
>> bring up the VPN tunnel. Changing that one line from
>> rightsubnet=10.0.0.0/8 (the line, I think, makes sense to you and me)
>> to rightsubnet=0.0.0.0/0 brought up the VPN where all traffic is
>> tunneled over.
>>
>> I'll pass the PSK comment on (I agree), I don't run the other end. In
>> fact its vendor software, said vendor has released a Strongswan
>> configuration on their website with the typo you mentioned.
>>
>> Alan
>>
>> [1]
>> 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
>> esp=aes-sha1
>> xauth=client
>> left=%any
>> leftid=keyid:[redacted]
>> leftsourceip=%modeconfig
>> leftauth=psk
>> rightauth=psk
>> leftauth2=xauth
>> right=[redacted]
>> 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
>>
>>
>> On 5/31/15, Noel Kuntze <noel at familie-kuntze.de> wrote:
>>>
>> 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
>
> iQIcBAEBCAAGBQJVbGTNAAoJEDg5KY9j7GZYng0P/iL+FOGj86FjOKjw6Yxgeq2Q
> Ean1kRkNtU63Ysn+G7npRytMdQDCTGaeigjCxISHv6bnvbyT8aurS9MFIaOdFWr7
> FGw29fZvAEDOWyZIaFfxQiau/tsb7kRdisrFUG/1XqG3qnXuSzxH6bgIXeor3+Yy
> cLvH96ALCWIrMH+ObK/ElweXc6IPBruo6w0T93CsR3rBQU1ZbYL0FasSDdmjL9pj
> 2tspUTzjRKOGH32LY8jShyGDrEjY4iZZjih1hPW/XTcA6Q/DZiWGciw8+RUNNOHh
> KXvCaA515+nm7jilYTKMBW33bFcDm6KzFDZO6k/X1q3r5gjv/p/eK0jMvXYFDdMk
> lHcU8oQtwqPIr204AbPia1cpQrhz7LIZYzlO33FsRIvB/w1/PTxh2jrT1SeGnow3
> 8q+GStAzVpPDOlKXPg7m8UlY71JuqFSrbGMHzs2o3p4jGuOyInxRpr4hAUjFjU6J
> hkcwictY1CdEajle1x/U1k284ZzQmQRLuYGufMDg2UzBT202PbO88OVz2TC+ZxEL
> tcg+38VLfF65Oplqjv9kyy5S5RPYXZGfpnuoXPR+LYW+/Sp5k6PSSxGV2WvKqs+C
> JrpPM5BzrsxA3FJWdAhFYMy0JMgQXNFPjUq/09ZMbllVvcH50jBzBJTHrEVDlGx7
> Q644v6cRgI94O60CUm7f
> =4yG/
> -----END PGP SIGNATURE-----
>
>
More information about the Users
mailing list