PIX access-list behavior question

[wilson_1234_2]

I have a PIX 6.3 configured with an access-list inbound on the inside interface.

I am allowing traffic from a particular host to a DMZ machine on port 80.

I can see the keepalive on port 80 hitting the access-list but not where I would expect it.

I have the source hosts allowed in the first two lines and the third line allows any, just to make sure everything is going to work.

I do not see any hits on the line with the source host identified, but I see it on the line that has "any".

I have a capture below and you can see the souce is from the 131 host.

But why doesn't it match the first line in the list?

access-list inside line 9 permit tcp host 6.2.1.131 host 192.168.1.15 eq www

access-list inside line 10 permit tcp host 6.2.1.151 host 192.168.1.15 eq www

access-list inside line 11 permit tcp any host 192.168.1.15 eq www

08:15:36.783498 6.2.1.131.3369 > 192.168.1.15.80: P 3588710642:3588710891

(249) ack 782786734 win 8192

08:15:36.980723 6.2.1.131.3369 > 192.168.1.15.80: . ack 782787014 win 8192

08:15:51.783467 6.2.1.131.3369 > 192.168.1.15.80: P 3588710891:3588711140

(249) ack 782787014 win 8192

08:15:51.980784 6.2.1.131.3369 > 192.168.1.15.80: . ack 782787294 win 8192

access-list inside line 9 permit tcp host 6.2.1.131 host 192.168.1.15 eq www

(hitcnt=0)

access-list inside line 10 permit tcp host 6.2.1.151 host 192.168.1.15 eq www

(hitcnt=0)

access-list inside line 11 permit tcp any host 192.168.1.15 eq www

(hitcnt=13)

[srue]

is 6.2.1.131 getting NAT'ed at all in the firewall?

[wilson_1234_2]

No, it is not NATed.

If it were, wouldn't i see that on the capture taken on the inside interface?

It shows the source being from the address that shows up in the capture.

The capture in the original post is applied to the inside interface of the firewall, the same interface that the inbound access-list is applied.

So I see the capture access-list getting hits and the capture showing the source and desitnation addresses the same as the access-list line which is before the "any" source line.

The access-list line before the line that source is "any" has the same parameters as the capture access-list and it shows 0 hits.

[Jon Marshall]

Hi Wilson

This is a strange one. Could you post the firewall config minus any sensitive info.

Jon

[wilson_1234_2]

jon,

It is a huge config and would take a lot of time to clean up the whole thing,

Is there any particular piece you want to look at?

[Jon Marshall]

Wilson

Yes, the whole of the inside access-list or at least from line 1 to the part you posted + the nat statements.

Jon

[wilson_1234_2]

Jon,

Attached is the access-list applied inbound to the Inside interface of the PIX.

The interface that has the 192.168.1.15 server is the DMZ1 interface.

It looks like anything in the Inside interface of the PIX should NAT to 192.168.1.254 address on the DMZ interface, but this should not affect how the inside interface sees the originating traffic correct?

I removed the lines below and I can still see the hits in the capture access-list and the service is alive from the device sending the traffic.

So, it is getting in somehow.

access-list inside permit tcp host 6.2.1.131 host 192.168.1.15 eq www

access-list inside permit tcp any host 192.168.1.15 eq www

[mattiaseriksson]

Wilson, have you tried to free the translation slot since you edited the list? Use clear xlate local 6.2.1.131 and check what happens.

If you have not edited the list this will not make any difference.

[wilson_1234_2]

Thanks,

I tried that and no luck.

[rajatsetia]

Hi

Can you try removing the "permit any to DMZ server" statement frm acl to check if the particular host statement works and you get some hit counts against it or if the access if denied to the server ?

i think need to take this approroch in order check this kind of pix behaviour

rgds

[wilson_1234_2]

Thanks,

I did that shortly after I posted that ACL.

I could still see the source traffic hitting the DMZ server., but did not see the line getting any hits.

The ACL is applied inbound to the inside interface.

I also did a capture on the DMZ interface and saw the source traffic as the 6.2.1.131.

Could it be a bug?

I see other lines in the list getting hits, so I know it is applied.

[Jon Marshall]

Hi Wilson

Apologies for not getting back sooner. Could you just describe the topology of your network from the perspective of the pix interfaces.

The 62.x.x.x addresses , they are definitely coming from the inside are they ?

Jon

[wilson_1234_2]

No need to apologize jon, I appreciate all of your help.

The 6.2.1.131 traffic is on the inside inbound to the inside interface of the HQ pix.

They are actually originating from the DR side PIX, traveling across the MPLS cloud to the HQ PIX

The source traffic is originating from the DR side hitting an address on the ouside interface of the DR pix.

The destination of the 6.2.1.131 sourced packets is a server on the HQ DMZ.

The DR PIX NATs the server to the DMZ address of 192.168.1.15, but this should not have an affect on the source traffic, which is what i see on the captured packets on the HQ inside interface.

I have captured packets on the inside interface and the DMZ and they show the correct source address hitting the DMZ server on port 80.

The access-list is applied properly to the inside interface of the firewall.

I don't see how it can be getting in.

[mattiaseriksson]

Wilson, you don't have any old "outbound" and "apply" statements hiding in the config? Just kidding, but it could be the cause of the problem.

I searched for bugs matching that description but could not find anything.

Have you tried to remove all lines permitting access to the server, to see if it then gets blocked?

[wilson_1234_2]

I am not sure what you mean by old "outbound" and "apply" statements, but I searched the config and don't see anything.

I did remove the line that allows the remote host that is getting in and the any to the server (both were defined to only allow port 80).

The only other line is an entirely different host allowed and it shows no hits at all.

I will remove it tomorrow and see if it makes a difference.

It has to be getting in somehow, and I know it is getting in through the inside interface.

I am just missing it.

Thanks for the input.

I just thought of something, I did a capture on the DMZ interface also and it showed the host assress as being the source address from the other site.

According to the nat/global statements, it should have nated the inside traffic to 192.168.1.254.

a clue...