Solved

Migrating from Site to Site VPN to MPLS

Posted on 2014-04-16
6
306 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
  • 3
  • 2
6 Comments
 
LVL 25

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 25

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
The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

 

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 25

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

Live: Real-Time Solutions, Start Here

Receive instant 1:1 support from technology experts, using our real-time conversation and whiteboard interface. Your first 5 minutes are always free.

Question has a verified solution.

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

Suggested Solutions

Using in-flight Wi-Fi when you travel? Business travelers beware! In-flight Wi-Fi networks could rip the door right off your digital privacy portal. That’s no joke either, as it might also provide a convenient entrance for bad threat actors.
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

776 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