Enabling split tunneling

[Jim Mueller]

Hello,

We currently have a large number of remote offices (roughly 130) using GRE over IPSEC VPN. The remote offices use local broadband as their internet connection. We've also always used some sort of central proxy (either on our internal network, or most recently in the cloud) for web filtering and reporting.

As we move more items to the cloud, the remote staff are finding that the additional latency of us routing all internet traffic across that tunnel is frustratingly slow due to the additional latency. Is it possible to put something in the remote router config which says, route all private traffic across the tunnel, and route all public traffic directly out to the internet? If yes, is there a way to route all public web traffic to a web filtering service provider? I can provide a redacted sample config for review.

Thanks,

Jim

[Richard Burts]

Jim

You have asked two questions. With no understanding of how your VPNs are configured and implemented it is difficult to give good answers. So a sample config would be quite helpful.

To answer your first question and based on generalities I would say that it is usually quite possible to configure the remote site such that it forwards "private" address traffic through the tunnel (and therefore encrypted) and forwards "public" addresses directly to the Internet.

The answer to your second question about whether it is possible to route public web traffic to a web filtering service provider is more difficult and is very much dependent on what you are doing at the remote sites, on what equipment is used at the remote sites, and on the web filtering service provider.

HTH

Rick

[Jim Mueller]

Hi Richard & Rahul,

Below is a redacted config of a production router at one of these remote offices.

!

version 15.4

no service pad

service tcp-keepalives-in

service timestamps debug datetime msec localtime show-timezone

service timestamps log datetime msec localtime show-timezone

service password-encryption

service compress-config

!

hostname *

!

boot-start-marker

boot system flash c800-universalk9-mz.SPA.154-3.M5.bin

boot-end-marker

!

aqm-register-fnf

!

logging buffered 24576

logging console critical

!

no aaa new-model

clock timezone EST -5 0

clock summer-time EDT recurring

!

ip flow-cache timeout active 1

no ip bootp server

no ip domain lookup

ip domain name *

ip cef

no ipv6 cef

!

flow exporter NTAexp

destination 192.168.0.26

source Vlan1

transport udp 2055

template data timeout 60

option application-table timeout 60

option application-attributes timeout 300

!

flow record NTArec

match ipv4 tos

match ipv4 protocol

match ipv4 source address

match ipv4 destination address

match transport source-port

match transport destination-port

match interface input

collect interface output

collect counter bytes

collect counter packets

collect application name

!

flow monitor NTAmon

description NetFlow nbar

exporter NTAexp

cache timeout inactive 10

cache timeout active 5

record NTArec

!

multilink bundle-name authenticated

!

cts logging verbose

license udi pid C891F-K9 sn *

!

vtp mode transparent

!

vlan 999

name GUEST

no cdp run

!

crypto isakmp policy 5

encr aes 256

authentication pre-share

group 5

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 5

crypto isakmp key * address 0.0.0.0

crypto isakmp keepalive 600

!

crypto ipsec transform-set esp-3des-sha-trans esp-3des esp-sha-hmac

mode transport

no crypto ipsec nat-transparency udp-encapsulation

!

crypto ipsec profile DMVPN

set transform-set esp-3des-sha-trans

set pfs group5

!

interface Loopback0

ip address 10.1.1.2 255.255.255.255

!

interface Tunnel1

description 2350 primary tunnel

bandwidth 1536

ip address 172.18.1.12 255.255.252.0

no ip redirects

ip mtu 1400

ip nhrp authentication *

ip nhrp map 172.18.0.1 *

ip nhrp map multicast *

ip nhrp network-id 1

ip nhrp holdtime 300

ip nhrp nhs 172.18.0.1

ip tcp adjust-mss 1360

ip policy route-map df-bit-clear

qos pre-classify

tunnel source FastEthernet0

tunnel mode gre multipoint

tunnel key 1

tunnel path-mtu-discovery

tunnel protection ipsec profile DMVPN shared

!

interface Tunnel2

description 2350 secondary tunnel

bandwidth 768

ip address 172.18.5.12 255.255.252.0

no ip redirects

ip mtu 1400

ip nbar protocol-discovery

ip flow ingress

ip nhrp authentication *

ip nhrp map 172.18.4.1 *

ip nhrp map multicast *

ip nhrp network-id 2

ip nhrp holdtime 300

ip nhrp nhs 172.18.4.1

ip tcp adjust-mss 1360

ip policy route-map df-bit-clear

qos pre-classify

tunnel source FastEthernet0

tunnel mode gre multipoint

tunnel key 2

tunnel path-mtu-discovery

tunnel protection ipsec profile DMVPN shared

!

interface BRI0

no ip address

encapsulation hdlc

shutdown

isdn termination multidrop

!

interface FastEthernet0

description 2350 WAN interface

