Project

General

Profile

Issue #2788

Passthrough policy not working

Added by Nihat Tanfer almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
configuration
Affected version:
5.6.3
Resolution:
No change required

Description

Hi,

There are some IP addresses I would like to bypass and not tunnel through the VPN. I tunnel all the internet traffic and have to because there is a proxy and dns server doing extra checks after the traffic is tunneled.

Essentially what I want to achieve is not to tunnel streaming from Youtube or Netflix and the best way I thought of doing this isthe Passthrough policy but I couldn't get it to work. I have read https://wiki.strongswan.org/issues/2472 this issue but is no help.

Here is the setup:

lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:    xenial




ipsec --version
Linux strongSwan U5.6.3/K4.4.0-87-generic


# Generated by iptables-save v1.6.0 on Fri Sep 28 16:58:02 2018
*mangle
:PREROUTING ACCEPT [4053395:425322637]
:INPUT ACCEPT [4053309:425318312]
:FORWARD ACCEPT [86:4325]
:OUTPUT ACCEPT [4338860:311661664]
:POSTROUTING ACCEPT [4338903:311663699]
-A FORWARD -s 10.2.0.0/16 -o ens160 -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
COMMIT
# Completed on Fri Sep 28 16:58:02 2018
# Generated by iptables-save v1.6.0 on Fri Sep 28 16:58:02 2018
*nat
:PREROUTING ACCEPT [40815:3297594]
:INPUT ACCEPT [133498:6632831]
:OUTPUT ACCEPT [365510:21963470]
:POSTROUTING ACCEPT [365510:21963470]
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3129
-A POSTROUTING -s 10.2.0.0/16 -o ens160 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 10.2.0.0/16 -o ens160 -j MASQUERADE
COMMIT
# Completed on Fri Sep 28 16:58:02 2018
# Generated by iptables-save v1.6.0 on Fri Sep 28 16:58:02 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4338861:311661752]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3128 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3129 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -s 10.2.0.0/16 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -m policy --dir out --pol ipsec --proto esp -j ACCEPT
-A FORWARD -j DROP
COMMIT
# Completed on Fri Sep 28 16:58:02 2018

and my ipsec.conf

config setup
    uniqueids=no
    charondebug="ike 3, knl 2, cfg 3, tls 2, dmn 2, net 2" 

conn %default
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftsubnet=0.0.0.0/0
#    leftsubnet=35.234.101.161/32
    leftcert=/etc/ipsec.d/certs/vpn-server-cert-v2.pem
    leftsendcert=always
    # leftfirewall=yes
    leftupdown=/etc/ipsec.d/vpn_updown.sh
    rightupdown=/etc/ipsec.d/vpn_updown.sh
    right=%any
    rightdns=172.31.32.90
    fragmentation=yes

conn IPSec-IKEv2
    keyexchange=ikev2
    auto=add
    leftid=x.x.x.x
    leftsendcert=always

# Currently used by Windows and Android
conn IKEv2-EAP
    also="IPSec-IKEv2" 
    rightauth=eap-radius
    rightsourceip=%radius
    rightsendcert=never
    eap_identity=%identity
    leftid=x.x.x.x
    auto=add

conn IPSec-IKEv1
    keyexchange=ikev1
    auto=add
    rightsourceip=%radius

# Currently used by OSX and iOS
conn IKEv1-XAUTHPSK
    also="IPSec-IKEv1" 
    xauth=server
    authby=xauthpsk

# VPN passthrough / tunnel bypass rules
conn passthrough_base
    left=127.0.0.1
#    right=127.0.0.1
    leftsubnet=0.0.0.0/0
    rightsubnet=35.234.101.161/32
    authby=never
    type=passthrough
    auto=route

35.234.101.161 is just for testing... it points to www.ipnedir.com which shows my ip to see if the passthrough policy worked.

Roadwarrior connects to server x.x.x.x and is given 10.2.0.4 virtual IP.

Your help would be much appreciated. Thank you.

History

#1 Updated by Tobias Brunner almost 7 years ago

  • Status changed from New to Feedback

