"IPSec over TCP" issue.

[michael.leblanc]

We are currently accessing a c1710 (c1710-k9o3sy-mz.123-4.T3.bin) through a PAT enabled c806 (c806-k9osy6-mz.123-4.T3.bin) with "IPSec over NAT-T" (UDP port 4500) enabled on a Cisco VPN Client v3.6.3.

We would like to use "IPSec over TCP" but have experienced problems.

The VPN Client is configured to use the default TCP port of "10000".

The connection attempt is being reset by the ingress interface on the c1700, despite an entry (permit tcp any gt 1023 any eq 10000) which permits the connection.

We've seen VPN Concentrator and PIX documentation indicating how to define the TCP port on those platforms, but have not encountered any such references for the IOS Routers.

Is the "IPSec over TCP" feature supported on IOS routers?

Is the TCP port configurable on the IOS routers?

Is the connection being reset because we have not bound this port (10000) to the "IPSec over TCP" feature?

Regards,

Mike

[Richard Burts]

Mike

At a customer site where I help support VPN we have some users who are doing IPSec over TCP. To support this we open a range of TCP ports not just port 10000. I suggest that you change your access list to:

permit tcp any gt 1023 any range 10000 10004

Try this and let us know what happens.

HTH

Rick

[michael.leblanc]

Rick:

There was no change to the VPN Server's (c1710) behavior, or the vpn client's (v3.6.3).

The client only attempts a TCP connection (SYN flag set, window size 65535) on port 10000, and the server responds with the RST and ACK flags set.

Syslog doesn't convey anything of interest.

I found a note in the VPN 3000 Series Concentrator Reference Volume I: Configuration | Chapter 7 | Tunneling Protocols that was interesting. I don't know if my situation is related.

It reads: IPSec over TCP is a TCP encapsulation rather than a full TCP connection. In software versions prior to 3.6.7.B, the VPN Concentrator did not limit data transmission by window size, so sometimes stateful firewalls shut down the TCP session. In software versions 3.6.7.B and later, the VPN Concentrator enforces a 64K window size on the connection to avoid connection shutdown. As a result, large data transfers might result in packet loss of end-to-end data. The VPN Concentrator does not retransmit dropped packets; the peer application must detect the dropping and recover from it. If you are running UDP streaming applications such as video or voice, you might notice choppy transmission.

Thanks for the response.

Regards,

Mike

[Richard Burts]

Mike

I am not positive but I do not think that your situation is related to the paragraph you quote from the documentation.

You say that the client sends TCP with SYN and window size 65535 and server responds with RST and ACK. Are you seeing this in a packet capture (Sniffer or whatever)? If so where is the capture device located? At a customer site I have had experiences where a client would send a TCP SYN and receive a RST which appeared to come from the destination but which in fact was generated by a firewall in between. Is there any possibility that a firewall is between your client and server and may be generating the RST?

HTH

Rick

[michael.leblanc]

Rick:

The external interfaces of the VPN Server (c1700) and the NAT router (c806) being traversed by the VPN Client initiated tunnel, are on the same collision domain (i.e.: connected with a hub, to aid diagnosis).

The connection attempt has been captured with Ethereal, and the source MAC address examined to ensure that the return packet with the "RST, ACK" flags set is coming from the external interface of the VPN Server (c1700).

When viewing the the acl applied to the external interface of the VPN Server (c1700) with the "sh" command, the "matches" count increments for the entry (permit tcp any gt 1023 any range 10000 10004) with each inbound connection attempt on port 10000.

The connection attempt has also been captured and examined on the internal collision domain where the VPN Client resides. The return packet from the VPN Server (RST, ACK) makes it back to the VPN CLient.

Do you know of any IOS commands that permit modification of the "IPSec over TCP" default port on the VPN Server?

Regards,

Mike

[mnlatif]

I don't think that IOS software support "IPSec over TCP", so that is why the VPN Server is not "listening" on port 10000 and sends a RST, when it receives a SYN on that port.

\\ Naman

[michael.leblanc]

Naman:

I suspect your right about the feature support on the IOS platform, but I'm still hoping, as it is a feature we'd like to implement.

If I get confirmation from Cisco on this, I'll pass it on via post.

Thanks for the feedback.

Mike