Link to home
Start Free TrialLog in
Avatar of lifetech
lifetech

asked on

site to site VPN - cannot route past main office.

I have a site to site VPN setup using Cisco ASA's. The VPN is working fine - users in the remote site (192.168.0/24) can get to resources in the main office and vice versa. The issue is, users in our divisions (All of our divisions are connected to the main office via MPLS connections) cannot connect to the remote office. Our main office uses subnets 10.1,1 10.1.2 etc. Our divisions use 10.6, 10.8, etc. The VPN was set up so that it allows access to any 10 network 10.0.0.0/8. Not sure if this is a routing issue or an issue with the VPN setup.
Avatar of SIM50
SIM50
Flag of United States of America image

Please confirm interesting traffic ACL matches 10./8 and 192.168.0/24; and ACL's to allow traffic match that too.

Where do MPLS connections terminate? Behind the firewall or in front?
Avatar of lifetech
lifetech

ASKER

Yes interesting traffic and ACL matches 10./8 and 192.168.0/24.
Here is a basic diagram. From any subnet at the main office, I can get to the Remote office fine, from any of the division offices, I cant.

RemoteASA-------VPN------MainOfficeASA---MainOfficeRouter----MPLS----DivisionofficeRouter
Hi There,

Kindly check the trace path from the division office router to the LAN subnet behind the remote ASA.
ASKER CERTIFIED SOLUTION
Avatar of SIM50
SIM50
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thank you both for your help.
The trace to 192.168.0/24 from a division router to our router at the main office indicates the traffic is coming across the MPLS and makes it to the router. It looks like it stops there though and does not go across the VPN to the remote office.
We run BGP. the division offices do not have a route for 192.168.0/24, but there is a default route that points to the router at the main office. I did try putting a route into BGP for that but it did not resolve the issue so I took it back out.
Where does your default route point to?
If you configure a static route for 192.168.0./24 on MPLS router pointing to ASA inside interface, does it appear in the routing table?
our default route (Advertised via BGP) points to our mpls router at the main office, which has the company's only internet connection. I did try a static route on a division mpls router that points 192.168. to the ASA inside interface, but no joy. It does appear in the routing table.
There is a static route on the mpls router at the main office that points 192.168.0 to the ASA inside interface. Can figure out why I can only ping across the VPN from any subnet at the main office. It looks like the traffic from a division office destined for 192.168.0 gets to the main office router, but it doesn't send it across the VPN. Or the VPN doesn't accept it.
Can you please post your VPN config from local and remote ASA?
Sure. Here you go. Both sides were set up using the standard cisco Site to Site VPN Wizard. I don't have the remote site config, but it should be very similar to this, with the remote and local subnets being reversed.
gib-ASA_17-Mar-16.txt
Ok. VPN looks good on this side. What about ACL for the traffic traversing the tunnel?
Also, let's un-stealth the firewall to see if it really stops on your router or ASA.

conf t
policy-map global_policy
class class-default
set connection decrement-ttl
end
wr

Now, your ASA should show up on a trace route results.
Run tracert from any PC at the 10.6 & 10.8 networks to 192.168.0./24 IP. If you will see the firewall at the last hop than the problem is with VPN config. If it is still the router, then it is routing.

To make firewall stealthy again, remove the command above.

conf t
policy-map global_policy
class class-default
no set connection decrement-ttl
end
wr
Hmm. I un-stealth'd it, but its still not returning trace results - even to other sites on the internet. If I recall there is another setting that is stopping it from returning pings/traces.
Here is the ACL related to this VPN - is this what you wanted?
access-list outside_cryptomap extended permit ip 10.0.0.0 255.0.0.0 192.168.0.0 255.255.255.0

Here is a trace from the main office if that helps. Below that is a trace from a division office.

  1    10 ms     2 ms     2 ms  10.1.5.254
  2     2 ms     2 ms     1 ms  DS2.gibraltar1.com [10.1.0.254] (router at main office)
  3     *        *        *     Request timed out.
  4   217 ms   221 ms   217 ms  192.168.0.98

Tracing the route to 192.168.0.98
VRF info: (vrf in name/id, vrf out name/id)
  1 198.233.222.33 8 msec 16 msec 8 msec (BGP neighbor of division office)
  2  *
    65.118.206.89 [AS 209] 24 msec 24 msec (BGP neighbor at main office)
  3 65.118.206.90 [AS 209] 36 msec 32 msec 40 msec (router at main office - MPLS connection)
  4  *  *  *
  5  *  *  *
Yes, I forgot about icmp unreachable default setting. :/

conf t
icmp unreachable rate 10 burst 10
end
wr
I think I figured it out. From the remote office routers is used during testing, pings were not being returned. From remote office PC's they could ping across the VPN without issues. There is a core switch at the remote office in question that did not have a route to the 192.168.0 network. So it looks like the MPLS and VPN routing was fine. I marked one of your earlier posts as the answer, because this pointed me in the troubleshooting direction that I needed. Thank you so much for your help!
No problem. Don't forget to remove those commands from the firewall.
Hi there,

Maybe i got lost in the translation.
Division office was not able to reach 192.168.x.x subnet in the remote branch office.
Unable to understand how a core switch in the remote office did not have a route to its own LAN.
Btw SIM50, some excellent commands you posted.thanks for that.
It was actually a division office (Connected via MPLS) that did not have a route from its LAN switch to the WAN router for the remote subnet (192.168.0).