Passthrough policies are something you have to configure locally, i.e. on the client in roadwarrrior scenarios. If that's not possible to configure, IKEv2 narrowing might be an option (i.e. setting leftsubnet on the server in a way that excludes the IPs/subnets you don't want to tunnel). On some clients it's also possible to avoid tunneling certain traffic via routing or firewall/NAT rules.

#2 Updated by Nihat Tanfer almost 7 years ago

Tobias Brunner wrote:

Passthrough policies are something you have to configure locally, i.e. on the client in roadwarrrior scenarios. If that's not possible to configure, IKEv2 narrowing might be an option (i.e. setting leftsubnet on the server in a way that excludes the IPs/subnets you don't want to tunnel). On some clients it's also possible to avoid tunneling certain traffic via routing or firewall/NAT rules.

Hi Tobias, thank you for the prompt reply. The clients are iOS/Android devices and do not have client configs. I'm guessing narrowing would be practically impossible as I would have to enter the whole internet subnets except streaming IP subnets.

I have to do this on the server side. Would you recommend any possible solutions for this dilemma? It would have been excellent to have passthrough policy work in this situtation.

#3 Updated by Tobias Brunner almost 7 years ago

The clients are iOS/Android devices and do not have client configs.

On iOS you don't have many options (using the default client), on Android with our own app you can freely configure subnets/apps that should not go via VPN.

I'm guessing narrowing would be practically impossible as I would have to enter the whole internet subnets except streaming IP subnets.

If you know the subnets that's not that much of a problem, just subtract them from 0.0.0.0/0 (depending on the excluded subnets that might result in a longish list, though). The question is whether the client then adheres to that remote traffic selector (our own app does, not sure about the iOS client).

Would you recommend any possible solutions for this dilemma? It would have been excellent to have passthrough policy work in this situtation.

There are no other solutions. You have to prevent the client from sending you traffic that should not be tunneled (split-tunneling), which you can't do without cooperation by the client (either via configuration or adherence to narrowed traffic selectors).

#4 Updated by Nihat Tanfer almost 7 years ago

Tobias Brunner wrote:

The clients are iOS/Android devices and do not have client configs.

On iOS you don't have many options (using the default client), on Android with our own app you can freely configure subnets/apps that should not go via VPN.

I'm guessing narrowing would be practically impossible as I would have to enter the whole internet subnets except streaming IP subnets.

If you know the subnets that's not that much of a problem, just subtract them from 0.0.0.0/0 (depending on the excluded subnets that might result in a longish list, though). The question is whether the client then adheres to that remote traffic selector (our own app does, not sure about the iOS client).

Would you recommend any possible solutions for this dilemma? It would have been excellent to have passthrough policy work in this situtation.

There are no other solutions. You have to prevent the client from sending you traffic that should not be tunneled (split-tunneling), which you can't do without cooperation by the client (either via configuration or adherence to narrowed traffic selectors).

Thanks again for the comments Tobias, much appreciated.

I have tried changing the leftsubnet on the default conn and it does as expected on iOSand Android, which tunnels only the traffic from the specified IP. So yes narrowing is definitely an option but just for example sake let's say I wanted to make an exception for 35.234.101.0/32 how would I write that into leftsubnet ?

#5 Updated by Tobias Brunner almost 7 years ago

So yes narrowing is definitely an option but just for example sake let's say I wanted to make an exception for 35.234.101.0/32 how would I write that into leftsubnet ?

That results in the following list of 32 subnets to tunnel:

leftsubnet=0.0.0.0/3,32.0.0.0/7,34.0.0.0/8,35.0.0.0/9,35.128.0.0/10,35.192.0.0/11,35.224.0.0/13,35.232.0.0/15,35.234.0.0/18,35.234.64.0/19,35.234.96.0/22,35.234.100.0/24,35.234.101.1/32,35.234.101.2/31,35.234.101.4/30,35.234.101.8/29,35.234.101.16/28,35.234.101.32/27,35.234.101.64/26,35.234.101.128/25,35.234.102.0/23,35.234.104.0/21,35.234.112.0/20,35.234.128.0/17,35.235.0.0/16,35.236.0.0/14,35.240.0.0/12,36.0.0.0/6,40.0.0.0/5,48.0.0.0/4,64.0.0.0/2,128.0.0.0/1

