DMVPN - remote site can access corporate LAN's but not internet

Unanswered Question
Sep 9th, 2009

Have an interesting one I may need some assistance on.

Have a remote branch site setup on VPN (using DMVPN configuration). The site can access the main headquarters networks just fine, but can't get internet access. I think it's because the VPN router (VPN hub) located at the headquarters has a default route to it's internet routers so it can get access to the internet. We are running EIGRP internally. When I trace from the branch router to say 4.2.2.2 (common public DNS server) the trace dies at the headquarters VPN hub router. When I trace to 4.2.2.2 from the VPN hub router at the headquarters it goes straight out hits the internet routers and is fine.

Thanks in advance for suggestions.

-Brandon

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Laurent Aubert Wed, 09/09/2009 - 19:12

Hi Brandon,

It seems your branch has a default-route right ?

In this case, you need to check the following:

- Is your remote branch traffic well nated ?

- Does your internet router have a route to send the traffic back to the remote branch via the VPN Hub ?

HTH

Laurent.

mbroberson1 Thu, 09/10/2009 - 04:41

Hi Laurent,

The setup is link this.

The branch had a fiber connection, but has a backup DSL where we are running DMVPN over as a backup link. Traffic favors of course the fiber, but if there's a cut traffic will go over the backup DSL VPN link.

The branch has a default-route over the fiber to in internal router ad headquarters. The headquarters internal router has a default-route to the internet routers. Internet works fine when your traffic goes over the fiber, but when you test and take the fiber down traffic goes over the backup DSL VPN link to a router that is directly connected to the internet (our VPN hub router). This VPN hub router has a default-route pointing to the internet and a routting table of all our internal sites. This VPN hub router is not our true internet router, it's just a router with a public ip for the sites with DMVPN as a backup.

Hope this helps,

Brandon

Laurent Aubert Thu, 09/10/2009 - 05:01

Thanks for the update.

- Do you have a default route pointing to the VPN Hub when the fiber is down ?

- Is your VPN hub router well configured to do NAT ?

- If the VPN Hub is not directly connected to the Internet, has your true Internet Router a route to join the public IP address used by the VPN Hub ?

HTH

Laurent.

mbroberson1 Thu, 09/10/2009 - 05:12

Hi Laurent,

-As far as a default-route pointing to the VPN hub when router is down do you mean a "floating-static default-route"? If so then no there is not.

-There is no NATing going on.

-The VPN hub IS directly connected to the internet. Or in other words it has a public ip address on an interface whihch is the address the remote routers peer their VPN connection with. This HUB vpn router has a default-route pointing towards the internet router.

Thanks

Laurent Aubert Thu, 09/10/2009 - 05:52

"-As far as a default-route pointing to the VPN hub when router is down do you mean a "floating-static default-route"? If so then no there is not. "

The remote branch needs a floating default route pointing to the tunnel otherwise you will not be able to reach the internet via the VPN Hub if your primary link is down. This route can be static or dynamically learn via the IGP running inside the tunnel.

"-The VPN hub IS directly connected to the internet. Or in other words it has a public ip address on an interface whihch is the address the remote routers peer their VPN connection with. This HUB vpn router has a default-route pointing towards the internet router."

So it means your branch routers have a static public IP address so you can use the default route to reach the Internet via your true internet router and not via your local interface. I assume the true Internet router is doing the NAT.

Troubleshooting routing issue is pretty straightforward:

Start on the branch and based on the destination find what is the outgoing interface (sh ip route). If the egress interface is the expected on, then do the same check on the next-hop up to the destination.

HTH

Laurent.

mbroberson1 Thu, 09/10/2009 - 06:26

Hi Laurent,

We do have an ASA that sits behind the internet routers that's going PAT, this is where the only type of NAT is being performed.

What seems to happen is traffic across the VPN from remote branch hits VPN hub router and then can reach corporate networks just fine, but when you try to access the internet it seems to get lost at the HUB VPN router. Now the HUB VPN router can reach the internet just fine since it has a public ip address and is directly connected to the internet.

I would like for traffic destined to the internet across the VPN to hit the VPN hub router then be directed toward the true internet routers and not our the VPN hub router which seems to be the issue.

mbroberson1 Thu, 09/10/2009 - 07:52

Hi Laurent,

The remote/branch can get to the internet if I put a default-static route pointing to the DSL modem public facing ip address. Is the way to do the configuration? I would prefer to have the internet access go through the VPN tunnel hit the VPN hub router then be directed toward our true internet routers, but since the VPN hub router has a default-static 0.0.0.0 0.0.0.0 x.x.x.x route pointing to the internet router (so it can be accessed from the internet) how can I make this happen? Should I use a form of route-map on the VPN hub router?

Thanks

Giuseppe Larosa Thu, 09/10/2009 - 08:12

Hello Brandon,

if I've understood the scenario the key point is the following:

the DMVPN hub router at central site has a public ip address (necessary to terminate the mGRE over IPSec) and it is in a DMZ so after decapsulating remote site traffic if it is destinated to the internet (because central site DNS has resolved the URL) it tries to send it out directly to the internet router without any form of NAT so the problem is on the return path: no one from the internet can reach the remote sites private ip subnets.

Because this is a failover scenario wher the primary link has failed you have few options:

a) allow internet access from the remote site via the DSL link implementing NAT overload there (traffic to private central site ip subnets go over DMVPN) and traffic to the internet is natted.

b) to have a default route over the DMVPN and to implement NAT on the central site DMVPN hub router. (It may be a NAT overload or PAT using the public ip addres of the DMVPN hub router)

c) as you are thinking of: using PBR to redirect traffic coming from remote site to the ASA to make it appear as it is coming from the intranet.

This may be possible depending on the way the devices are interconnected.

Hope to help

Giuseppe

Laurent Aubert Thu, 09/10/2009 - 08:54

The default-route needs to point to your tunnel interface instead of your physical interface:

ip route 0.0.0.0 0.0.0.0 tunnel x

Laurent.

Giuseppe Larosa Thu, 09/10/2009 - 03:06

Hello Brandon,

check if the internet facing routers at central site know the remote site IP subnets (specially the client Vlan subnets).

Check also if NAT is performed for the remote site IP subnets at the central site internet facing routers/firewalls..

Have you tried to use an extended traceroute and to specify a source = client vlan ip address.

The issue may be limited to the DMVPN IP subnet like it happened with frame-relay WAN.

Hope to help

Giuseppe

mbroberson1 Thu, 09/10/2009 - 08:52

The default-route on the branch/remote site? What about the default-route on the VPN hub that points out to the internet router? I of course need this route for the VPN hub router to be accessible from the internet so the VPN can function.

Should the defaul-routes be weighted?

Thanks

Laurent Aubert Thu, 09/10/2009 - 09:43

Yes on the remote sire.

The VPN Hub already has a default route it will use to either route the IPSec packets or the clear packets (after decryption) to your Internet router.

Routing is a hop by hop decision.

Laurent.

Actions

This Discussion