1. Home
  2. Cisco Systems
  3. Implicit rule PIX

Implicit rule PIX

Hi all,

PIX has a feature called implicit rule. When there is no acceslist, outside traffic from a interface with a higher security-level is allowed to a lower security-interface. But traffic from a lower security-level to a higher securitylevel is not allowed ( unless it was initiated from higher interface).

But if I want to add some rules to this setup, the implicit-rule is no longer availble ( because implicit rules are only available when there on acceslist) It seems not possible to add an implicit rule by hand ( correct?)

also a rule like permit DMZ tcp any any, would give dmz also acces to inside So i have block acces from DMZ to inside first and then allow DMZ acces outside

At the moment i'm working with a few vlan interfaces, so a lot of work to get the above described setup working, without making errors

I'm thinking of creating a network-object wich contains al my internal (public IP) networks, deny all acces to these networks, then allow acces to outside from these networks, apply this to all my interfaces And put all my exeptions before these lines.

I hope this setup will be less error prone, I know myself forgetting a smal thing.

Dont know how an interface will react if a network-object contains also his own interface, and disable acces to it.

Is this a good setup? Are there better ideas? Or is it possible to make acceslist like: allow trafic from interface-x to interface-y (based only on interfaces, not on IP)

Any suggestions are helpfull.

Jan-Willem

Reply to
Nieuws Xs4all
Loading thread data ...

I don't recall ever having seen it referred to as a "feature called implicit rule", but I know what you are referring to.

If you added it by hand, it would no longer be implicit, so No. The equivilent explicit rule is just "access-list NAME permit ip any any" applied to the higher security level interface.

That would depend on where it was applied, and it isn't quite that simple.

Not quite. Given the above rule applied to the DMZ interface, access still would only be permitted to those inside hosts which are covered by an "nat (inside) 0 access-list" or "static (inside,dmz)".

You probably don't want to apply that to your outside interface.

It won't care, except perhaps in PIX 7 with same-interface routing to VPNs. With the exception noted, traffic from a subnet inside an interface to the -same- subnet, never goes through the PIX and the PIX will reject it if you try to force it to. Traffic from the subnet to the PIX itself (e.g., ping the PIX) is not controlled by ACLs: it is controlled by 'icmp' and 'http' and 'ssh' and 'telnet' commands.

No, you can't do that.

Reply to
Walter Roberson

;-)

In my project, the complete network is a public ip /24 network devided into a lot of small segments connected to individual vlans. The pix has to control who can talk to who, So everything is nat0 A solution could be no to create a translation-map to every network so no traffic can flow as you point out. But then the nat-0 rules function as a sort of firewall functions, perhaps not so clean to do that. At the moment i've created nat-0 rules exactly as one would expect, in every network direction no change of ipadress.

understand that Well it is PIX7.

Any other, better ideas how to cleanly manage such a network?

Reply to
Jan-Willem

;-)

In my project, the complete network is a public ip /24 network devided into a lot of small segments connected to individual vlans. The pix has to control who can talk to who, So everything is nat0 A solution could be no to create a translation-map to every network so no traffic can flow as you point out. But then the nat-0 rules function as a sort of firewall functions, perhaps not so clean to do that. At the moment i've created nat-0 rules exactly as one would expect, in every network direction no change of ipadress.

understand that Well it is PIX7.

Any other, better ideas how to cleanly manage such a network?

Reply to
Jan-Willem

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.