Solved: Adding addition IP Block to PIX 520 - Page 3

imanco671 · ‎08-03-2011

Hello Community,

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

Here are my specs:

Hostname	AGNIPIX520	Device	PIX 520
PDM Version	3.0(4)	PIX Version	6.3(5)
User	root	Privilege Level	15
JavaScript	Enabled	Java	Enabled
Browser	Internet Explorer 8.0	JDK Version	1.5.0_05
OS	Windows 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!

imanco671 · ‎08-04-2011

Do you think I should still keep ethernet3 active so it can present a gateway? Then plug ethernet3 into my DMZ switch?

What should be the next plan of action?

I am about to just reconfigure my 2nd watchguard. make my primary watchguard handle all the 69.x.x.x NATing. Make my secondary watchguard handle all the 173.x.x.x NATing.

As of right now, the secondary and primary are both sharing the 69.x.x.x. NATing. Each are assigned a 69.x.x.x. address. There are only a hand full of NATs on the secondary and making the switch should not be too hard.

What are your thoughts? Are you confident we could have each watchguard share both the 69.x.x.x. and 173.x.x.x?

Jon Marshall · ‎08-04-2011

What are your thoughts? Are you confident we could have each watchguard share both the 69.x.x.x. and 173.x.x.x?

Not at all because i just don't know how they work

Think i've covered most of this before but what i would look to do in the long run is -

1) for the connection between the WatchGuards and the pix use a subnet with private addressing. This assumes that there are not WAN or other connections coming in on this subnet ie. to get to this subnet you either have to go through the pix or the WatchGuards.

2) The public IP addressing used for the interconnect presently could simply be used together with your new IP block on the pix. None of that addressing would need to be assigned to a physical interface on the pix, you can simply use them as statics on the pix.

So basically traffic going to the WatchGuard has already been natted on the pix to the real IP address of whatever server is behind the pix. It removes the complications we have seen here and you don't have to worry about secondary addressing on the WatchGuards.

But that is only a rough outline. Without knowing exactly how everything works within your topology it would be dangerous to start making those sort of changes to your infrastructure and there may be a very good reason why it was designed this way in the first place although i have to say i am struggling to see it.

Jon

imanco671 · ‎08-04-2011

Hi Jon,

I am thinking of making one watchguard for the 69.x.x.x addresses and the other for the 173.x.x.x. addresses.

1. Create a new internal DMZ IP range between the PIX and the watchguard 173.x.x.x firewall. NAT using the PIX to the internal DMZ range, then on the watchguard NAT the DMZ range to my "real" internal network where the application servers are?

2. should I keep trying to assing the newblock to use the 69.x.x.x interface instead? then I may run into issues with the Watchguards.

Sorry I am such a novice with firewalls! I have to re-read your posts to get it. its just me being a newbie not understanding

Jon Marshall · ‎08-04-2011

John

Unfortunately i don't know how the WatchGuards are setup ie. it may be the case if you reassign the NAT on these then it breaks something and to be honest i probably wouldn't be much use in helping you getting fixed.

As you can see using public IPs does not scale too well and this is what you are coming up against.

From what you have described so far i would try using eth3 with the new block on the pix and connecting that to the spare port on the WatchGuard and seeing if that works. At least that way you wouldn't be making huge changes to the existing setup.

*** Edit -- actually i would make that the 2nd choice, see below for first choice.

I would personally look to make the least changes possible. It certainly could do with a redesign and subject to the caveats i have covered about not knowing the full picture you may want to look at this in future.

Getting the pix to pass the new 73.x.x.x address to the WatchGuards is relatively simple as long as the spare interface on the WatchGuard can be used to create a new DMZ. Even doing this is making more of a mess though because now you have 2 entry points to the WatchGuards, one from the outside interface and one from the dmz interface.

What i really would like to do in the short term is simply pass the 73.x.x.x address to the outside interface of the WatchGuard without having to use a secondary address on the outside interface of the WatchGuard. Are you sure that you need a secondary address because with the firewalls i have used you don't need to do this. You should just be able to -