bandwidth 51200

bandwidth receive 332800

ip address * 255.255.255.248

ip access-group internet-in-v2 in

ip nbar protocol-discovery

ip flow ingress

ip virtual-reassembly in

ip tcp adjust-mss 1360

duplex auto

speed auto

no cdp enable

!

interface GigabitEthernet0

no ip address

no cdp enable

!

interface GigabitEthernet1

no ip address

no cdp enable

!

interface GigabitEthernet2

no ip address

no cdp enable

!

interface GigabitEthernet3

no ip address

no cdp enable

!

interface GigabitEthernet4

no ip address

no cdp enable

!

interface GigabitEthernet5

no ip address

no cdp enable

!

interface GigabitEthernet6

no ip address

no cdp enable

!

interface GigabitEthernet7

no ip address

no cdp enable

!

interface GigabitEthernet8

no ip address

shutdown

duplex auto

speed auto

!

interface Vlan1

description 2350 LAN gateway

ip address 10.23.50.1 255.255.255.0

ip helper-address 192.168.0.12

no ip redirects

ip nbar protocol-discovery

ip flow monitor NTAmon input

ip flow monitor NTAmon output

ip flow ingress

ip virtual-reassembly in

ip tcp adjust-mss 1360

ip policy route-map df-bit-clear

!

interface Async1

no ip address

encapsulation slip

async mode interactive

!

interface Async3

no ip address

encapsulation slip

!

router eigrp 111

network 10.23.50.0 0.0.0.255

network 172.18.0.0

passive-interface default

no passive-interface Tunnel1

no passive-interface Tunnel2

eigrp stub connected

!

ip forward-protocol nd

no ip http server

ip http authentication local

no ip http secure-server

!

ip flow-export source Vlan1

ip flow-export version 9 peer-as

ip flow-export destination 192.168.0.105 2055

!

ip route 0.0.0.0 0.0.0.0 *

!

ip access-list standard ssh-in

permit * 0.0.0.15

permit * 0.0.0.255

deny any log

ip access-list standard telnet-in

permit 172.18.4.1

permit 172.18.0.1

permit 172.16.13.0 0.0.0.15

permit 192.168.0.0 0.0.0.255

permit 172.16.22.0 0.0.0.255

permit 172.16.26.0 0.0.0.255

permit 172.16.28.0 0.0.0.255

permit 10.23.50.0 0.0.0.255

deny any log

!

ip access-list extended internet-in-v2

permit esp any host *

permit udp any eq isakmp host * eq isakmp

permit icmp any host * echo

permit icmp any host * echo-reply

permit tcp any host * eq 22

permit udp host * host * eq ntp

permit udp host * host * eq ntp

deny ip any any log

!

route-map df-bit-clear permit 10

set ip df 0

!

snmp-server group * v3 priv access 10

snmp-server community * RO 10

snmp-server community * RW 10

snmp-server ifindex persist

snmp-server tftp-server-list 15

snmp-server location *

snmp-server contact *

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server enable traps tty

snmp-server enable traps flash insertion

snmp-server enable traps flash removal

snmp-server enable traps cnpd

snmp-server enable traps config

snmp-server enable traps syslog

snmp-server enable traps ike policy add

snmp-server enable traps ike policy delete

snmp-server enable traps ike tunnel start

snmp-server enable traps ike tunnel stop

snmp-server enable traps ipsec cryptomap add

snmp-server enable traps ipsec cryptomap delete

snmp-server enable traps ipsec cryptomap attach

snmp-server enable traps ipsec cryptomap detach

snmp-server enable traps ipsec tunnel start

snmp-server enable traps ipsec tunnel stop

snmp-server enable traps ipsec too-many-sas

snmp-server file-transfer access-group 15 protocol tftp

access-list 10 permit 192.168.0.105

access-list 10 permit 192.168.0.26

access-list 10 permit 172.16.26.0 0.0.0.255

access-list 10 deny any

access-list 15 permit 192.168.0.5

access-list 15 deny any

!

control-plane

!

mgcp behavior rsip-range tgcp-only

mgcp behavior comedia-role none

mgcp behavior comedia-check-media-src disable

mgcp behavior comedia-sdp-force disable

!

mgcp profile default

!

privilege exec level 15 connect

privilege exec level 15 telnet

privilege exec level 15 rlogin

privilege exec level 15 show access-lists

privilege exec level 15 show ip access-lists

privilege exec level 1 show ip

privilege exec level 15 show logging

privilege exec level 1 show

privilege exec level 10 debug

privilege exec level 2 clear line

privilege exec level 2 clear

!

line con 0

login local

no modem enable

line aux 0

login local

modem InOut

modem autoconfigure discovery

transport input all

autoselect ppp

stopbits 1

speed 57600

flowcontrol hardware

