[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 01:45:50 CEST 2015
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:
>
> -----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