failover interface received tcp packet

[khchiang]

I have 2 failover Pix 525 under version 6.1.1

we found some inbound packet

> Jul 11 07:33:53 [primary-inside.2.2] %PIX-6-302001: Built inbound TCP

> connection

> 87177438 for faddr 218.1.1.1/32932 gaddr 218.1.2.2/443 laddr 218.1.2.2/443

> Jul 11 07:33:53 [secondary-inside.2.2] %PIX-6-302001: Built inbound TCP

> connection

> 87177437 for faddr 218.1.1.10/32932 gaddr 218.1.2.2/443 laddr 218.1.2.2/443

> Jul 11 07:33:53 [primary-inside.2.2] %PIX-6-302002: Teardown TCP connection

> 87177438 faddr 218.1.1.1/32932 gaddr 218.1.2.2/443 laddr 218.1.2.2./443

duration 0:00:01 bytes 918 (TCP Reset-O)

> Jul 11 07:33:53 [secondary-inside.2.2] %PIX-6-302002: Teardown TCP connection

> 87177438 faddr 218.1.1.10/32932 gaddr 218.1.2.2/443 laddr 218.1.2.2/443

duration 0:00:01 bytes 918 (TCP Reset-O)

Normally, the secondary-inside just only for failover, can not handled inbound Do you think which is software bug or inbound attack

Many thanks

[yusuff]

Normally, the secondary PIX will not arp for anything, unless the primary goes down and secondary will swap the IP address and MAC of the primary box, and start arping for that address.

From the logs, it looks like someone is trying to reach 218.1.2.2 on port 443 and primary pix arps for it and a connection is built up, but next thing is that it tears down the connection for some reason and Secondary PIX builts the connection for same. This could be due to Failover triggering, and perhaps you have Stateful failover so all the connections built on the primary are now going to be built on Secondary. Check to see who is the 'active' failover PIX at that time, that is where the TCP connections should be built on. Maybe your PIX is failing over to secondary.

HTH

R/Yusuf

[khchiang]

Dear Yusuf,

I just found the bug list as

CSCdv39306 Bug Details

Headline PIX loses ARP entry for HSRP address

Product pix Model

Component other Duplicate of

Severity 2 Status Verified

First Found-in Version 4.4(1), 5.2(1), 5.3(1), 6.1(1), 6.0(1)

First Fixed-in Version 6.0(4), 6.2(1), 6.1(4), 6.2(0.227), 6.1(1.107),

6.0(1.106), 6.1(3.102), 6.0(3.101) Version help

Release Notes

Problem:

The PIX loses the default route's ARP entry to an HSRP virtual IP

address. This then causes everything at the end of the PIX to lose

connectivity to everything on the other end of the PIX. This seems to

occur in version 6.0.1. This inconsistent behavior is very difficult to

replicate and we have done so only twice. Out of many hours trying to

replicate the problem.

Solution:

There is no solution at the current time.

Workaround:

Hardcode the HSRP virtual IP/MAC address mapping using

the 'alias' option to the 'arp' command.

Do you know we hit the bug, it is because , we used the 6.1.1 & 2 internet router with HSRP.

Many thanks

KH

[yusuff]

I don't think it is this bug you are hitting. This one is primarily if you are loosing ARP entry on the PIX for an HSRP address, which i don't think is your problem. The TCP connections built on secondary are for port 443, which is SSL and nothing to do with HSRP.

As i mentioned earlier, did you check if you have stateful failover and that if the Secondary unit is/was the ACTVIE unit at the time when you see the connections being built on secondary PIX from the logs.

R/Yusuf

[khchiang]

Dear Yusuf,

I checked the sh failover, it is normally, no failover active counter,

By the way, is it possible to upgrade 6.2.(x) is OK, or

we shutdown the failover interface, to observed the events,

OR any method to test it.

Many thanks

KH

[khchiang]

Dear Yusuf,

Do you have suggestion on testing,

please advise

Many thanks

KH

[yusuff]

if you can afford to disable failover for testing, then go for it, and just ahve a single PIX with no failover cable and observe.

R/Yusuf

[khchiang]

Dear Yusuf,

Yes, at this time, the Pix is running single unit, we power down the secondary, everthing is smooth, no customer to compliant dropping application.

Do you have any suggestion at further action.