cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7443
Views
0
Helpful
53
Replies

Adding addition IP Block to PIX 520

imanco671
Level 1
Level 1

Hello Community,

I am having a hard time adding a new IP block to my PIX 520.

Here are my specs:

HostnameAGNIPIX520 DevicePIX 520
PDM Version3.0(4) PIX Version 6.3(5)
Userroot Privilege Level15
JavaScriptEnabledJavaEnabled
BrowserInternet Explorer 8.0 JDK Version1.5.0_05
OSWindows XP 5.1

I have an existing external IP block on eth1 which is working fine. I have another eth3 card which I want to use for my additional IP range.

So my ISP gave me a new /27 block is addition to what I have now. This block is supposily active and nothing is needed to configure on the ISP router, it is said that it is autmatically available and ready to use once I configure my PIX.

I am using the PIX GUI and running into an error while trying to create a NAT pool "Start and end addresses overlap with existing range"

I have done the following:

1. I have filled in the eth3 IP address info:

     a. enabled: YES

     b. name: NewBlock

     c. security level: 30

     d. ip address: 173.xxx.xx.65

     e. subnet mask: 255.255.255.224

     f. hardware: ethernet3

2. physically plugged an ethernet cable in the ethernet3 port then to a laptop who has an ip address of 173.xxx.xx.66, mask: 255.255.255.224 (just as a test laptop to see if I can get the internet)

3. Used the GUI and clicked the "host/networks" tab and selectted the interface "NewBlock".

4. Edited the NewBlock-pool, clicked the "NAT" tab, clicked "Manage Pools".

5. Tried to add a pool to "NewBlock" using range 173.xxx.xx.66 - 173.xxx.xx.91

6. Receive error stating that "Start and end addresses overlap with existing range", my other range is nothing like this new range. This is the actual command that the PIX does not like:  global (NewBlock) 1 173.xxx.xx.67-173.xxx.xx.91

I have searched all throughout my PIX and cannot find any conflicting IP addresses anywhere. I have no idea what I am doing wrong.

I have posted some screen shots. Please let me know if you need me to post any other screen shot

Thanks in advance!

53 Replies 53

John

Okay the problem is that you cannot have a default-gateway that is not from the same subnet.  This is why private addressing is generally used ie. you would not have run out of private IPs as quickly on the inside interface so you would simply have been able to use another private IP with the correc default-gateway and then used one of your new IPs.

But i am still confused. What would be the address of an app server you wanted to NAT for with the new IPs ?

Jon

Hi Jon,

sorry things are a little confusing on my end. We have a bunch of apps that run on the same port. We issue a different WAN address for each application for our clients. So there is no WAN IP address sharing allowed. Each server has its own internal address too. The PIX does not do the "proper" NATing of WAN to internal. The "proper" NATing is done on the 2 other firewalls which are behind the PIX.

Our PIX is our exterior firewall who is just redundant to the firewalls behind it. It is just for extra security. So starting with the PIX, each WAN address is passed through it and is picked up by either firewall behind it. So a WAN address is passed and NATed to itself and added to and acl which could be part of a group or a single entry. Basically passing a WAN address to a WAN address to be picked up by something on the DMZ switch or the 2 other firewalls.

There is also a DMZ switch in between the PIX and the 2 firewalls. On the DMZ switch, the PIX is plugged in, 2 other firewalls, 2 DNS servers and my laptop for testing.

( Its a network that was already configured before I joined this company) If you have suggestions, I am definately listening. I am able to change anything that makes sense.

John

John

Think i'd be a bit scared to make suggestions

Seriously though there does seem to be too much public addressing assigned to interfaces. Without seeing the full topology and configs it would be very difficult to suggest changes but it does, on first appearances seem to be more complicated than it needs to be.

So this is my understanding so far which my well be incorrect. You want to present to your WAN ie. on the outside of your pix one of the new IP addresses. You then want to simply pass this connection through to your internal firewalls where it will get correctly natted to real app server IP ? Is this correct.

If so you need to add a route on your outside pix for the new block pointing to the next-hop ie. one of your internal firewalls. Use the static i provided and then on the internal firewall NAT it to the real address. To test you will have to be on the app server subnet with your laptop using an IP from that subnet. If that subnet is also using public IPs and you have run out then i'm not sure how you are going to test to be honest.

I understand you didn't set this up and it's always difficult to say something is wrong. There may be a reason why the interconnect between your pix and the other firewalls are using public IPs. But i have to say this seems to me to be a waste of public IPs and unnecessarily complex. But to redesign may well create a whole new set of problems especially if things are referencing public IPs from the interconnect subnet.

Jon

