Debug VPN telnet problem

[gary.wilcox]

I have a CISCO 1711 security router serving as a firewall to the Internet and as a VPN server for client connections. I am trying to troubleshoot a telnet problem and am having trouble with debug. Using a PC and the CISCO VPN client I make a connection to the router via the Internet (no problems). I am able to ping inside hosts, use http to a web server but am unable to telnet. I want to use DEBUG on the router to see whats going on with the telnet packets but when I do a debug packet detail I don't seen any telnet traffic. I setup a packet sniffer on the inside network and can see the telnet syn packet from the PC and a syn ack from the server but then I get a rst from the pc. Any ideas? Telnet works fine when I'm directly connected to the inside network.

[ehirsel]

Try using the debug ip packet command. So that you can capture what you want use the acl option to capture traffic to and from the vpn client.

Here is the syntax:

[no] debug ip packet [access-list-number] [detail] [dump]

One thing to look at is if NAT is being used? Do you bypass NAT for the vpn clinets? In the sniffer trace, are the source and dest addresses correct in the syn and syn-ack frames? What about the reset frame? If you still have problems, post the relevant parts of the 1711 config and what you see in the sniffer and the debug ip traces, and I will try to help.

[gary.wilcox]

As I mentioned. I tried using debug "debug ip packet detail" and saw no telnet traffic. I am using NAT but have an exclusion for the VPN pool of addresses.

The source and destination addresses are correct in the sniffer trace. Even if the frames were being NAT'ed wouldnt the sniffer trace show the correct source and destination addresses?

I will post my config this evening.

Thanks

Gary

[erickflamenco]

1 Check for server's deafault gateway

2 See if you are not spliting telnet traffic outside the tunnel.

Erick

[gary.wilcox]

The servers default gateway is correct. I can ping it without problems.

How would I determine if I am splitting telnet traffic outside the tunnel.

Thanks

Gary

[erickflamenco]

1 Check for server's default gateway

2 See if you are not spliting telnet traffic outside the tunnel.

Erick

[erickflamenco]

1 Check for server's default gateway

2 See if you are not spliting telnet traffic outside the tunnel.

Erick

[Richard Burts]

In your message you say that when you run debug you do not see any telnet traffic. I can not tell whether that means that you do see some output but not output for telnet or if you do not see any debug output.

If you do not see any debug output, one thing to be sure of is that you have entered the command terminal monitor so that your session will receive the debug output.

Another thing to look at is how you turned on debug. Do I assume from your post that you did a debug ip packet detail? Did you use the access list option to limit the output? If so there is the possibility that the access list was not set up correctly and may be supressing the telnet output. Perhaps you can tell us specifically how you turned on the debug.

Another possibility to consider is that if the telnet packets are in the fast switching path then debug will not see them. It might be necessary to force the router to process switch (using the interface command no ip route-cache) while you are running debug. If you do this be sure to set it back to whichever switching mode it was originally in when you complete your testing.

If the sniffer sees syn and syn/ack then we know that there is correct IP connectivity between the devices. If that is followed by rst then there is some reason that the PC chooses not to fully open the telnet connection. There is a possibility of some parameter mismatch between the devices. Or the possibility that the syn/ack is not making it all the way back to the PC.

HTH

Rick

[gary.wilcox]

I don't see any telnet traffic when using the debug ip packet detail command. With debug running I can see all other traffic http etc but no telnet. I tried debug using a telnet only access-list but when I didn't see any traffic I just used "debug ip packet detail"

I will try "no ip route-cache"

Since the PC seems to work fine (telnet) when connected directly to the inside network, I am wondering if the router is sending the RST.

I will try to setup a sniffer on both ends to see if I can tell where the RST originates.

[gary.wilcox]

I set no ip route-cache on both the inside and outside interface. I am now able to see the telnet session with the "debug ip packet detail" command. I can see the SYN packet arrive from the VPN client to the server. It has the VPN pool source address 192.168.10.47 and the correct destination address. The return packet from the server (SYN ACK) seems to take a different route back to the client. It goes from the outside interface of the router directly to the dynamic IP of the VPN client - like it is routed outside of the tunnel. How does the router know how to route the VPN traffic? When I do a "show ip route" the only routes are the directly connected inside network and the outside network. With a default route to the ISP's router.

[Richard Burts]

One thing that could produce the symptoms that you describe is that the router does not think that the telnet SYN ACK response qualifies as traffic to be sent through the tunnel. If you see the packet go out the outside interface, do you see a TCP telnet (port 23) packet or do you see an ESP (protocol 50) packet. If it is a TCP packet then it is being sent outside the tunnel and the PC would reject it.

Perhaps you can look carefully at how you define traffic on the router for VPN. If you do not find anything perhaps you can post that part of the config.

HTH

Rick

[gary.wilcox]

I found the problem. It turned out to be a NAT problem. I had a static NAT mapping to allow incoming connections to our mail server from the Internet. I added an exclusion for the VPN pool of addresses and all is working.

Thanks for all the help

Gary