VPN Connectivity to Entire MPLS Network

We have a client who has a nationwide MPLS network and they are looking for a way to provide remote workers with access to the MPLS network.

I had expected to be able to configure SSL VPN on one of the ASAs on the network and that everything else would fall into place.  I have a feeling that I am missing a NAT exemption somewhere in my access-lists, but since I have never attempted something like this before, I wanted to make sure this was possible before I went crazy finding what was missing.

The MPLS network uses various /24s on the /16 netblock. /24 is used for MPLS routing between sites by the carrier. /24 is what I currently have configured as the IP pool on the ASA for SSL VPN clients.

In my NAT exemption lists (using double NAT on ASA 8.4.1), I have included the /16 and the as the source and as the destination.

Same with the split-tunnel access-list.

The VPN tunnel comes up fine, the SSL client indicates all the routes I specified are secured, but I only have connectivity to the network where the ASA I am establishing a VPN connection to is the default gateway.

At first, I thought that this may indicate that what I was looking to accomplish was not possible, however, weird traceroute response has me believing that something may just be misconfigured. /24 is the network the ASA is acting as the gateway for.  When tracerouting to a machine on this network, I get one simple response and standard pings work perfectly.

When attempting to tracert to a machine on the /24 network, a tracert returns one successful reply and then continuous failures.  Ping attempts return nothing.

Any assistance or input would be appreciated.
Who is Participating?
If I'm understanding you properly your remote clients attached to the VPN can only communicate with the internal subnet local to the ASA they're connected to.

Given that, it sounds like you need to set routes across the rest of your network pointing the network back to this ASA. Your packets from the remote host are likely making it to the destination but the destination host has no known path to get back.
djcaponeAuthor Commented:
Lol...ah yes something so simple overlooked.  I will give this a try this afternoon.
those were words based on first hand (and infuriating) experience sir. good luck! :)
djcaponeAuthor Commented:

I may need to simulate this in a lab and confirm this as the source of the problem.  this is a network I have recently taken over and the routing is a mess.  I am in the process of cleaning this up but that will take some time.

I added:

ip route (IP of ASA)

to the router controlling /24 and I am experiencing the same symptoms.

Like I said the part that is odd is that if I ping (for example) from a client connected to ASA via SSL VPN, I never get a response.

If I run tracert from the DOS command prompt, I get a 67 ms reply with listed as the "target" as the first hop, and then * * * till I break out of the tracert command.  tracert to 192.168.169.X yield basically the same response as the attempt to for the first step only then it correctly ends and brings me back to prompt.  I can also successfully ping on the 169.0 network.

Any more ideas would be appreciated, as I would like to find a way to patch this in while the rest of routing situation is squared away.

Do you have any good techniques for how I might be able to trace where these packets are getting lost?

Thanks again.
yeah you'd get that first response from the next hop because it would more or less be a direct connection on the next ASA.

simple trick would be to go to one of those hosts on your 192.168.168.x network and do a tracert to and see where the packet goes. Doesn't matter if that .50 is active or not since we're not interested in if we get a response or not, just want to see what direction it travels.

i feel you on the sloppy routing table thing. i just last week stripped a dozen or so routes out of my core from old point-to-point lines that haven't existed in years. are you using a routing protocol or all statics? you might be better served to go the way i did and just configure eigrp on everything and start stripping out statics until something breaks (one-off connects etc) then probably the only thing you'd need is a static route for your 172.16.3.x in the default router on the attached subnet and add "redistribute static" to the protocol so all the other participating routers would see it.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.