Tunnel Routing

[austin.madsen]

Hello,

I'm scratching my brain and trying to figure out an IP route issue. Hopefully someone much smarter than I can shed some light on it.  I have two vlans, one is a standard LAN with internet access.  The other is the problem, it should be a VPN to another network for corporate resources and protected / filtered internet access. The issue I seem to be running into is that my tunnel doesn't have a next hop so I cant get PBRs to work.  Whenever I try and add another IP route of something like 0.0.0.0 0.0.0.0 Tunnel 99 and write PBRs traffic doesn't pass.  I can ping and contact local resources over then tunnel just, no internet access. NAT is also turned on at the far end. I'm used to source and destination routing with another vendor so its very possible a config mistake is happening.  Any guidance is appreciated, conf below:

interface Tunnel99
 ip unnumbered GigabitEthernet0/1.99
 tunnel source S.S.S.S
 tunnel destination D.D.D.D
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VPN

interface GigabitEthernet0/0
 description Charter
 ip address X.X.X.X 255.255.255.248
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 media-type rj45
 negotiation auto

interface GigabitEthernet0/1
 description LAN
 no ip address
 duplex auto
 speed auto
 media-type rj45
 negotiation auto
 no mop enabled

interface GigabitEthernet0/1.1
 description LAN
 encapsulation dot1Q 1 native
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 no snmp trap link-status

interface GigabitEthernet0/1.99
 description VPN
 encapsulation dot1Q 99
 ip address 10.212.135.1 255.255.255.0
 no snmp trap link-status

ip classless
ip route 0.0.0.0 0.0.0.0 GW.GW.GW.GW
ip route 172.16.0.0 255.255.0.0 Tunnel99

ip nat pool ovrld S.S.S.S S.S.S.S prefix-length 29
ip nat inside source list 1 pool ovrld overload

access-list 1 permit 10.10.10.0 0.0.0.255
access-list 23 permit 10.10.10.0 0.0.0.255

[Richard Burts]

I would have thought that the route that you have configured using the tunnel should work. Are you sure that the tunnel is really coming up? And does the router on the other end have an appropriate route through the tunnel for traffic coming back to you?

HTH

Rick

[austin.madsen]

Hey Rick,

Thanks for the feedback.  With the IP route 172.16.0.0 255.255.0.0 Tunnel99 I can access anything that is over the tunnel just no internet, expected as there is no wildcard route to tunnel 99.  Its when I add the 0.0.0.0 0.0.0.0 Tunnel 99 then add associated route-maps, I loose connectivity on both VLANs.  Its possible that's where the problem is as well.  I've been assigning extended IP access lists permitting each network then doing a route-map with a next hop of the Charter ISP for the 10.10.10.1 network and leaving the tunnel network as there is no GW address.  Should/can I be using the tunnel destination as the  next hop?

-Austin

[Richard Burts]

Austin

It looks like I misunderstood what was your problem. I thought it was a problem with getting traffic going over the tunnel. Now I think that I understand that traffic for the remote LAN is passing ok over the tunnel. Is that correct? And that the problem comes up when you  attempt to set your default route to use the tunnel. Since the partial config in the original post included a static default route that appears to be to a local next hop then perhaps you can share some details of how you are attempting to change it when the tunnel stops working? I am wondering if the changes somehow make it appear that the tunnel destination is reached through the tunnel. This would cause recursive routing and cause the tunnel to fail.

HTH

Rick

[austin.madsen]

Hey Rick,

The tunnel does actually pass traffic.  For a test I added ip route 0.0.0.0 0.0.0.0 tunnel 99 and was able to route traffic through the tunnel and at HQ perform NAT.  Unfortunately having two static routes with 0.0.0.0 0.0.0.0 had some unexpected results as I suspect the router was trying to send the traffic at both routes.  I'm wondering if I should leave the two routes in there and reattempt some PBRs or if I should segment with VRF?  The PBRs attempted haven't worked out so far but, that could be my user error.  Here is what I added thinking it would use the routes as expected:

ip access-list extended 100
permit ip 10.10.10.0 0.0.0.255 any
route-map LAN
match ip address 100
set ip next-hop GW.GW.GW.GW
int g0/0
ip policy route-map LAN

ip access-list extended 101
permit ip 10.212.135.0 0.0.0.255 any
route-map VPN
match ip address 101
int tu99
ip policy route-map VPN

-Austin 

[Jon Marshall · Accepted solution]

Austin

By the looks of your configuration you want traffic from 10.212.135.0/24 to go via the tunnel.

If that is the case then  -

1) you only need one default route and you can use the local internet access default route

This means you don't need PBR for traffic that uses the local gateway.

2) your PBR configuration is only needed for the HQ traffic ie. via the tunnel and your PBR route map VPN needs to have "set interface tunnel99"

then apply the PBR to the gi0/1.99 interface ie.

int gi0/1.99
ip policy route-map VPN

Jon

[Richard Burts]

Austin

I still do not understand what you are trying to achieve. Can you provide some clarification?

Certainly when you have two default routes configured the router will attempt to use both of them. And that probably does mess things up.

If it is that you want some traffic from certain source addresses to use the tunnel (including using the tunnel for Internet access) then I like Jon's suggestion of a single PBR with a set interface rather than a set ip address.

But the most important thing is for us to really understand what you are trying to achieve.

HTH

Rick

[austin.madsen]

Hey Guys,

Thanks for the help!  I was looking to route 10.10.10.0 (VLAN1) to the default ISP GW and 10.212.135.0 (VLAN99) over the tunnel interface 99. I was able to achieve the routing desired with the single PBR on 0/1.99.  I think I was misplacing the single PBR and trying to add another for the default route and that was causing my headaches.  I'm grateful for the guidance!

-Austin