VPN authenticates, but no access

[lucian01]

Hi all,

I use my Cisco VPN dialer and login with no problems, but I can't access anything in my company's network. I thought it was my internal network or my ISP, but I used my dialer and got into another company's VPN and I have access to internal resources. Any pointers on what I should check on the first company's VPN device?

The biggest difference I saw was the one that works has transparent tunneling active on UDP port 4500 while the one that doesn't work is set to inactive.

Thanks in advance.

Lucian

[Richard Burts]

What are you connecting to when you attempt a VPN connection (a VPN concentrator, a PIX, or what)? Is this a consistent problem that happens every time you attempt to access via VPN to your company? Do other people access your company VPN and access resources ok? Knowing the answer to these questions would help us give a better answer to your question.

I recently had to troubleshoot a problem like this. It impacted all users. They could access the VPN concentrator, could authenticate, and would get assigned an IP address from the pool on the concentrator but could not access any resources. The problem turned out to be that the address pool was not being properly advertised into their network. So when they attempted to access some resource, the response could not get back to them. So be sure that the IP address pool is being advertised correctly. Also be sure that the concentrator (or whatever device has appropriate routes to get to the resources that you want to get.

HTH

Rick

[patricklaupt]

Hi Rick,

I have a similar problem with my PIX. The client (PPTP on W2K) is able to authenticate, the PIX recognizes the connections and assigns an IP, but the client cannot ping/access anything behind the PIX, not even the PIX itself. I don't fully understand what you mean by "address pool not properly advertised". Could you please elaborate and give some suggestions?

Many Thanks,

Patrick

[Richard Burts]

Patrick

Is this a problem for all clients or do some work and some do not?

What I meant by the address pool properly advertised is do devices in the network beyond the PIX have those addresses in their routing table. If you go to a router in the network and do a show ip route a.b.c.d (the IP address of the client which is having the problem) does the router have a route to that address - and if so does the route point to the right place. I recently had to troubleshoot a VPN connectivity problem at a customer site. The problem turned out to be that the addresses in the address pool were also being advertised by a router in the network (due to misconfiguration of the router). So you do need to see if there is a route and also that the route would get you to your PIX.

In some cases the address pool can be advertised by the VPN device itself (most of my VPN experience is with concentrators and routers, so they can participate directly in the routing protocol and advertise their address space). Or the router to which they attach can configure a static route and redistribute the static into the routing protocol.

HTH

Rick

[lucian01]

Rick,

Sadly, I don't have the specific hardware for you, but I did more troubleshooting and here are the results. If I plug my computer directly to my DSL modem, my computer pulls a legitimate IP. My VPN works with no problems. When I hook my computer to a D-Link router which gets internet access through the DSL modem, it authenticates, but can't get to internal resources. My computer now has an internal IP assigned from the D-Link router. I did a route print on my computer and the internal routes needed show up. Doing a tracert to an internal network server, it tries to go through my D-Link router which is the default gateway. I need to somehow get the internal traffic to go through the VPN acquired IP. Any suggestions?

Also, to avoid conflicts I made sure my internal network IP's are different from my company's internal IP's.

Thanks,

Lucian

[dpatkins]

Lucian,

Some things I would consider. Do you ahve the lastest firmware on your router? Do you have IPSec passthrough enabled on the DLink? Do you have UDP port 10000 and/or UDP port 4500 opened on your firewall if indeed you do go through one? In your static routes, do you have your default route going to the next hop up? Hope this helps.

[patricklaupt]

Hi Rick,

First of all, let me say that my problem is not exactly the same as Lucian's. So, if I am interrupting this thread, my apologies. If my post is not appropriate here, please reply by email to patrick@computerbrokers.com.sg.

Now, to answer your questions. All the clients that came through VPN have the same problem. And my network is really very simple. Something like:

ISDN router -> LAN -> PC1

|

|--> PIX -> Hub -> PC2

The PIX is 10.1.1.1 on the inside.

After authenticating, PC1's IP is 192.168.1.1.

I did a few traces from PC1 (after authenticating), and I noticed that the default gateway for 10.1.1.x is my ISDN router. I think this cannot be right. Any idea on what I have missed?

Thanks,

Patrick

[Richard Burts]

Patrick

I do not think that your messages in this thread are inappropriate. If you wanted to start a new thread so that your issue would be more clearly identified, that would be ok or I am content to keep going with this one.

I am still not clear about the topology of your network not about what does not work. If I understand your drawing the ISDN router has one interface to a LAN where PC1 is located and another interface which connectes to the PIX. I am assuming that the PIX has one interface connected to the PIX and another interface connected to the Hub and PC2. I am not clear which is inside and outside for the PIX.

It would help me understand if you could indicate addresses for the ISDN router interfaces, PIX interfaces and PC2.

HTH

Rick

[patricklaupt]

Hi Rick,

Thanks for continuing the discussion. I really appreciate your help.

You are right about the topology: from the ISDN router I have two links, one goes into a hub (thus PC1) and the other goes into the PIX. From the PIX, there is one link going into another hub (thus PC2).

Let me try to "draw" a better picture of my topology here:

ISDN router (192.168.0.1) -----> PC1 (192.168.0.x)

|

|

| (outside 192.168.0.111)

PIX (inside 10.1.1.1, VPN ip pool is 192.168.1.x)

|

|

HUB

|

|--> PC2 (10.1.1.x)

I am using PC1 as the client to connect to the PIX. Once authenticated, PC1 gets an IP (say, 192.168.1.1).

- From inside the PIX console, I can ping PC1

- From PC1, I cannot ping/telnet/etc to PIX or PC2

- From PC2, I cannot ping/telnet/etc to PC1

Just FYI, I have actually tried to use the same ip range for the ip pool as the inside interface of the PIX (i.e., ip pool is 10.1.1.x), but the result is the same.

I have also attached the PIX config. Again, thanks for your help.

Patrick

[patricklaupt]

Hi Rick,

I think I understand what you said about IP not broadcasted properly.

Recall that 192.168.1.x is my pptp ip pool, and 10.1.1.x is the ip range behind the PIX. Now, after authentication, I added "route add 10.1.1.0 mask 255.255.255.0 192.168.1.1 metric 1" to the PC client. With that, I am able to ftp/telnet to other machines on the 10.1.1.x network.

This solves part of the problem because the address 192.168.1.x is dynamically assigned to the PC client. Instead of asking the users to look for the assigned ip and type the "route add" statement everytime, what can I do to make the connection automatic?

Many Thanks & Regards,

Patrick

[lucian01]

Thanks to all for their input. I upgraded my router firmware and reset my DSL settings.

Thanks,

Lucian

[shaun.oliver]

Good to hear that it's now working.

It sounds like the problem is that NAT-T isn't enabled on your central PIX/router. Upgrading your DSL router (no doubt to add IPSec passthrough) is a workaround, but other users might have the same problem.

If you need to enable NAT-T on a PIX, use "isakmp nat-traversal 20". For a router, you'll need to use a recent IOS (as it's then enabled by default).