1) setup the static NAT as provided on the pix.

2) add a route on the pix for the new 73.x.x.x network and point it to the outside interface of the WatchGuard

3) add a NAT rule on the WatchGuard to NAT the 73.x.x.x address to the real 10.10.10.x address of the app server. You can certainly do this on Checkpoint/pix without having to add secondary address to the interface.

4) Obviously update any access-lists etc. that are needed to allow the traffic.

I would try the above first. It involves minimal changes and it may well work. If it doesn't try the eth3 to WatchGuard dmz solution.

Jon

imanco671 · ‎08-05-2011

Hi Jon,

I'm Back. I have read your replys and came up with the below. Let me know what you think... I am not sure if I am going to implement the "DMZ Subnet" inbetween the PIX and Watchguards.

I have 2 watchguards, one is connected to 10.0.0.0 network using the 69.x.x.x externals. The other is a 192.168.110.0 network that uses the 69.x.x.x addresses too.

There are few servers on the 192.168.x.x. network which are using the 69.x.x.x. addresses.

I was thinking just moving the NATed 192.168.x.x. addresses over to the 10.x.x.x. watchguard which would make the 192.168.x.x. watchguard "NAT less" thus freeing it up from ties to the 69.x.x.x.x addressing. Once this is happens, then I can plug the cable from the eth3 PIX interface to this watchgaurd and replace the 69.x.x.x. settings with the 173.x.x.x settings.

This would make each IP Block separate and "clean". The PIX handles both IP Blocks and each Watchguard handles its own IP Block. No messy mixture of NATing.

(thanks for keeping with me on this post, you are the master!!)

Jon Marshall · ‎08-05-2011

John

Not sure how this would affect the failover if one of the WatchGuards fails. But then again it sounds like they are doing NAT for different things anyway so it sounds reasonable.

However you shouldn't need to use eth3 on the pix. If the WatchGuard you are "freeing" has it's outside interface on the same subnet as the other WatchGuard and the pix inside subnet then simply add the static to the pix and add a route to the pix for the new block pointing to the outside interface IP of the "freed up" WatchGuard.

Jon

imanco671 · ‎08-05-2011

Hi Jon,

It would be perfect if I can make one of the watchguards use a secondary address, but I had trouble doing this. That would definately make my life much easier.

I still dont know if the PIX is passing the external 173.x.x.x. IP address propely. I have no proof. This is my main worry, I can spend hours on the watchguard and think its the problem, but it could be the PIX. You never know.

What tests can I preform to make sure that the PIX is passing the 173.x.x.x. address properly?

John

Jon Marshall · ‎08-05-2011

John

on the pix -

static (inside,outside)

route inside

then -

debug ip packet inside dst <-- use a specfic IP from the new block here.

then initiate a connection from the outside of the pix to the new IP, don't forget to update the outside acl if you have one, and you should see if any packets are being sent out of the inside interface to the WatchGuard.

To turn off debugging - "no debug packet inside"

Note debugging can place a heavy load on any device so don't do this if the firewall is being used heavily ie. you will need to do it out of hours.

Jon

imanco671 · ‎08-05-2011

Hi Jon,

I like your testing solution, but I dont want to mess with putting strain on the device. Its too important and dont want to cause any disrupution.

I was just trying to get the secondary IP address to work on the watchguard (sharing of the 69.x.x.x. ethernet) , but without luck.

I could not get it to work, I am doing something wrong.

I also tried to use that DMZ port on the Watchguard from ethernet3 on the PIX

I think that DMZ port can possibly be used as a secondary interface, just as long as it allows traffic to the inside ethernet.

Here is what I have currently:

PIX - eth3 173.xxx.xx.65

PIX - host named watchguard - 173.x.x.66

PIX - host named tester - 173.x.x.70

PIX - ACL for all above allowing ANY

PIX - 3 translation rules for the above IP addresses

Watchguard - Optional interface - 173.x.x.66/27

Watchguard - Secondary Network - 173.xx.x.66/27

Watchguard - Dynamic NAT entries called: "trusted-optional" and "optional-external"

