topic Re: PIX error 106015: Deny TCP (no connection) flags PSH ACK in Network Security

PIX error 106015: Deny TCP (no connection) flags PSH ACK

limtohsoon — Fri, 21 Feb 2020 08:24:55 GMT

Hi Sir,

I have a server which is behind a PIX 525 (OS version 6.3(3)). Clients on other segments connect to an application on this server, which is actually HTTP on a non-standard port. The connection always fails and I get the following system log message on the PIX:

106015: Deny TCP (no connection) from 10.219.58.83/35528 to 10.219.126.72/2061 flags PSH ACK on

interface DMZ

I found an explanation on cisco.com at the following URL:

http://www.cisco.com/en/US/partner/products/sw/secursw/ps2120/products_system_message_guide_chapter09186a008051a0cd.html#wp1052198

----------------------------------------------

106015

Error Message %PIX-6-106015: Deny TCP (no connection) from IP_address/port to

IP_address/port flags tcp_flags on interface interface_name.

Explanation This message is logged when the firewall discards a TCP packet that has no associated connection in the firewall unit's connection table. The firewall looks for a SYN flag in the packet, which indicates a request to establish a new connection. If the SYN flag is not set, and there is not an existing connection, the firewall discards the packet.

Recommended Action None required unless the firewall receives a large volume of these invalid TCP packets. If this is the case, trace the packets to the source and determine the reason these packets were sent.

----------------------------------------------

A sniffer was run on the client to capture packet trace when it accesses the server. The TCP 3-way handshake was successfully done. But when the client was asking for data from the server, the client set the PSH bits. As far as I know, the PIX is correctly configured and "permit ip any any" is temporarily configured on the ACLs to troubleshoot the problem.

I'd like to know what's the real cause of the problem? Is it PIX configuration error or is it the app not behaving correctly? Anyone knows a workaround, kindly tell me.

Thank you.

B.Rgds,

Lim TS

Re: PIX error 106015: Deny TCP (no connection) flags PSH ACK

pwicks — Sat, 24 Sep 2005 01:48:43 GMT

Quick question - Is the HTTP fixup protocol enabled, and if enabled, is the fixup configured for the non-standard HTTP port that you are using?

Re: PIX error 106015: Deny TCP (no connection) flags PSH ACK

limtohsoon — Sun, 25 Sep 2005 16:47:04 GMT

Hi,

Thanks for the reply.

I have yet to check whether HTTP fixup is enabled for that particular port.

One question - Will enabling HTTP fixup for that port overwrite the default port 80?

Thank you.

B.Rgds,

Lim TS

Re: PIX error 106015: Deny TCP (no connection) flags PSH ACK

limtohsoon — Mon, 26 Sep 2005 06:05:04 GMT

Hi,

This is another scenario but it's similar to the one I posted earlier. Two interfaces involved in this case; DMZ-A and DMZ-B. DMZ-A is the higher security-level interface. There's a pool of servers on DMZ-A with IP addresses 10.219.126.70 - .78. The client (with IP address 10.219.58.83) initiates HTTP connection to any of the servers on non-standard port and the request originates on DMZ-B. The client application fails.

Below are outputs of "show log" on the PIX:

Deny TCP (no connection) from 10.219.126.70/2061 to 10.219.58.83/56850 flags PSH ACK on interface DMZ-A

Deny TCP (no connection) from 10.219.58.83/64961 to 10.219.126.72/2061 flags PSH ACK on interface DMZ-B

I tried the following commands:

fixup protocol http 2061

clear xlate

The problem persists and following is PIX "show log":

106015: Deny TCP (no connection) from 10.219.58.83/65106 to 10.219.126.78/2061 flags ACK on interface DMZ-B

I'd like to know whether this is an application error or whether there's anything we can do on the PIX to work around the issue?

Please help.

Thank you.

B.Rgds,

Lim TS

Re: PIX error 106015: Deny TCP (no connection) flags PSH ACK

jim.normand — Wed, 21 Dec 2005 19:30:31 GMT

I'm having the same issue on my 515E running 6.3(5) and I've not yet been able to tell where this is coming from. I understand why the PIX is logging this since it's not in the conn table but the big question is why? I have one Inside, one Outside, and one DMZ interface...and am performing PAT outside.

Jim