Simultaneous Tunneled and Native Internet Access

By stretch | Tuesday, September 4, 2012 at 12:19 a.m. UTC

Suppose you have a number of branch sites which need to connect to a hub site. Each branch site has a private dedicated circuit as its primary path and a routed VPN tunnel carried over a business-class broadband circuit as its secondary circuit.

branch_site.png

Under normal conditions, all traffic from the site traverses the dedicated circuit. Should the dedicated circuit fail, all traffic (including Internet traffic) traverses the VPN tunnel over the Internet back to the main site. Internet traffic is routed via the main site rather than directly out to the Internet to ensure that is passes through a content filtering mechanism.

This design is fairly simple, but what if we need to provide Internet access for a guest wireless network as well? This guest traffic can not, for security reasons, be routed through the main office; it must be routed directly out to the Internet via the broadband circuit.

The first implication of this new requirement is that we will need two default routes: One for internal corporate traffic to follow back to the main site, via either the dedicated circuit or the VPN tunnel, and one for the guest network to follow directly out to the Internet. We can leverage VRF lite on Cisco IOS to accomplish this.

First, let's define our interfaces on the branch router:

  • Gi0/0.10 - Corporate network (VLAN 10)
  • Gi0/0.20 - Guest network (VLAN 20)
  • Gi0/1 - Private MPLS connectivity to main office
  • Gi0/2 - Broadband Internet access
  • Tunnel0 - Backup VPN tunnel to main office

We'll create a VRF named Internet to hold the guest network and Internet interfaces and a default route. Corporate network routes will be kept in the global table. (This may be the inverse of what you would expect when employing a VRF, but it works quite well.)

ip vrf Internet
!
interface GigabitEthernet0/0
 no ip address
!
interface GigabitEthernet0/0.10
 description Corporate LAN
 encapsulation dot1Q 10
 ip address 10.8.42.1 255.255.255.0
!
interface GigabitEthernet0/0.20
 description Guest Wireless
 encapsulation dot1Q 20
 ip vrf forwarding Internet
 ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet0/1
 description Private Circuit
 ip address 10.8.0.26 255.255.255.252
!
interface GigabitEthernet0/2
 description Broadband Internet
 ip vrf forwarding Internet
 ip address 192.0.2.84 255.255.255.0
!
interface Tunnel0
 description VPN Tunnel to Main Office
 ip address 10.16.0.26 255.255.255.252
 tunnel source GigabitEthernet0/2
 tunnel destination 174.143.213.184
 tunnel protection ipsec profile VPN

Assume that a default route is being advertised via BGP over the private circuit, and a floating static default route has been configured pointing out the VPN tunnel in the global table. We just need to configure a static default route in the Internet VRF:

Router(config)# ip route vrf Internet 0.0.0.0 0.0.0.0 192.0.2.1

There's one piece of configuration left to make: Since we assigned Gigabit0/2 to the Internet VRF, and Tunnel0 is being sourced from that interface, we need to explicitly source Tunnel0 from that VRF:

Router(config)# interface tunnel0
Router(config-if)# tunnel vrf Internet

This command instructs the router to follow the Internet VRF routing table to reach the tunnel endpoint. It does not affect the forwarding of traffic within the tunnel, which is kept in the default routing table. (To change the forwarding VRF, you would use the command ip vrf forwarding just as you would on a physical interface.)

Note: I've not included a complete configuration here: You would want to extend the interface configurations to employ NAT and probably some type of security control, such as IOS Zone-Based Firewall.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Design

Comments


Bkil
September 4, 2012 at 1:13 a.m. UTC

Good article, I'm having fun and learning by going back in the archive of the site while waiting for new posts :)

One thing I've noticed at work is that when customer have this setup and their main site goes down they are a lot more frustrated then if they had a separate content filtering device at each site.

I know that it is a lot more expensive but if you only lose your main site instead of all of them isn't that better?

You have redundant connections at your branch offices. You then limit yourself to a single point of failure in that all traffic must go to the main site.

An addition or expansion to this might be that if the main site can't be reached that normal internet traffic be allowed out out of the broadband connection. If this is allowed by the rules of the organization and laws it has to follow. I don't think this would work for schools as they need to filter what their students can access.


