pix and multiple subnets

Apr 29, 2005 3 Replies

Rate this thread:

Zee 21 years ago

can a pix do the following

on the outside 1 subnet of addresses mask 255.255.255.0 nated to the inside range 1 subnet of addresses 255.255.255.0

This we have working.

What i would like to do is multihome the inside interface to have 4 other subnets. and the inside interface to have 4 ip addresses. So these addresses would only route inside to inside.

Can that be done?

So right now we have

outside

10.10.1..1/24 nat to inside
192.168.2.1 /24

I would also like to have on the inside interface addresses of

192.168.3.1/24
10.11.44.1/24
10.44.55.1/24

These addresses would never go to the outside only the inside. So an IP of 10.11.44.5 wanted to talk to 192,168,3,5 it would use send the data to 10.11.44.5 -> 10.11.44.1 (inside of pix) then to 192.168.3.1 (inside of pix) back out same interface to 192,168,3,5

basically not having to go through the pix

Can this be done without vlaning?

Vote

Walter Roberson 21 years ago

In article , Zee wrote: :can a pix do the following

:What i would like to do is multihome the inside interface to have 4 other :subnets. :and the inside interface to have 4 ip addresses. So these addresses would :only route inside to inside.

:Can this be done without vlaning?

PIX 7.0 possibly. Certainly not in PIX 6.x.

Vote

John Smith 21 years ago

Would a linux box with 2 interfaces work. Those can be multihomed, I heard

definately more functional than a pix if you don't want to vlan

Vote

Walter Roberson 21 years ago

In article , John Smith wrote: :Would a linux box with 2 interfaces work. Those can be multihomed, I heard :definately more functional than a pix if you don't want to vlan

Well, you'd be better going with OpenBSD than linux for something like that, but the general idea works.

The BSD/Linux route has a some prime advantages:

a) nominal cost; b) customizability; c) ability to make changes (e.g., bug fixes) quickly

The firewall appliance (e.g., PIX) has some advantages though:

1) designed at very low levels to not pass packets unless the packets are explicitly permitted;

2) codebase tested and pounded on for years, with a real support organization behind it

3) time is money -- rolling your own is not often not cost effective unless you have spare time, or very low-priced labour, or you will be deploying a fair number of them and so can amortize the effort

4) user-friendly configuration and monitoring interfaces available

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required