PIX - restrict services

Your Subject asked about restricting service, but your body is about allowing unrestricted service. That doesn't make sense.

How do the PIX inside and outside interface addresses related to the ranges you have specified?

Does traffic need to be permitted to 192.168.90.0 and 192.168.90.255 ?

One way is to first Nat the inside on the outside for itself

static (inside,outside) 192.168.90.0 192.168.90.0 netmask 255.255.255.0

And then filter the traffic with proper access-group and access-list

You must also assure that you have a route on NetworkTwo for the NetworkOne. PCs on NetworkTwo must know that NetworkOne is reachable through the PIX outside address.

When I do...

access-list 101 permit icmp any any access-list 101 permit tcp any any access-group 101 in interface outside static (inside,outside) 192.168.90.0 192.168.90.0 netmask 255.255.255.0

..would that be enough to allow 172.16.20.0/24 to access any hosts on

192.168.90.0/24? ....Should I be able to ping, say, 192.168.90.38 from 172.16.20.3?

yes it should, depending on your routing.

What is the default gateway of 172.16.20.3 , and what is the ip address of the PIX outside interface ?

The default gateway of 172.16.20.3 is 172.16.20.1, and the ip address of the PIX outside interface is 192.168.90.2. ....Would that still work?

No. Your original message said that 192.168.90.0/24 was the Inside of the PIX. It is not possible for the inside and outside interface of a PIX to have the same IP address range.

This would have gone faster if you had answered the questions in my reply soon after your posting.

My mistake. Outside interface ip is 172.16.20.1

So you do not have a router between the two subnets, just the PIX. In that case, the data flow will work only if proxy arp is functioning on the PIX. proxy arp is turned on by default on the PIX, and sometimes you can get away with using it, but it is more robust to configure so that you do not need to rely on proxy arp (there are a couple of features on the PIX that are documented as not working if proxy arp is on; in particular, the deprecated 'alias' command.)

With the static() that has been proposed, there are three addresses on the inside lan that would not be reachable through the PIX: the lowest IP number in the range; the highest IP number in the range; and the IP address of the inside interface itself.

If you want to permit all traffic between the two subnets, then why not just get a cheap router? You could probably get a functional one for about $US40.

Proxy arp is enabled.

Not reachable addresses in this case would mean...

192.168.90.0, 192.168.90.255, and 192.168.90.1;

Is this correct?

PIX is mandatory in this production environment. The intention is to restrict communication protocol between outside hosts and inside hosts. The plan is to create an object group for the services that will be allowed from outside hosts in to the inside hosts, and utilize access list as well.

Thanks.

i did the following and still can't ping hosts on the inside interface from 172.16.20.0/24(ex: 172.16.20.5 ==> 192.168.90.30)...help.

static (inside,outside) 192.168.90.0 192.168.90.0 netmask 255.255.255.0

route inside 192.168.0.0 255.255.0.0 192.168.90.1 1 OTHER static route inside 192.168.90.0 255.255.255.0 192.168.90.1 1 CONNECT static route outside 172.16.20.0 255.255.255.0 172.16.20.1 1 CONNECT static

..And here's what i put on the outside interface access-list 101 permit icmp any any echo-reply access-list 101 permit icmp any any access-list 101 permit icmp any any time-exceeded access-list 101 permit icmp any any unreachable access-list 101 permit tcp any any access-group 101 in interface outside

Hi Sarastra Maya:

Here is a sample configuration for PIX and it should work in your situation:

access-list permit_all permit ip any any access-group permit_all in interface outside nat (inside) 0 access-list permit_all

I assume that you want to allow ALL traffic through the PIX. You can replace the access-list with a more specific one if you want to prevent outside from accessing some services. For example:

access-list permit_http permit tcp any any eq 80 access-list permit_all permit ip any any access-group permit_http in interface outside nat (inside) 0 access-list permit_all

To configure the PIX to allow traffic initialized from outside, you have to use "nat (inside) 0 access-list" if you want to use dynamic NAT, or static NAT. Other forms of dynamic NAT do not allow inbound traffic initialized from outside.

In addition to ACL and NAT, you have to make sure that every node (including PIX) in your network has proper routes. A simple solution is to enable RIP for every node, and configure the PIX to propagate default route to inside and outside. Also you may choose to use static route.

May i ask Mr CCIE or Walter,

What is the best solution for those cases,

static(inside,outside) inside inside etc,...

or

nat (inside) 0 access-list etc,...

What are the PROS and CONS , other than the Proxy Arp requirements already mentionned.

thanks

Both are good for those cases, but they are different.

1, "static (inside,outside)" is static NAT and "nat (inside) 0 access-list" is a special form of dynamic NAT, just like static routing vs dynamic routing. I am not to say that static is bad and dynamic is good. It really depends. However, if you have many subnets in a zone and you want to NAT them, dynamic NAT is usually a better solution.

2, "nat (inside) 0 access-list" is evaluated by PIX BEFORE ANY OTHER FORMS of NAT.

3, Using access-list makes "nat (inside) 0 access-list" much more powerful than "static". For static NAT, you can filter on source IP ONLY. I do not need to mention how many ways you could do filtering with access-list.

mcaissie wrote:

Thanks for your answer,

one thing to be carefull with is that

" access-list permit_all permit ip any any nat (inside) 0 access-list "

doesn't have the same behavior than

" nat (inside) 0 0.0.0.0 0.0.0.0 "

In the second case the translation occurs only when traffic is initated from the inside. I got caugh with that once , wich made me switch for the static solution. But later i discovered that using the nat 0 with an access-list would work also.

Thanks a bunch guys! Like you said, both methods work great, but I decided to go with nat (inside) 0 access-list. I also found that in order to make this work I have to use static (outside,inside) statement for my outside hosts. Not sure whether that was the case but it works now :)

One more thing...Please correct me if I'm wrong..

Outside hosts want to access a website (somewhere; whether Intranet or Internet, but I would assume that the query has to find a DNS server somewhere). He opens a browser, and type in the URL. To get this to work I did the following...

object-group service Ports tcp-udp port-object eq www port-object eq 53 access-list permit_stuff permit tcp any any object-group Ports access-list permit_all permit ip any any access-group permit_stuff in interface outside nat (inside) 0 access-list permit_all access-group permit_stuff in interface outside

....

I know that there has to be some work done with defining DNS somwhere, but not sure how to go about.

Thanks!

Hi Sarastra Maya,

DNS uses UDP 53 but not TCP 53 (yes, it does use TCP 53, but not for queries and you do not need to consider it here). After you correct this problem in your configuration, it should work.

However, if the traffic is NATed (say, you are using common NAT but not NAT exemption), then you should add keyword "dns" at the end of the NAT commands. For example:

nat (inside) 1 access-list permit_some dns

--- or --- static (> CCIE #15766 wrote:

So, by defining 53 in the object-group service Ports tcp-udp, would not work? or simply that I just need to make another statement: access-list permit_stuff permit udp any any eq dns (or object-group Ports tcp-udp; where 53 is defined as port-object in object-group Ports)...?