Inbound access from outside

[d.westerhoff]

Hi!,

I am writing to ask a question of the various ways to gain inbound access from the outside. I am analyzing a pix configuration (my first) and it doesn't have any conduits. I thought to go from lower to higher conduits or access-lists were required.

I do however see the following:

access-list acl-in permit ip any any

and:

access-group acl-in in interface outside

I understand that it is permitting an IP traffic, but is this the proper way of doing business?? does this not essentially "open the gates" or am I missing the point?

The rest of the config simply disables Nat (Nat 0) and then nats by static addressing addresses to themselves, and is followed by several dozen "route inside" or "route outside" commands. of course there is a default route to the outside router.

This is definitely a little odd from the way I learned in class.

Any guidance?

Thanks, Donn

[bgrunewald]

I hope this is not in production, as it is not a very secure configuration.

The access-list plus access-group commands perform essentially the same function as a conduit - permit inbound traffic.

The nat 0 tells us that the inside addresses are registered (or at least routable within this network).

The problem is that there are no inbound port restrictions on traffic to the hosts that have a static address mapping. The same will apply to a regular client once they establish an outbound connection; anything will be accepted inbound.

Having "permit ip any any" in a Pix configuration pretty much defeats the whole purpose of having a firewall.

[d.westerhoff]

I have afurther question , actually a couple related to this issue:

1. Even with no port restrictions existing, will the PIX still block trafiic in bound if the originating traffic did not pass through it outbound?? I have a client whose traffic originates from a system above the firewall and goes directly to the Internet. His return traffic is purposefullu coming back in another direction destined for a location below the firewall. He claims that his application stops at the firewall because it didn't originate from below it, that th stateful packet inspection of the firewall is blocking him. This doesn't sound right to me, but I am uncertain of how to proceed.

2. If I am running a private network behind the firewall, and running NAT 0 as described above, what exactely is the purpose of doing a static translation to ones own address?? static a.b.c.d a.b.c.d mask ??? the pix book just says this is the way you translate to yourself? why would I want to do this??

[bgrunewald]

1) Yes, other than static server addresses Pix must see the outbound packets to set up a translation table entry and a connection table entry. Without these the return packets are pitched. In other words, unless you are a server that is expected to receive inbound connections, inbound packets that do not go with an open connection are dropped. That is what makes it a firewall. Also note that most firewalls require symmetrical traffic flow because of this, which can be an issue where there are multiple ISPs and firewalls.

2) There are two forms of NAT 0. If you use the old form (no access-list) then Pix actually does everything it does for "real" NAT - it maintains a translation table entry with the outside and inside address the same(!) and is still really doing NAT to the same address. So if you use "old" NAT 0 you need a static with the same address inside and outside to put a static entry in the translation table for a server. The "new" NAT 0 command with the access-list is fundamentally different because it really doesn't do NAT, but it does still maintain the connection table. If you are using the new NAT 0 you must be careful how you construct the inbound ACL or you can easily allow inbound access to all your NAT 0 addresses. The new NAT 0 does't use "static" because it doesn't maintain the translation table, so any address that falls under NAT 0 can be reached inbound like a server. Note that the new NAT 0 was designed to make VPN configurations more flexible and is only designed to work between subnets that consist of private addresses. If you construct the NAT 0 ACL incorrectly you can fail to translate packets going to the Internet, resulting in connection failures.