line 3

modem InOut

speed 115200

flowcontrol hardware

line vty 0 4

access-class telnet-in in

privilege level 15

login local

transport input telnet

line vty 5 15

access-class ssh-in in

privilege level 15

login local

transport input ssh

!

scheduler allocate 20000 1000

ntp update-calendar

ntp server *

ntp server *

!

end

　

[Richard Burts]

Jim

Thanks for posting the redacted config. It does make clear some things including that you are using a Cisco 800 series router, that you are running DMVPN with dual tunnels, that you are running EIGRP over the tunnels, that the remote router is operating as EIGRP stub, that you are advertising the subnet of the LAN and of the tunnels to HQ, and that a static default route is configured. That is helpful to know. There are some things it would help to know which are not part of the config. In particular it would be good to know what is being advertised to the remote from the HQ. It is not clear what is used as the next hop in the configured default route and so we do not know whether the default route is pointing up the tunnel(s) or is pointing to the outside interface.

Given this additional information I am fairly confident that it should be possible to make changes so that the remote router does split tunnel, sending only the private address traffic through the DMVPN and sending public traffic directly to the ISP.

We would need more information about the web filtering service provider and what they suggest about forwarding public web traffic to them before we could offer much opinion about how feasible that would be for your remote sites.

HTH

Rick

[Jim Mueller]

I've attached redacted configs of both remote VPN routers at HQ. Regarding the web filtering service, we are currently using the Symantec Web Security Services cloud product.

[Richard Burts]

Jim

Thanks for posting the configs from the head end. They provide some interesting information such as you appear to be running BGP with Sprint and redistributing routes into EIGRP. So it looks like your EIGRP from the head end would be advertising both external/public routes as well as internal/private routes. But with the redaction we can not tell how many or what kind of routes in each category. And we can not tell whether EIGRP is advertising a default route to the remotes.

I do not see anything in the added information that changes my opinion that it should be quite feasible to make changes to implement split tunneling at remote sites such that the remote sends only private address destinations to the head end using the tunnels and forwards public destination addresses directly to the ISP.

If you do decide to go in this direction I would suggest several things that you need to think about and to plan for. 1) If you are going to send traffic directly to the Internet you will need to configure address translation. Will dynamic address translation be sufficient or are these some things that might need static translation? 2) If you are sending some traffic direct to the Internet then you need to allow responses to that traffic to enter the remote site from the Internet. Do you want traffic initiated from the Internet to access the remote site? If not then how will you prevent it. 3) In the current environment where all traffic from the remote site is tunneled to the head end there are probably some security policies being implemented at the head end that control the traffic for the remote. As you move to split tunneling will you want to move any of those security policies down to the remote? If so how would they be implemented at the remote?

It is good to know that currently Symantec Web Security Services is examining your public web traffic. There probably are people in the forum who could offer good advice about whether it is feasible to send the public web traffic from the remote to Symantec Web Security and if so then how to do it. But that is insight that I do not currently have.

HTH

Rick

[Jim Mueller]

1) We have a number of initiatives for 2017 and I don't have many details on the implementations at this time. It's reasonable to assume static translation will be desirable for a few private devices.

2) We'd want the responses from the internet to route directly to the remote site.

3) We had a CCIE design our entire environment over a number of years but that person is no longer available. I'm not sure how to isolate any such policies to determine the value of moving them to the remote sites.

[Jim Mueller]

We use the same Symantec service elsewhere and this is what I was able to determine. The other service only connects to the internet, and the rules we use NAT anything with a destination of tcp/[80/3128/8080/8888] to destination {Specific IP or FQDN}:3128.

Would we have the ability to have the private/public split tunneling configuration trump the above rule, so (for example) they'd be able to access both private & public web services?

[Richard Burts]

Jim

I do not understand your question about being able to trump the rule. I believe that the 800 series router should be able to do the dynamic translation so that port 80/3128/8080/8888 going to the Internet would be translated to the Symantec address. And any traffic going to a private address server would not be translated since going through the tunnel that packet no longer looks like 80/3128/8080/8888 but looks like a tunnel packet. So I believe users at the remote site should be able to access both public address servers and private address servers.

HTH

Rick

[Rahul Govindan]

Since you are using GRE over tunnels, it really depends on the routing mechanism that you are using over the tunnels. You can choose to advertise only private networks of your Datacenter to the remote sites so that the branch routers only route that traffic over the tunnel. This can be controlled by the routing protocol at the headend side.

For the security using web based proxy, you can use the Cisco Cloud web security feature with the router as connector to send web requests to the cloud. The design similar to what you require is given here:

http://www.cisco.com/c/dam/en/us/products/collateral/security/router-security/cws-design-guide.pdf

As Richard mention, the more specifics you can provide the better. Hope this helps.