Steven (guest)
September 5, 2012 at 8:47 p.m. UTC

Good article. I would normally accomplish this using Policy-based Routing. Any thoughts on pros/cons of either technique?


stretch
September 5, 2012 at 11:53 p.m. UTC

@Steven: As a rule, I avoid PBR wherever possible. In my experience it's rarely an elegant solution (and even more rarely thoroughly documented).


mohandesadla
September 9, 2012 at 11:43 a.m. UTC

hi dear

thanx

topic is very very .... gooooooooooooooooooooooooood


Faizal (guest)
September 13, 2012 at 8:09 a.m. UTC

This is great way of doing it. We have similar setup but for Guest/Visitor, we use route-map and next hop IP of the ISP default-gateway so that all guest/visitor traffic break out to the internet through local ISP without going through our core network. Furthermore, I have setup a bandwith limit and restricted them to limited amount of bandwidth that they get using traffic shapping policy.


Scott24038
October 18, 2012 at 1:54 p.m. UTC

There are other ways to accomplish this, but this is probabbly the cleanest and kills both the routing and security birds with one stone. It's simple and ensures that the guest users can't touch the corporate network.

The only thing different I'd probabbly do rather than using a floating static is peer the BGP peers over both links using two different loopbacks at the Main office router. Using the lower IP for the private circuit and the higher IP for the VPN tunnel. That way you will get identical BGP tables from the same peer on two different addresses. With identical parameters BGP will install prefixes learned from the lower IP address into the routing table. When the private circuit fails, those routes gets flushed and BGP will install the prefixes, including the default route, learned through the other peering. That way all your routes failover to the VPN tunnel, not just the default route.


Henrique (guest)
October 30, 2012 at 2:17 p.m. UTC

Where is documented that the data license also includes IP SLA?


Tom (guest)
November 14, 2012 at 3:03 p.m. UTC

Good article.

However, our company uses ASAs everywhere, no routers. So we can't use VRF nor PBR.


ed (guest)
November 21, 2012 at 6:18 a.m. UTC

good article...
I have a setup like this with 120+ sites.. I guess alot of us do.

Being busy and a dead-line (surprising) to implement Wireless controller + identity service engine from cisco, i've gone ahead and let the local DSL hand out the ip addresses to guests, that way they don't touch the corporate side at all.

they connect to ssid which is set to guest vlan and end of story.
no config :]

I've also natted all DSL modem/routers so I can access them from HQ in case I need to change something - hell i've even gone ahead and setup dynDNS on most of them, so i can access them as ny.mycompany.com , chicago.mycompany.com and so on, eventhough their public address changes.

pros: easy
cons: not alot of visibility of what they are doing.


Anthony Kellar (guest)
January 21, 2013 at 9:28 p.m. UTC

Interesting design. That is what makes networking so awesome! So many ways of accomplishing the same things.

I used layer 2 VLAN Access Maps to restrict Guest Network Traffic from Corporate users...both directions. They are even NAT'd to a different public address so they they cannot SSH into our external devices. They in effect...follow the same default route...regardless of which network they are on. This enables us to ensure traffic is properly routed through our IPS's...firewall dynamic filters, etc...etc.


larry (guest)
February 6, 2013 at 8:15 a.m. UTC

What would this look like with a crypto map vs the tunnel to establish the vpn tunnel?


mgurbski
February 17, 2013 at 11:19 p.m. UTC

Hi Jeremy

Thanks for the inspiration.

I used your example in different way. VRF is defined for tunnel and uses global ip routing table to forward packet for this tunnel.

michal

P.S.
here is config:

ip vrf Client_A

interface Tunnel44
description ### Tunnel to Client_A for monitoring ###
ip vrf forwarding Client_A
ip address 10.44.44.1 255.255.255.252
tunnel source fa0
tunnel destination Public_IP_addesss_Client_A
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE-VPN-SERVER
exit

interface Fa0
description ### Public IP address ###
ip address Public_IP_address
! no vrf

Leave a Comment


Optional; will not be displayed publicly or given out.
No commercial links. Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.
How many bytes in length is a UDP header?