This post originated from an RSS feed registered with Python Buzz by Aaron Brady. Original Post: Using a Cisco PIX Without NAT Feed Title: insom.me.uk Feed URL: http://feeds2.feedburner.com/insommeuk Feed Description: Posts related to using Python. Some tricks and tips, observations, hacks, and the Brand New Things. Latest Python Buzz Posts Latest Python Buzz Posts by Aaron Brady Latest Posts From insom.me.uk

I searched at length for a good treatment of this subject, and for the most part had to puzzle through it for myself. Now, as fodder for Google, here's how to configure a PIX firewall without having to use network address translation.

The Cisco PIX is pre-disposed to wanting you to use NAT for the 'inside' (secure) portion of your network. Some of this probably comes from the fact that the PIX was initially a NAT-only device, which has evolved into a firewall since coming to Cisco.

However, there are many reasons you would not want this, including sharing the broadcast segment with non-NAT hosts (not that I recommend this) and for general ease of configuration of some protocols that are generally broken by NAT. The one I am foremost thinking of here is RTSP.

In order to allow traffic to pass between your PIX and the world, without NAT you need to:

• Add the outside & inside interfaces to the global address pools. By default, these commands will add all IPs within the subnet specified by the mask on the interface.

  global (outside) 1 interface
  global (inside) 2 interface

• Create NAT 0 access lists for inbound and outbound traffic. These are not the same as firewall rule lists- they only specify which packets will be NATed or not. As we're doing NAT 0 (which means no translation), we can let everything be NATed.

  access-list out2in permit ip any any access-list in2out permit ip any any

• Associate the access lists with NAT 0.

  nat (outside) 0 access-list out2in outside
  nat (inside) 0 access-list in2out

• Interesting side effect: because we're doing NAT in both directions, firewall rules apply to outbound traffic as well as inbound traffic. Your firewall rules obviously need to take this into account. You might want a simple:

  access-list foo permit ip INTERNAL.IP INTERNAP.NETMASK any

  to get outbound traffic flowing.

• Associate this access list with the outside world:

  access-group foo in interface outside

• Apply your own firewall rules as normal.

• Enjoy.