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.
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------M ainOfficeA SA---MainO fficeRoute r----MPLS- ---Divisio nofficeRou ter
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------M
Hi There,
Kindly check the trace path from the division office router to the LAN subnet behind the remote ASA.
Kindly check the trace path from the division office router to the LAN subnet behind the remote ASA.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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?
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?
ASKER
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.
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?
ASKER
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
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
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
ASKER
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 * * *
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
conf t
icmp unreachable rate 10 burst 10
end
wr
ASKER
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.
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.
ASKER
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).
Where do MPLS connections terminate? Behind the firewall or in front?