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.
Best Answer
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
capturelook 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 conncommand on the ASA set to?