cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
640
Views
0
Helpful
3
Replies

Traffic not returning to remote VPN connections

james.davis
Level 1
Level 1

I've successfully setup remote VPN connections to my ASA using vpnc as the client and everything behaves as expected. I'm trying to test the official Cisco client and I'm unable to make the same SSH connections across the VPN as I was using vpnc.

The ASA shows connections the IKE and IPSec connections forming, and shows connections being built for the SSH traffic across the VPN.

tcpdump shows the host listening on SSH behind the ASA receiving the traffic and sending ACKs in reply. They don't appear to be arriving back

at the remote client though, and SSH connections timeout without connecting.

Any idea what might be stopping the return traffic? I thought it might be some policy the ASA is pushing out to the Cisco client but not to vpnc but I can't spot anything obvious.

3 Replies 3

kerek
Level 4
Level 4

Hi,

Did you excluded the VPN traffic in NAT?

Because the traffic sent back by the inside host shouldn't be translated.

Can you post the config?

Krisztian

michael.leblanc
Level 4
Level 4

Is the internal SSH host you are connecting to sending ACKS (as you've stated), or SYN/ACKs?

It might be nice to know if the TCP three way handshake is being completed, and subsequent packets are the issue, or if it's the initial TCP setup that is the issue.

Perhaps there would be some benefit in confirming whether these packets are making it through the IPSec tunnel, though the ASA un-encapsulated, or not through the ASA at all.

You could use Wireshark to look for un-encapsulated packets exiting the ASA.

You could use Wireshark to capture the "pre-encapsulated" traffic being sent to the far side, and the "post-decapsulation" traffic returning from the far side, by capturing on the Cisco VPN Client virtual interface (Windows installation).

Perhaps examine IPSec SA details on the ASA and look for errors.

Perhaps logging on the internal interface ACL (log any packets denied) to identify whether the returning packets are being dropped.

I currently believe that the problem is due to the behavior of NAT-T when ESP is blocked by a firewall rule but NATing doesn't take place. See

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Virtual%20Private%20Networks&topic=General&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cc09484

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: