PIX 515E dropping existing TCP connections

I recently took over administration of a PIX 515E. I think I have a good understanding of networking and VPNs, however I've never dealt with Cisco devices before, so please forgive me if I use any incorrect terminology or ask any silly questions.

The problem we're having is that the PIX seems to drop connections that use more than a tiny bit of bandwidth. I have a workstation on a public network, and VPN to the PIX to access a private network. I believe that this is called "split tunneling."

When the VPN is connected, I can SSH to hosts on the private network. This works fine for simple command line sessions. However, when I try to copy files over SSH (using scp) to the hosts on the private network, the PIX drops the connection after transferring just a few kilobytes.

Since both the command line sessions and scp are running over the same port to the same host, the only difference I can see is that scp requires a lot more bandwidth. That is why I suspect that the PIX is dropping connections that use more than a tiny bit of bandwidth. When the connection is dropped, I see the following message in the PIX's log:

302015: Built inbound TCP connection 45281 for outside:10.100.3.116/54568 (10.100.3.116/54568) to inside: 10.100.14.2/22 (10.100.14.2/22) 110001: No route to 128.36.236.149 from 128.36.236.114

In the above, 128.36.236.149 is my workstation, 128.36.236.114 is the public address of the PIX, 10.100.3.116 is the VPN address of my workstation, and 10.100.14.2 is the host on the private network that I am connecting to. Obviously there is a route between 128.36.236.149 and

128.36.236.114, otherwise the VPN wouldn't work at all. The "no route" message repeats itself several times.

I have another issue that may or may not be related. There is a switch on the private network that uses a web interface for administration. When I am connected to the VPN, I can get to the login screen of the web interface of the switch, however as soon as I click "login", the PIX drops the TCP connection entirely. At that point, this message shows up in the PIX's log:

106015: Deny TCP (no connection) from 10.100.3.116/39576 to 10.100.14.200/80 flags PSH ACK on interface outside

10.100.3.116 is my workstation's VPN IP, and 10.100.14.200 is the switch on the private network that I am trying to use the web interface of. Obviously if I can get to the login screen of the switch, I am able to access 10.100.14.200 port 80 from 10.100.3.116 without being denied. I don't understand why the PIX would then deny the same connection at a later time.

Any help with these issues would be greatly appreciated. I apologize if I mistyped any of these log messages.. by the way, is there a way to copy and paste log messages from the Windows Cisco ASDM client? I can't seem to figure out how to do it...

Reply to
Jim Faulkner
Loading thread data ...

I have sometimes seen this if Path MTU Detection is not permitted. The simple commands often only require packets of less than maximum size; higher bandwidth corresponds to greater probability that you will attempt to pass a maximum size packet. If Path MTU Detection is not permitted then that may fail because of the extra overhead required for encapsulation. There is related command having to do with tcp mss adjustment that should be enabled.

I have seen something like that if the VPN address pool is the same as the internal IP address range.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.