2

Following up from a previous question regarding how to capture packets on the ASA5505 I'm having some difficulty in distinguishing which traffic has come through the VPN and which was generated from the firewall itself.

To outline the problem, I have an application that connects to a telnet server over a vpn and it is receiving reset packets when it sends data after the connection has been idle for a while. I'd like to work out where these resets originate from; either it's the router/telnet server on the other side of a VPN or whether it is in fact the ASA5505 my side that the application server is behind. I've read about the ASA series dropping connections due to a low default timeout and am hoping this is the issue.

I've captured packets on the app server to identify the resets. I've now captured packets on the inside interface of the firewall and the resets are there too. What I'm unable to do is capture the packets coming out of the VPN tunnel to see if they're there too. I've tried capturing all packets on the outside interface but there are no any packets at all, so I'm guessing the VPN data cannot be captured via the outside interface. Does anyone know how I can capture the packets as soon as they come out of the VPN tunnel?

To capture the packets on the inside I've matched on the telnet server as source:

capture capture1 interface Inside match tcp 171.28.18.50 255.255.255.255 any

In an attempt to capture packets on the outside I've matched any source/dest that's not the ssh connection I've established to monitor the capture:

capture capture2 interface Outside match tcp any neq 22 any neq 22

The timeout conn line in the config is:

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

Update: Following the suggestion by Shane Madden I captured ESP packets and have now established that the reset is definitely generated by the ASA. I'm now going to try to increase the timeout conn

Update: I've not yet increased the timeout conn but have monitored the VPN connection using the graph in ASDM and it seems that when it's been idle for 30 minutes the tunnel is closed. I'm suspecting the when it's closed the TCP connection is broken and upon sending more data on the connection after an hour the ASA responds with the reset. 30 minutes is the default for vpn-idle-timeout. When I run show run | include vpn-idle-timeout I get nothing back so hopefully just need to work out how to set the vpn-idle-timeout variable.

Community
  • 1
James
  • 325
  • 2
  • 10
  • 22

3 Answers3

2

ESP packets should capture just fine - they just won't be very helpful in terms of seeing whether there's a reset, since they're still encrypted (what's the ACL or match statement on your capture look like?).

Trying to match ESP packet timestamps to reset packet timestamps is the best way I can think of to determine if the ASA's generating the resets.

Dumb question: what's your timeout conn command on the ASA set to?

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Hi Shane. Thanks very much for your answer. I'd not heard of esp packets before, I'll definitely give that a go and match timestamps. Is there a 1-1 relationship between esp and tcp packets? I've now updated my question to include the capture and timeout info. – James Jul 13 '11 at 00:04
  • 1
    ESP packets are the tunneled traffic; they won't show up in your capture because you're catching only TCP. Use `match 50 any any` to catch ESP. There will be more ESP packets than TCP packets, for VPN overhead such as dead peer detection and (infrequent) rekeying. That `timeout conn` line seems mighty suspicious, given the "about an hour" from your other question; try turning that up to 2 hours or higher? – Shane Madden Jul 13 '11 at 00:35
0

Is this line from the actual configuration of the ASA?

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

If so, then that's your answer, it's the firewall. TCP doesn't implement any mechanism to determine if a connection is still alive or not (that I'm aware of) so the client and server should, in theory, be perfectly content to maintain the session even if no data is flowing. Either one may implement TCP keepalives but that would have the opposite affect of what you're seeing. A TCP keepalive from either side would cause the firewall to see the connection as active.

The normal termination of a TCP connection would be for the host that initiated the connection to send a FIN to the other end, resulting in a half-closed connection from the initiating side's perspective and (barring any problems) the TCP connection will proceed through the close process. This is a graceful process and won't cause a TCP RST. If one side of the connection crashes this will result in a half-open connection but again, neither side can detect this (that I'm aware of) so no RST will be issued, except by the firewall. Neither side should send a RST due to a long idle connection unless the software on either side (telnet client software or telnet server software) is programmed to issue a RST or some type of terminate command for long idle connections.

As a test (and to be able to capture on the external interface of the firewall) you might consider establishing a telnet session to another server (if available) that doesn't transit the VPN connection and let it sit idle. You could also probably test by establishing an FTP connection to an external server that doesn't transit the VPN connection and let it sit idle. If you see the same RST behavior then I think it's a safe bet that the firewall is the cause.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • The timeout line is from my config on the ASA. What makes you say that's the cause? I think the conn field can take 0 as a param to make connections infinite but that could be risky on stability? I like your idea of trying to replicate the error on another telnet server that's not on the VPN, I'll set one up today and see how it goes. – James Jul 13 '11 at 08:51
  • I'm saying it's the firewall because of the conn 1:00:00 setting. If I'm undersdtanding that right, it means that connections are terminated after 1 hour. Is that right? This article seems to imply as much, although it states that this doesn't apply to an IPsec VPN environment (not quite sure what that means). http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080624e19.shtml – joeqwerty Jul 13 '11 at 10:58
  • I'm not sure. If the fix for `vpn-idle-timeout` works I'll try leaving it idle for 1:01:00 and see if I get the reset. Having said that if IPsec VPNs aren't affected then it might not prove anything I suppose – James Jul 13 '11 at 11:30
0

Have you looked at applying a TCP timeout on the connection between the app server and the telnet server? I would try applying it on your ASA's interface closest to your appserver, after you've test it.

Here is an example: access-list no_tcp_timeout extended permit ip object appserver object telnetserver

class-map no_tcp_timeout match access-list no_tcp_timeout

policy-map dmz_policy class no_tcp_timeout

service-policy dmz_policy interface dmz

Tim
  • 106
  • 4