VPN connects, but can't see past next routers...

Do the remote routers have any special network configs (NAT)? What does the route table look like on the remote routers, they have routes back to the VPN IP pool network all the way, and are they correct? Can you ping from the vpn itself to those networks, and if so, make sure you also try sourcing the ping from the interface that is the DG for the IP pool.

I am kind of new at this but will take a stab. Are the different locations on different subnets? We just set up a new remote location (last november) and I forgot to put in a route to tell our remote office where to funnel the traffic back to for the main office. So traffic could get there from the main office and get in, but it didn't realize where to send the return traffic (back through the VPN tunnel in our case). After I added the route on the remote router, it worked fine.

I honestly can't tell you what the remote router configs look like, because they are AT&T managed routers, and I have no access to them. I'm sorry. I think I need to do a little more research than I have to get this answered properly. It seems to be a very complicated issue, as I just noticed this isn't only restricted to VPN - I also have an IP translation setup where extrenal IP translates to internal IP. This worked just fine until I added another router at the location with the internal IP (internet address could connect to the machine from outside our network, but now they can't. Although, again, when inside the network we can see that device just fine - I think there's an issue when the traffic tries to travel over more than 2 routers...?)

Sorry, I will do more research first.

Tim is on the right track. It sounds like you added a new subnet and there is a route missing some place. You have to remember that the VPN is more or less a gateway on both sides (gateway for vpn'ed machines to get into the internal network), and a gateway for internal network traffic to get back to the IP pool of the VPN. So the core network (internal side) has to have a static route to the VPN IP pool that points to the VPN appliances IP on the internal network. So you should be looking at route tables on a hop by hop basis, and making sure they are pointing to the right next-hop. Traceroute will work too from devices on the other side of the MPLS. Have them trace to the VPN appliance's internal network IP, and then to its IP address inside the VPN pool subnet. This should help you pinpoint where the traffic is being dropped. Just guesses here.

Thank you very much for your reply. I will try and get AT&T to look at it for me. I don't know if you have worked with AT&T on anything before, but it is an absolute nightmare - it took me 3 days to explain to them that I needed the default route (0.0.0.0 0.0.0.0 traffic) to point to a different interface, and another 2 days for them to actually fix it for me. I can just imagine the phone call when I try to explain this one to them. Ugh.

Thanks again, you are very appreciated!

Not a problem. If I were you, I would definitely do some traceroutes from remote systems to the internal interface of the VPN appliance, and see how it fares. Then I would do traceroutes from the same systems to the interface on the other side of the VPN (inside the ip pool). If one fails and one succeeds, you would have a good idea that a route is missing somewhere.

Server -> MPLS WAN - > WAN Router -> Core -> Internal Network VPN Interface -> VPN Concentrator -> VPN Pool IP Address (gateway for vpn hosts) -> VPN Hosts

If traceroutes both fail, you may have a bigger issue, but I'd be surprised if that was the case.

Your VPN clients receive an IP address that are on a different subnet or even a new subnet than all your other network resources. So the MPLS routers do not know about this new subnet. Just a guess.