PIX access-list behavior question

Unanswered Question
Jul 23rd, 2007

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)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
srue Mon, 07/23/2007 - 07:15

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

wilson_1234_2 Mon, 07/23/2007 - 08:04

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 Mon, 07/23/2007 - 10:46

Hi Wilson

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

Jon

wilson_1234_2 Mon, 07/23/2007 - 17:57

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 Mon, 07/23/2007 - 20:20

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 Tue, 07/24/2007 - 05:22

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

Attachment: 
mattiaseriksson Tue, 07/24/2007 - 00:37

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.

rajatsetia Wed, 07/25/2007 - 21:49

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 Thu, 07/26/2007 - 11:38

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 Thu, 07/26/2007 - 00:01

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 Thu, 07/26/2007 - 08:23

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 Thu, 07/26/2007 - 14:51

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 Thu, 07/26/2007 - 16:07

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...

mattiaseriksson Thu, 07/26/2007 - 16:23

Ok. The outbound was the old way to configure outbound access, before access-lists existed in the PIX OS. You can use them both but would end up with a conflict.

You don't have any crypto-maps applied?

If you could attach the config it would be helpful.

Or:

sh nameif

sh access-group

sh access-list

sh nat

Actions

This Discussion