#6 Updated by Nihat Tanfer almost 7 years ago

Tobias Brunner wrote:

So yes narrowing is definitely an option but just for example sake let's say I wanted to make an exception for 35.234.101.0/32 how would I write that into leftsubnet ?

That results in the following list of 32 subnets to tunnel:

[...]

Thanks Tobias, tried and it's working as expected that is great. The downside is it takes a long time for the client to connect to strongswan. Is there a way to speed up that process? and by the way how did you calculate the narrowing so fast?

Thanks

#7 Updated by Tobias Brunner almost 7 years ago

The downside is it takes a long time for the client to connect to strongswan. Is there a way to speed up that process?

Hm, not sure if that's related to the traffic selectors (I guess it makes the IKE_AUTH message a bit larger, though). Check the timestamps in the server log, the message sizes and number of fragments and whether there are any retransmissions.

and by the way how did you calculate the narrowing so fast?

I wrote a Python script a while ago (using the ipaddress module).

#8 Updated by Nihat Tanfer almost 7 years ago

Tobias Brunner wrote:

The downside is it takes a long time for the client to connect to strongswan. Is there a way to speed up that process?

Hm, not sure if that's related to the traffic selectors (I guess it makes the IKE_AUTH message a bit larger, though). Check the timestamps in the server log, the message sizes and number of fragments and whether there are any retransmissions.

and by the way how did you calculate the narrowing so fast?

I wrote a Python script a while ago (using the ipaddress module).

Thanks Tobias. Yes I believe the message gets larger and it dramatically increases the connection time which affects greatly user experience.

For a single subnet this might look like a good idea but after playing around with some IPs (wrote a python script as well), it just isn't feasible to use narrow for a wide range of IPs.

I will look into ip route and iptables for a better performance.

Thank you for all your help. By the way I realized later on that I should have leave out some paths and IP addresses from my copy/paste... can we delete this issue completely?

Thanks again.

#9 Updated by Tobias Brunner almost 7 years ago

Yes I believe the message gets larger and it dramatically increases the connection time which affects greatly user experience.

Don't believe. Actually check logs or traffic captures (message sizes, timestamps etc.).

For a single subnet this might look like a good idea but after playing around with some IPs (wrote a python script as well), it just isn't feasible to use narrow for a wide range of IPs.

Yeah, depends on the ranges you can exclude. If you have lots of single IPs it could result in a long list of subnets (so ideally you can exclude larger subnets and not only single IPs).

I will look into ip route and iptables for a better performance.

That won't help you at all. The client will still send all traffic to the server.

By the way I realized later on that I should have leave out some paths and IP addresses from my copy/paste... can we delete this issue completely?

I'd rather not delete it completely. But you may send me an email with the addresses/paths you want me to remove.

#10 Updated by Tobias Brunner almost 7 years ago

  • Description updated (diff)

#11 Updated by Nihat Tanfer almost 7 years ago

Tobias Brunner wrote:

Yes I believe the message gets larger and it dramatically increases the connection time which affects greatly user experience.

Don't believe. Actually check logs or traffic captures (message sizes, timestamps etc.).

For a single subnet this might look like a good idea but after playing around with some IPs (wrote a python script as well), it just isn't feasible to use narrow for a wide range of IPs.

Yeah, depends on the ranges you can exclude. If you have lots of single IPs it could result in a long list of subnets (so ideally you can exclude larger subnets and not only single IPs).

I will look into ip route and iptables for a better performance.

That won't help you at all. The client will still send all traffic to the server.

By the way I realized later on that I should have leave out some paths and IP addresses from my copy/paste... can we delete this issue completely?

I'd rather not delete it completely. But you may send me an email with the addresses/paths you want me to remove.

Thank you for all your help Tobias. You are a champ!

#12 Updated by Tobias Brunner over 6 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No change required