Solved

Migrating from Site to Site VPN to MPLS

Posted on 2014-04-16
6
312 Views
Last Modified: 2014-06-13
We've recently switched from a site to site VPN to an service provider MPLS.  So, I removed (so I think) all remnants of the site to site VPN in the ASA's.  The subnets are subnet 1 and subnet 2.  The MPLS is a separate network on connection on a service provider router.  I have put the command:

route inside 192.168.2.0 255.255.255.0 192.168.1.2 on the network 1 ASA

and
route inside 192.168.1.0 255.255.255.0 192.168.2.2 on the ASA on Subnet 2 ASA

I can ping 192.168.1.2 and 2.2 from the opposite networks.  But, when I try to ping from the desktops, it won't cross.  If I tracert it, it times out before it even gets to the default gateway.  

What am I missing? I know I have ICMP blocked going outbound, but it should work across the MPLS.

Traffic should flow as follows:
1. Client PC
2. ASA
3. MPLS Router
4. Remote MPLS Router
5. Remote device.  

What can I look for? Any suggestions would help.
0
Comment
Question by:esolms
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
6 Comments
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 40005607
Hmmmm.  I thought I'd already answered this.

I can't think of any reason why it shouldn't be working.

The internet gateways all need to point to the other LAN subnets with the local MPLS router as the next hop.
The MPLS routers each need to have a route to all the other LAN subnets.

If the internet gateway routers are confused because the return packets aren't in any stateful context then that "feature" has to be dealt with (since the incoming packets don't hit the internet gateway at all - so it has no state information).
0
 

Author Comment

by:esolms
ID: 40005698
Sorry, you did answer.  They made me post it to a different board.  I didn't realize I posted to the wrong board.  But, I do have these setup.  I did a route inside command on each ASA to point to the internal interface on the MPLS.
Could it be a access list issue?
0
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 40005720
I'm not the Cisco expert here so all I can suggest are the basics that have to be met.
I can ping 192.168.1.2 and 2.2 from the opposite networks.  But, when I try to ping from the desktops, it won't cross.  If I tracert it, it times out before it even gets to the default gateway.
This statement seems key in the analysis.  I'm not sure I understand what you mean by "when I try to ping from the desktops" while "I can ping 192.168.1.2... from the opposite networks"  Why isn't the latter "from the desktops" too?
The tracert result is *really* telling.  You aren't getting packets to the default gateway.
But, I should ask, do you mean the default *internet* gateway or the MPLS gateway?
Where does the traceroute end. At the default internet gateway device or at the MPLS router or before the internet gateway?
0
[Live Webinar] The Cloud Skills Gap

As Cloud technologies come of age, business leaders grapple with the impact it has on their team's skills and the gap associated with the use of a cloud platform.

Join experts from 451 Research and Concerto Cloud Services on July 27th where we will examine fact and fiction.

 

Author Comment

by:esolms
ID: 40006407
Everyone's default gateway is the Internet Gateway ASA.  The traceroute never goes anywhwere.
0
 
LVL 20

Accepted Solution

by:
rauenpc earned 500 total points
ID: 40006564
So the ASA always wants to see stateful connections whenever possible. Your current setup most likely creates asymmetric routing.
In your earlier post, you put:
Traffic should flow as follows:
1. Client PC
2. ASA
3. MPLS Router
4. Remote MPLS Router
5. Remote device.  
Which is probably true, assuming that you have the "same-security-traffic permit intra-interface" command applied. But consider the return traffic
1. Remote device.
2. Remote MPLS Router
3. MPLS Router
And because the MPLS router is on the SAME subnet as the client PC, it send traffic directly to the client and doesn't use the ASA at all.
4. Client PC

There are ways to configure the ASA to ignore state data for these connections, but that isn't recommended as a permanent fix. The real fix is to get away from asymmetric traffic flows. This could be done by using the local MPLS router as the clients' default gateway. You may need to make some routing changes on the MPLS router to support this.
Another method would be to put the MPLS router on a different subnet, create a sub-interface on the ASA, and then configure routing as needed for this.
Myself, I would go for the option to use the MPLS router as the clients' gateway device, that way you don't have to apply a potentially messy config on the ASA. I do realize that if the MPLS router is managed by the ISP, this takes away from some of your control and visibility, but it still seems like a better choice than hairpinning traffic through an ASA.

Overall, when I have clients looking to implement MPLS, I always try to steer them to get their own router to connect into MPLS, run BGP, and that way they have a descent share of control over the routing of the MPLS cloud, and then they don't run into situations like this where you have to make a compromise between visibility and management or a potentially complicated ASA configuration. I hope this helps.
0
 
LVL 26

Expert Comment

by:Fred Marshall
ID: 40007046
At least it appears we agree with rauenpc on what may well be the issue.  I said:
If the internet gateway routers are confused because the return packets aren't in any stateful context then that "feature" has to be dealt with (since the incoming packets don't hit the internet gateway at all - so it has no state information).
And we have different ways of tackling it.  I'm not sure which is "easier" or more "complicated".  A lot depends on your situation.  There's much to be said for selecting the "better" solution from a security and management point of view.
0

Featured Post

Optimum High-Definition Video Viewing and Control

The ATEN VM0404HA 4x4 4K HDMI Matrix Switch supports 4K resolutions of UHD (3840 x 2160) and DCI (4096 x 2160) with refresh rates of 30 Hz (4:4:4) and 60 Hz (4:2:0). It is ideal for applications where the routing of 4K digital signals is required.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Cybersecurity has become the buzzword of recent years and years to come. The inventions of cloud infrastructure and the Internet of Things has made us question our online safety. Let us explore how cloud- enabled cybersecurity can help us with our b…
Examines three attack vectors, specifically, the different types of malware used in malicious attacks, web application attacks, and finally, network based attacks.  Concludes by examining the means of securing and protecting critical systems and inf…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…

626 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question