pix and multiple subnets

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?

Reply to
Zee
Loading thread data ...

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.

Reply to
Walter Roberson

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

Reply to
John Smith

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

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.