Hi Jon,

Yes, you are correct. PIX just passes the connection, then the interior firewalls do all the "proper" NATing.

The 2 interior firewalls are WatchGuards. (so we can reference them that way)

So  you dont want me to test using the laptop? I was thinking it would be  easier to get PIX verified (passing the IP) first, then verify the  WatchGuards next. But if you want me to put the laptop behined the  WatchGuards, then no problem.

The laptop did not work even after I have reassigned the NIC using:

Ip address: 173.xxx.xx.65

subnet: 255.255.255.0

I still could not get anywhere and test. Maybe I am not testing the proper way (since I am using a browser).

John

John

Yes, because of the way your network is setup you will have to test from the app server subnet ie. behind the watchguards.

Don't forget to add the route to the pix for the new block that points to the WatchGuard(s).

Jon

Jon,

Ok I have an internal server (we will call it NewWeb) which is behind the Watchguard.

I have IP address 173.xxx.xx.65 passing through the PIX (ANY access)

I also have IP address 173.xxx.xx.70 passing through the PIX ( ANY Acceess)

Each of the above, I have used that static command that you have given me.

Now on the WatchGuard, I have added an Alias to the "external Interface" using IP address 173.xxx.xx.65

I have also added a Secondary Network assignment: 173.xxx.xx.65/27 EXTERNAL (which is the interface)

I then added  the NAT for 173.xxx.xx.65 to NewWeb and then added it to the ACL for http.

Still no luck.

The watchguard is configured as:

External interface:

Configuration: Static

Ip Address: 69.xxx.xx.xxx/26

Default Gateway: 69.xxx.xx.129

John

I don't have any experience with WatchGuards so i'm assuming adding a secondary address is how you do it although you do not need to do this on pix/ASA or Checkpoint.

It may be after all this, that the only way to get get this working is indeed your original solution ie. using another interface on the pix.

I can't see any reason why what i suggested wouldn't work but as i say i don't know how watchguards work.

When yo do try and connect do you see any NAT translations for you new IP on the pix ?

One comment i would make following on from the last post was that generally using 2 sets of firewalls, one in front of the other, a common approach is to have subnets between the 2 sets of firewalls. I am struggling to see what additional benefit you get by simply passing traffic from one firewall straight to the other apart from the benfit that if one firewall has bugs in it a different vendors may not.

Jon

Jon

Hi Jon,

Okay so I should use ethernet3? And plug that ethernet3 into the Watchguard?

lets focus on the PIX since you are an expert on Cisco.

I will worry about the Watchguard later.

I just first want to make sure that the PIX poasses this external IP address correctly. Then I can blame the Watchguard.

So I will config the ethernet3? How should I start? I was thinking assiging ethernet3 173.xxx.xx.65

John

I have this config on the PIX:

Ethernet3: 173.xxx.xx.65

Static route command for 173.xxx.xx.65

ACL: outside --> 173.xxx.xx.65  ANY

Should I make a static route for 173.xx.xxx.70 and a ACL for it too?

John

Actually, thinking about it it makes no difference because you still want to pass that address through to the WatchGuards. In fact using an additional interface on the pix is exactly what you can't do.

It's all to with this public IP addressing and running out on the inside interface. So we have to get this WatchGuard thing working. If you used a separate interface on the pix then you wouldn't be able to pass it through as is to the WatchGuards.

This is the problem i was referring to before. If the interconnect between the WatchGuards and the pix was using private addressing then you wouldn't have run out. Then you simply use public IPs, your old and new block on the pix for static NATs and then pass through to the WatchGuards the private IPs.

But i'm not suggesting we try and set this up.

I think we have done all we can on the pix ie. it should now be passing this through correctly to the watchguard although just to be sure can you post pix config ?

Looks like we need to work out why the WatchGuards are not doing what we want them to do.

Final question, what subnet is actually used for the apps servers ie. what is their real IPs ?

Jon

Hi Jon,

I could plug the nic from my PIX (ethernet3) driectly into my Watchguard's extra port?

I just dont see how I can assign a 173 address using the 69 gateway.

My internal addresses are 10.10.10.0

John

Ahh, i didn't realise you had extra ports on WatchGuard. Yes do that and then setup the NAT on the Watchguard to translate from 73.x.x.x to 10.10.10.x.

If you test with a laptop on the pix be aware that this only tests the pix config though.

Jon

oops, that port is labeled optional. which after reading, that it is only for DMZ and not for another external interface.

John

Again i would stress my lack of knowledge on WatchGuards but it shouldn't matter. As long as you setup the NAT on the WatchGuard from the dmz interface to the inside i can't see why it wouldn't work.

Jon