Solved: simple pix problem?

linnea.wren · ‎05-13-2007

Hi,

On a PIX 525, v6.3, I'm trying to create a static, and can't seem to get it to work.

My static command is:

static (dmz1,outside) 209.129.164.10 209.129.164.10 netmask 255.255.255.255 0 500

When I try to ping it, logg shows:

106014: Deny inbound icmp src outside:67.101.42.72 dst dmz1:209.129.164.10 (type 8, code 0)

When I try http://209.129.164.10, logg shows:

106001: Inbound TCP connection denied from 66.249.65.236/45593 to 209.129.164.10/80 flags SYN on interface outside

This PIX has no other statics. Another PIX I take care of has many statics - I have compared everything I can think of to compare between the two, but so far I can't find what I'm doing wrong.

One more piece of info: response to "sh xlate state static" varies. Sometimes the response includes 209.129.164.10, sometimes not. Attempts to ping and http produce the results above regardless of whether or not the address appears in the xlate table.

"System Messages" doc for v6.3 says "This message occurs when an attempt to connect to an inside address is denied by your security policy." But I don't see anything in the box's config that qualifies...

Any help will be most welcome...

Linnea

Jon Marshall · ‎05-13-2007

Hi Linnea

Could you post the config of the pix as the static entry looks fine so there might be something else in your config.

Have you checked your acl's.

Jon

View solution in original post

Jon Marshall · ‎05-13-2007

Hi Linnea

Could you post the config of the pix as the static entry looks fine so there might be something else in your config.

Have you checked your acl's.

Jon

linnea.wren · ‎05-13-2007

Hi Jon, Joshua,

PIX config is attached. At the bottom of the file I include output of "sh route"

>"Have you checked your ACLs."

I haven't been thinking this was an ACL problem for 2 or 3 reasons.

1. When I do "sh access-list acl_dmz1", the hits on that ACL don't change in response to what I've tried.

2. My experience so far is that when an ACE is the culprit, the logg message will be "106023: Deny tcp ... by access-group "acl_outside""

3. The relevant ACL allows the 2 kinds of traffic I've been attempting (icmp & http).

However, I have been mistaken about the impact of one or another ACL before, so it wouldn't be too surprising to find there's an ACL component to this...

joshua.walton · ‎05-13-2007

You must allow pings.

access-list 100 permit icmp any any echo-reply

access-list 100 permit icmp any any time-exceeded

access-list 100 permit icmp any any unreachable

access-list 100 permit

access-group 100 in interface outside

106014

http://www.cisco.com/en/US/docs/security/pix/pix63/system/message/pixemsgs.html#wp1052183

106001

http://www.cisco.com/en/US/docs/security/pix/pix63/system/message/pixemsgs.html#wp1052079

linnea.wren · ‎05-14-2007

Hi,

Problem solved - acl on the outside interface was incomplete, and acl on dmz1 interface was backwards. (turned out the additional params for permit icmp weren't needed, it was just a matter a including the necessary ACEs for outside, and correcting mistakes for the dmz.)

I still have a question, though.

There's a traffic flow concept that I understood as "Traffic flows from higher security interfaces to lower security interfaces." I thought that meant you didn't need ACEs to allow traffic from higher security interfaces to lower. Yet to get this to work, I had to have

...."permit proto any"

in an ACL applied to the DMZ interface.

My interfaces are thus:

nameif ethernet0 ... security0

nameif ethernet1 ... security100

nameif ethernet2 ... security10

The DMZ interface is ethernet2.

The outside interface is ethernet0

If "traffic flows higher to lower", why do I need an ACL to get a server in the DMZ to converse with the outside world?

acomiskey · ‎05-14-2007

You wouldn't...until you wanted to ping the server since icmp does not apply to what you have described above. So as soon as you created an acl into the dmz interface for icmp ping replies, you must then allow all other traffic because of the implicy deny ip any any at the end of the acl.