Watchguard - 1-1 NAT - Interface (optional), NAT base (173.x.x.70), Real base (192.168.x.191)

Watchguard - Dynamic NAT Exceptions - 192.168.x.191 - optional

When I go to the 192.168.x.191 machine, I go to a browser www.whatismyip.com and it gives me a 69.x.x.x. address of the firewall (usual outcome to a server without NAT)

I am lost...

Jon Marshall · ‎08-05-2011

John

You are right, you do need secondary address on the WatchGuard, i just looked it up.

I don't think the way to go is with eth3. I have said this a number of times but you keep using eth3. The config on the pix is simple -

static (inside,outside) 73.x.x.x 73.x.x.x

route inside 73.x.x.x <-- where this would presumably be a 73.x.x.x address assigned as a secondary address.

add any rules need to the pix to allow this traffic through.

That is all you need to do on the pix. Please keep it as simple as possible. I understand why you don't want to debug but you must be able to do it out of hours ?

I think if you do the above you have ruled out the pix firewall as an issue. You then need to look at the WatchGuard(s). The WatchGuards seem to support multiple secondary IPs on the interfaces so it should be doable although i guess it depends on the model/version.

Jon

imanco671 · ‎08-08-2011

Hi Jon,

Sorry about my obsession with eth3. I will throw that idea away for now. Lets get things working using the existing ethernets.

On my PIX, I have removed the settings from eth3. I have also removed the statics and the ACLs for the 173 addresses.

Here are all the listings of the 173.x.x.x. addresses in my running-config:

name 173.xx.x.70 test2

network-object 173.xx.xx.66 255.255.255.255

pdm location 173.xxx.xx.66 255.255.255.255 inside

I have tried issueing the command without success: static (inside,outside) 173.x.x.66 173.x.x.66 255.255.255.255

I received an error: number of maximum connections should lie between 0 and 65535

******************** I want to fully document the config on the Watchguard:********************

IP address: 69.x.x.43/26

Default GW: 69.x.x.29

( I have created an alias, using the "aliases.." button next to the above settings: 173.xx.x.66)

Next tab on the "Network Configuration" window is Secondary Networks:

I have created a secondary address on the watchguard : 173.xx.xx.66/27 External

I want to eventually NAT Ip address 173.x.x.70 to 192.168.202.191

I have created a 1-1-NAT for the above.

I have also added an ACL for allowing http access. I check to see if the port is open, by going to www.whatismyip.com

John

Jon Marshall · ‎08-08-2011

John

No need to apologize, i'm just trying to make it as simple as possible.

I have tried issueing the command without success: static (inside,outside) 173.x.x.66 173.x.x.66 255.255.255.255

the command you entered was slightly wrong, try -

static (inside,outside) 173.x.x.66 173.x.x.66 netmask 255.255.255.255

Jon

imanco671 · ‎08-08-2011

Jon,

Perfect, command was successful. I added the other route command too.

route inside 73.x.x.66 255.255.255.255 69.x.x.143

Do I need to create an ACL for the 173.x.x.66 (new watchguard IP) and 173.x.x.70 (new NAT I want to create for the 192.168.202.191 server)

John

Jon Marshall · ‎08-08-2011

John

It depends. If the traffic is always from the internal server to outside the pix then you don't need top update the acl on the pix (that is assuming you don't have an acl on the inside pix interface).

If traffic is initiated from the outside of the pix to the internal server then yes you would need to update the outside acl of the pix (assuming you have one). Obviously in the acl you would use the 73.x.x.x address.

One final point. If you use ping from the internal server to test connectivity then you would temporarily need to add a line to your outside acl on the pix. This is because ping is not stateful.

Jon

imanco671 · ‎08-08-2011

Jon,

Okay I have entered all the commands successfuly for both the 173.x.x.66 and for the 173.x.x.70 address.

The Ip address is still not being NATed properly. The server is not able to resolve any websites using the 173.x.x.70 NAT

This NAT is the same as all other 69.x.x.x. NATs.

John