ASA blocking telnet return traffic?

[geolchris]

Hello all,

I'm having an issue where I am connecting to a remote site with a telnet device behind a router.

Attempting to connect via my corporate network (with a Cisco ASA5515 9.8(2)) does not succeed.

When I hop onto my phone as a wifi hotspot, I am able to successfully connect.

I have run wireshark on both connection attempts, and on the unsuccessful attempts I see: (times are approx and my port is representative, and the filter is to view all traffic with source or destination of my target)

1    0.000    SOURCE    DEST    TCP    54743 > 23 SYN
2    0.400    DEST    SOURCE    TCP    23 > 54743 SYN,ACK
3    0.450    SOURCE    DEST    TCP    54743 > 23 ACK
4    10.000    SOURCE    DEST    TCP    54743 > 23 FIN,ACK
5    10.100    DEST    SOURCE    TCP    23 > 54743 ACK
6    10.700    SOURCE    DEST    TCP    54743 > 23 SYN
7    11.000    DEST    SOURCE    TCP    23 > 54743 FIN,ACK
8    11.200    SOURCE    DEST    TCP    54743 > 23 ACK

And then it repeats until the program I'm using to connect times out.

Successfull attempts on wifi hotspot see:

1    Same
2    Same
3    Same
4    0.455    SOURCE    DEST    TCP    54743 > 23 PSH,ACK
5    0.500    DEST    SOURCE    TCP    23 > 54743 PSH,ACK
6    0.501    DEST    SOURCE    TCP    23 > 54743 ACK
7    0.600    SOURCE    DEST    TCP    54743 > 23 ACK

...and connection has been established.

Where should I start looking on my ASA for what could be blocking this? It almost seems to me like it's a NAT error, or some error in letting data flow, but the handshake is clearly getting through and not being blocked.

Let me know if you need to see the actual pcap files, and/or if you want details on the ACL's on the ASA.

Thank you much, in advance.

[Ajay Saini]

Hello,

The good thing is that the 3-way handshake is happening so that part is okay.

Now, coming to non-working captures, the 4th packet is where the client sends a fin-ack. Are these captures taken on the client or the ASA inside interface. Can you please attach the captures from the client machine for working or non-working scenario. 

Ideally, ASA does not inspect the telnet packet, so that part is out.

HTH
AJ

[geolchris]

Those captures were taken on the client with wireshark, captures from the ASA on inside show the same.

Here's client side captures for both working (via hotspot) and non-working (via asa).

Your mention that the ASA doesn't inspect telnet pinged something in my mind, the far end router is doing port translation from 2000->23, so you'll see all connections being attempted to 2000. Perhaps that is part of the issue? The far side was set up by the manufacturer that way, I can see if I can change that if needed.

[geolchris]

The other interesting aside is that ping to that device also does not work over our corp network.
There may be larger issues at play here...

[Ajay Saini]

Hello,

Just checked both working and non-working captures. Looks like something happening at far end (router side). In the working captures, the push ack (data) is send by the server from router side in 4th packet.

In non-working one, there is no packet sent back, and hence client closes the connection gracefully by sending a fin-ack in 4th packet as seen in wireshark captures. 

Is the other side running router with ZBF or CBAC? Could be something on other side that is preventing the data coming to our side. Worth checking on router config.

HTH
AJ

[geolchris]

That's my initial thoughts as well, but it's hard for me to not single out our corporate network as the culprit since I am able to connect to the unit from any other network.

That being said, I have not tried an ASA that doesn't have our corp settings on it, I'll spin up my lab tonight and try that.

The far side is a sierra wireless RV50. Another oddity, we have 11 units that are running an older modem, the Raven XE, and they don't have any issues. I'll have to get in touch with Sierra Wireless again and see what they have to say this time.

Thanks for the help!

[geolchris]

This ended up being very helpful, actually - as it pushed me away from looking at my config.

The other end as mentioned was a Sierra Wireless AirLink RV50. It had Proxy ARP enabled for some reason. I disabled that and was able to successfully connect.

[Ajay Saini]

Great. Happy to help.

**Please mark the post as helpful or mark the solution as accepted if it helped.

Regards,

AJ