Solved

Migrating from Site to Site VPN to MPLS

Posted on 2014-04-16
6
310 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
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 

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

U.S. Department of Agriculture and Acronis Access

With the new era of mobile computing, smartphones and tablets, wireless communications and cloud services, the USDA sought to take advantage of a mobilized workforce and the blurring lines between personal and corporate computing resources.

Question has a verified solution.

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

Suggested Solutions

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é.
The use of stolen credentials is a hot commodity this year allowing threat actors to move laterally within the network in order to avoid breach detection.
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

751 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