NAT Help on Pix 515E

Unanswered Question
Jul 26th, 2007

I need some help figuring out the best way to setup a NAT on an existing setup that I inherited. I'm using a PIX 515E, Cisco PIX Security Appliance Software Version 7.1(2). Here is the config for the internal and external interfaces:

interface Ethernet0

nameif outside

security-level 0

ip address 209.x.x.242 255.255.255.248

!

interface Ethernet1

nameif inside

security-level 100

ip address 66.x.x.1 255.255.255.0

!

As you can see, I have 2 public IP ranges on the interfaces. From what I've read, a traditional NAT would have a public IP range on the external, and an internal IP range (ie, 10.10.10.0/24) on the internal. I do not want to change the interfaces.

We do not use the 209.209.209.242/29 to assign to any machines inside of our network, we use the 66.66.66.0/24. What I need to do is use a 10.10.10.0/24 network as my internal network, and NAT that through the 66.66.66.0/24 network. Another variable to throw into this equation is that I need a number of hosts inside the network to have external access (I?m assuming a static NAT rule to map 66.66.66.124 -> 10.10.10.124 ? for example) such as web servers, and the rest of the hosts can overload to a single IP (66.66.66.250) such as workstations that do not need public access.

What is the best way to achieve this setup?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
mattiaseriksson Thu, 07/26/2007 - 15:06

You should change network on the inside interface to 10.10.10.0/24, and set up dynamic NAT using a pool of 1 ip address and use the rest of the addresses for static NAT as you described. You have to change the inside interface address in order to free the 66.66.66.0/24 network for NAT use. You don't have to change the external address.

If you can't change the inside network you have to use an internal device as NAT gateway.

ephillips12 Thu, 07/26/2007 - 16:59

Hello mattiaseriksson,

Thanks for your reply.

So you're saying to do something like this:

interface Ethernet0

nameif outside

security-level 0

ip address 209.209.209.242 255.255.255.248

!

interface Ethernet1

nameif inside

security-level 100

ip address 10.10.10.1 255.255.255.0

!

global (outside) 1 66.66.66.250

nat (inside) 1 10.10.10.0 255.255.255.0

static (inside,outside) 66.66.66.124 10.10.10.124

static (inside,outside) 66.66.66.125 10.10.10.125

static (inside,outside) 66.66.66.126 10.10.10.126

This would allow all hosts inside the firewall with an IP in the range of 10.10.10.0/24 to PAT over 66.66.66.250. And hosts 10.10.10.124, 10.10.10.125, 10.10.10.126 would have public access via 66.66.66.124, 66.66.66.125, 66.66.66.126 respectively.

Is this right? Please correct me where I'm wrong.

Also, all our rules are on an extended access list named "outside_acl". Here's one line from it.

access-list outside_acl extended permit tcp any 66.66.66.0 255.255.255.0 eq www

Then:

access-group outside_acl in interface outside

This will need to be unchanged, correct? I'm thinking since it's applied to outside interface it hasn't been translated yet and putting 10.10.10.0 would be wrong.

Thanks!

mattiaseriksson Fri, 07/27/2007 - 00:35

Exactly. But you should be a little more specific in the outside_acl, and only permit access to real servers.

ephillips12 Sat, 07/28/2007 - 07:47

Thanks, I'll try this during our next maintenance window and I'll let you know of my success.

ephillips12 Thu, 08/30/2007 - 05:56

Ok I was finally able to give this a shot last night and for the most part it worked great. My only issue now is this. My 10.10.10.x network is not able to talk to IPs on the 66.66.66.x network. Is there something special I need to get this to work?

The reason for this is that some machines inside the internal network still have configurations pointing to IPs on the 66.66.66.x network. Until I get a chance to find them all and get them changed I need the ability for the 10.10.10.x network IPs to be able to talk to the 66.66.66.x network IPs.

Thanks for your help.

jeremyault Thu, 08/30/2007 - 07:16

That's an interesting problem and a good question. Basically you want to nat traffic from the inside (with a 66.66.66.X destination) to a 10.10.10.X destination address for the servers inside the network.. hmm.

Disclaimer - this is just a "brainstorm" and may not even work. Basically, you want to do a policy NAT (using an ACL) for the inside traffic with the following conditions.

1) traffic from 10.10.10 network to 66.66.66.124 nats to 10.10.10.124 on the inside interface

2) traffic from 10.10.10 network to 66.66.66.125 nats to 10.10.10.125 on the inside interface

3) traffic from 10.10.10 network to 66.66.66.126 nats to 10.10.10.126 on the inside interface

4) traffic from 10.10.10 network to any other nats to 66.66.66.250 on the outside interface

It might look something like this. The "problem" is that I have no idea if you can nat from inside to inside. But if you could, it would probably look exactly like this:

access-list 124 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.124

access-list 125 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.125

access-list 126 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.126

access-list 150 permit ip 10.10.10.0 255.255.255.0 any

nat (inside) 124 access-list 124

nat (inside) 125 access-list 125

nat (inside) 126 access-list 126

nat (inside) 150 access-list 150

global (inside) 124 10.10.10.124 255.255.255.255

global (inside) 125 10.10.10.125 255.255.255.255

global (inside) 126 10.10.10.126 255.255.255.255

global (outside) 150 66.66.66.250 255.255.255.255

Additionally, I don't know how the PIX will respond to traffic going back out on the same interface it came in on. I know it doesn't like to allow traffic (by default) from one interface to another with the same security level so it's possible you may need to add an ACL to the inside interface to permit the traffic to go back the way it came.

Maybe something like (unless I totally messed this one up - forgive me I'm learning too)

access-list 101 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.124

access-list 101 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.125

access-list 101 permit ip 10.10.10.0 255.255.255.0 host 66.66.66.126

access-group 101 in interface inside

jeremyault Tue, 09/04/2007 - 16:17

Another way I was going to suggest would be to split the inside interface into two sub-interfaces and set it up so that one is the default gateways for the 10 network and the other is the gateway for the 66 network. Put them on different VLANS then set up the firewall to route between them.

May be more complex to do but it would (should) work.

Again, hypothetical solution. I'm hoping a real expert will confirm or squash my suggestions.

ephillips12 Thu, 09/06/2007 - 08:34

Ok I performed the changes and some of it worked. I actually found the issue with the 10.10.10.0/24 network not being able to talk to the 66.66.66.0/24 network, it was something on the outside_acl.

Everything is working good now. I have a few new problems. Let's deal with this one first, as it may fix other problems.

We have VPN tunnel to our production network (IP range 64.64.64.0/24). We (our development network - 10.10.10.0/24) can talk to the production network fine, however the production network cannot talk back to our internal development network. It can talk to our 66.66.66.0/24 IPs (which are statically nat'd). So I need basically for our production PIX to route all traffic to 10.10.10.0/24 through the VPN tunnel. It's already working for 66.66.66.0/24 (routes it through the tunnel fine).

What do I need to do to get this to work?

Thanks so much.

Actions

This Discussion