Re: Is it possible to ping virtual telnet ip address?

Adam David · ‎08-25-2010

Refer to document below, I have simple question about virtual telnet.

PIX/ASA : Cut-through Proxy for Network Access using TACACS+ and RADIUS Server Configuration Example

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00807349e7.shtml#acess

Is it possible to ping virtual telnet ip address?

I have one case where user unable to authenticate into virtual telnet. Normally he only need to authenticate to the virtual ip before he allowed to do other thing.

What happened is when he telnet into virtual ip, nothing happened and time out after a few minutes.

I did packet capture on the firewall and I can see SYN packet sent to the firewall.

Firewall reply with SYN ACK to the user.

However, there is no ACK packet from the user.

This SYN, SYN-ACK traffic keep repeating.

Any advise would be highly appreciated.

Thanks

Jennifer Halim · ‎08-25-2010

Unfortunately virtual telnet ip address will not respond to ping, because the only protocol/port that it is listening on is just telnet (ie: tcp/23).

From the description that was given so far, looks like the firewall is responding with a SYN-ACK, however, the host does not ACK back for whatever reason.

Adam David · ‎08-25-2010

Thanks so much halijenn for your reply. I appreciate it so much.

Yes, you are right. Firewall is responding with a SYN-ACK, however, the host does not ACK back for unknown reason.

This process is keep repeating.

There are a few possibilities that I can think rite now.

1. SYN-ACK reply packet from firewall unable to reach the user. So, user assume that SYN packet sent by him was failed, and he tried to send it again. That's why we will see this process is keep repeating.

2. Probably SYN-ACK reply packet from firewall was blocked somewhere else, in the middle of journey between firewall and the user.

ASA5510 <------> Cisco Router <------> Leased Line <------> Third Party Router <------> Third Party Firewall <------> User

Let me give more details about this case. I'll use ip specified in RFC 1918 as example.

User : 192.168.1.10

Virtual Telnet : 172.16.1.10

I've performed packet capture and test it with the user. Below is the test result.

asa5510# sh access-list | i cap
access-list capi; 2 elements
access-list capi line 1 extended permit ip any host 172.19.1.10 (hitcnt=3) 0x5607784a 
access-list capi line 2 extended permit ip host 172.19.1.10 any (hitcnt=0) 0x1cf0ce5a 
access-list capo; 2 elements
access-list capo line 1 extended permit ip any host 172.19.1.10 (hitcnt=6) 0x6f3c4ae7 
access-list capo line 2 extended permit ip host 172.19.1.10 any (hitcnt=3) 0x24338ef6

asa5510# sh cap 
capture capin type raw-data access-list capi packet-length 54 interface inside [Capturing - 210 bytes] 
capture capout type raw-data access-list capo packet-length 54 interface outside [Capturing - 630 bytes]

asa5510# sh cap capin 

3 packets captured
   1: 00:37:46.669063 192.168.1.10 > 172.16.1.10: [|icmp] 
   2: 00:37:52.240893 192.168.1.10 > 172.16.1.10: [|icmp] 
   3: 00:38:04.240557 192.168.1.10 > 172.16.1.10: [|icmp] 
3 packets shown

asa5510# sh cap capout

9 packets captured
   1: 00:37:46.641019 192.168.1.10.1298 > 172.16.1.10.23: S 916998597:916998597(0) win 65535 <[|tcp]> 
   2: 00:37:46.641370 172.16.1.10.23 > 192.168.1.10.1298: S 184272433:184272433(0) ack 916998598 win 8192 <[|tcp]> 
   3: 00:37:46.668910 192.168.1.10 > 172.16.1.10: [|icmp] 
   4: 00:37:49.597549 192.168.1.10.1298 > 172.16.1.10.23: S 916998597:916998597(0) win 65535 <[|tcp]> 
   5: 00:37:52.212971 172.16.1.10.23 > 192.168.1.10.1298: S 184272433:184272433(0) ack 916998598 win 8192 <[|tcp]> 
   6: 00:37:52.240771 192.168.1.10 > 172.16.1.10: [|icmp] 
   7: 00:37:55.627058 192.168.1.10.1298 > 172.16.1.10.23: S 916998597:916998597(0) win 65535 <[|tcp]> 
   8: 00:38:04.212833 172.16.1.10.23 > 192.168.1.10.1298: S 184272433:184272433(0) ack 916998598 win 8192 <[|tcp]> 
   9: 00:38:04.240420 192.168.1.10 > 172.16.1.10: [|icmp] 
9 packets shown

Is there anything I should do? Please let me know if you need more info. Thanks

Kureli Sankar · ‎08-25-2010

How about a quick wireshark capture on the client PC to see if the SYN ACK from the ASA arrives.

If the SYN ACK is not seen on the client then

ASA5510 <------> Cisco Router <------> Leased Line <------> Third Party Router <------> Third Party Firewall <------> User

start at the Cisco router and find out if there is a route to reach the destination 192.168.1.10. Repeat the same - route checking on the Third Party Router and third party firewall.

-KS

Adam David · ‎08-25-2010

Thanks kusankar for your advise. I've checked the Cisco Router and confirmed that the route is there.I will check with Third Party to see whether they have correct configuration (routing, access-list) on their routers & firewalls.

Traceroute from Cisco Router end at Third Party Router which I don't have control to it. Looks like everything is good at our side. What do you think

Wireshark capture at user's pc is a very good idea, however, I don't control to the user due to it was located at Third Party and user also from Third Party site. I need to get third party to do this.

I have one more question. User is only perform normal telnet to the virtual ip from his windows client.

Why icmp traffic appear in the log?

Jennifer Halim · ‎08-25-2010

You are absolutely right. Seems like your end has been correctly configured and the firewall is responding with SYN-ACK.

In regards to ICMP, i suspect that user also tests ping hence you are seeing that on the firewall capture. As firewall is only capturing traffic off the wire before any inspection is performed.

Adam David · ‎08-26-2010

Yup, that's what I thought when I saw the log. But after I contacted the user directly and guide him how do it. He only do

telnet

that's it. No ping at all