TCP connection won't stay open through PIX

[JMCraig]

Hi Folks,

I've got a really simple setup with a PIX 501 protecting a little 8-IP public subnet. Each of the five boxes behind the PIX has it's own public IP address (the ISP is handling the routing to the subnet via a single address that the PIX hooks up with via DHCP). In general, this works great. I have various services on the boxes behind the PIX and there's no problem making connection to them.

But, I need some of my colleagues to get to port 2000 of one of the protected boxes and I've got an ACL entry for the service group I've defined for that port. There's a web service using JSP on that same box and the ACL entry was all I needed to add to what was already defined for that to work. But with the port 2000 service, when I try to connect through the port, I get this kind of built/teardown pattern from the PIX debug output (it seems to be closing the socket rather than using it):

302013: Built inbound TCP connection 845 for outside:166.70.26.159/10106 (166.70.26.159/10106)
to inside:204.x.x.131/2000 (204.x.x.131/2000)
302014: Teardown TCP connection 845 for outside:166.70.26.159/10106 to inside:
204.x.x.131/2000 duration 0:00:01 bytes 638 TCP FINs
302013: Built inbound TCP connection 846 for outside:166.70.26.159/10107 (166.70
.26.159/10107) to inside:204.x.x.131/2000 (204.x.x.131/2000)

If I run ethereal on the client box, I get nothing that seems like it should close the TCP socket (see below). When I attempt to connect from a box on the same subnet as the host, ethereal shows all the communication on the same port that's first established as the client endpoint for dozens packet exchanges (with total traffic way beyond 638 bytes). Ultimately, it also opens a second socket too, but the first connection stays live throughout.

Here's the pattern of packets recorded by ethereal on the client when it can't connect (the client is behind a DSL modem that does PAT so that's why the port numbers are so different than what the PIX sees--in case anyone wonders):

Client IP to 204.x.x.131 TCP 1759 > 2000 [SYN]
204.x.x.131 to Client IP TCP 2000 > 1759 [SYN, ACK]
Client IP to 204.x.x.131 TCP 1759 > 2000 [ACK]
Client IP to 204.x.x.131 TCP 1759 > 2000 [PSH, ACK]
204.x.x.131 to Client IP TCP 2000 > 1759 [TCP Previous Seg Lost]
Client IP to 204.x.x.131 TCP 1759 > 2000 [TCP Dup Ack 3#1]

So, the communication breaks down after getting going. Is there an option that controls TCP sockets that I've got set wrong?

Here's what I see when it all works:

Client IP to 204.x.x.131 TCP 2694 > 2000 [SYN]
204.x.x.131 to Client IP TCP 2000 > 2694 [SYN, ACK]
Client IP to 204.x.x.131 TCP 2694 > 2000 [ACK]
Client IP to 204.x.x.131 TCP 2694 > 2000 [PSH, ACK]
204.x.x.131 to Client IP TCP 2000 > 2694 [ACK]
Client IP to 204.x.x.131 TCP 2694 > 2000 [PSH, ACK]
204.x.x.131 to Client IP TCP 2000 > 2694 [ACK]
204.x.x.131 to Client IP TCP 2000 > 2694 [PSH, ACK]
/* they've now exchanged encryption info and things proceed. After a dozen more packet exchanges, a connection is opened to the client port 2695 and then traffic is exchanged on both sockets.
*/

As noted above, I have a test setup to a web service on the same box and it works just fine. There's also a database service on the same box that is very touchy about connections dropping and it has no trouble.

Is it possibly something about the port number (which is listed as "Skinny" in a predefined service group)?

Any suggestions as to what else might need adjustment to allow the TCP socket to stay open would be much appreciated.
Thanks,

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com

 

[JMCraig]

Well, on the advice of the vendor of the service product, I removed the entry for 2000 from the Skinny fixup. That solved it.

Can anyone give me some insight into why that would be? Uh, what's the Skinny [fixup]?

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com

 

[JMCraig]

Skinny is a VOIP protocol (proprietary to Cisco, apparently). With the fixup in place, it's not happy with HTTPS traffic apparently. Here's a decent reference:

http://www.javvin.com/protocolSCCP.html

John

John Craig
Alpha-G Consulting, LLC

http://www.alphagconsulting.com

 

[chicocouk]

I would suggest to the vendor who wrote the web app to move their product to a different port number. There will be considerably more people using VoIP than this webservice, and they're only going to run into problems with various firewall vendors enforcing protocol checking on this port.

Fixup is used on a pix to do application layer inspection of the traffic, determined by the port number. So you can check that SMTP traffic contains only the minimum required commands for SMTP to flow (as defined in the RFC), by issuing using the smtp fixup, and so forth.

Fixup skinny checks that traffic on port 2000 conforms to the SCCP protocol. The web app obviously doesn't, so the pix drops it. You'll have no problems disabling skinny fixup, assuming you don't want to use Cisco IP phones at your site. But the vendor of the web app should seriously consider using another port.

CCSP, CCNA, CCSA, MCSE, Cisco Firewall specialist, VPN specialist, IDS specialist