«

Hello,

I'm in somewhat of a bind here...

I've got a class C network with publically accessible IP addresses,
and a shiny new Cisco PIX 501 that my boss has decreed "Must Be Used",
replacing a linux based firewall running proxy-arp. Our wiring goes
something like this:

Router
xxx.xxx.xxx.1
|
|
xxx.xxx.xxx.2
Firewall
xxx.xxx.xxx.2
|
|
The rest of the network
xxx.xxx.xxx.3-254

Can anyone give me a clue as to how to make this work?

Thanks,

Bobby

In article <> ,
Bobby Kuzma <> wrote:
:I'm in somewhat of a bind here...

:I've got a class C network with publically accessible IP addresses,
:and a shiny new Cisco PIX 501 that my boss has decreed "Must Be Used",
:replacing a linux based firewall running proxy-arp.

:Can anyone give me a clue as to how to make this work?

You cannot configure the same subnet on the inside and
outside interfaces of a PIX.

The easiest solution to your problem is to subnet the public IP
space.

The alternative configurations pretty much require an internal router
as part of the setup. I have described the arrangement several
times in the past, in this newsgroup; you can google for the details.

--
Ceci, ce n'est pas une idée.

> :I've got a class C network with publically accessible IP addresses,
> :and a shiny new Cisco PIX 501 that my boss has decreed "Must Be Used",
> :replacing a linux based firewall running proxy-arp.
>
> :Can anyone give me a clue as to how to make this work?
>
> You cannot configure the same subnet on the inside and
> outside interfaces of a PIX.
>
> The easiest solution to your problem is to subnet the public IP
> space.
>
Even easier, use private IP addresses on the router's and PIX's interface,
the two that connect to each other. Set the deafault gateway on the PIX to
the router, but a static route in the router pointing xxx.xxx.xxx.0 to the
pix.

Router (ip route xxx.xxx.xxx.0/26 10.10.1.2)
10.10.1.1
|
|
10.10.1.2
Firewall (ip route 0.0.0.0 0.0.0.0 10.10.1.1)
xxx.xxx.xxx.1
|
|
The rest of the network
xxx.xxx.xxx.2-254

RC

In article <3fec8173$0$25377$> , <RC> wrote:

:> You cannot configure the same subnet on the inside and
:> outside interfaces of a PIX.

:> The easiest solution to your problem is to subnet the public IP
:> space.

:Even easier, use private IP addresses on the router's and PIX's interface,
:the two that connect to each other. Set the deafault gateway on the PIX to
:the router, but a static route in the router pointing xxx.xxx.xxx.0 to the
ix.

You can do that, but then any packets produced by the outside
interface of the PIX (RST, icmp refusal, icmp time exceeded) will
have an IP source address which is the private IP address of the
PIX outside interface. RFC1918 says that you must not allow
packets with private source addresses to be publically routed.

In order to adhere to RFC1918, one must thus add some NAT rules to
the router to map that private source IP into a public source IP.
Depending on the router, that kind of mapping might not be possible,
and even on Cisco routers it is not the easiest of things to configure.
I therefore contend that my original statement is true: that the
*easiest* solution to the problem is to subnet the public IP space.
--
Admit it -- you peeked ahead to find out how this message ends!

> You can do that, but then any packets produced by the outside
> interface of the PIX (RST, icmp refusal, icmp time exceeded) will
> have an IP source address which is the private IP address of the
> PIX outside interface. RFC1918 says that you must not allow
> packets with private source addresses to be publically routed.

When I put in a PIX it doesn't respond to anything. Basic security, keep a
low profile and they go after someone else.

> In order to adhere to RFC1918, one must thus add some NAT rules to
> the router to map that private source IP into a public source IP.
> Depending on the router, that kind of mapping might not be possible,
> and even on Cisco routers it is not the easiest of things to configure.
> I therefore contend that my original statement is true: that the
> *easiest* solution to the problem is to subnet the public IP space.

No, just drop the packets (null route). The whole point is security.
Just my opinion, but so far the firewalls I've done have always been secure
and worm free.




Security is establishing a mutual level of distrust.

In article <3ff21bfa$0$18406$> , <RC> wrote:
:When I put in a PIX it doesn't respond to anything. Basic security, keep a
:low profile and they go after someone else.

How do you stop it from responding to TCP port 23 on the outside IP?
Without, that is, using an additional device to filter the
response?


:> In order to adhere to RFC1918, one must thus add some NAT rules to
:> the router to map that private source IP into a public source IP.

: No, just drop the packets (null route). The whole point is security.

What about MTU path discovery?
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

On Tue, 30 Dec 2003 21:09:53 -0600, Walter Roberson wrote:

> In article <3ff21bfa$0$18406$> , <RC>
> wrote: :When I put in a PIX it doesn't respond to anything. Basic
> security, keep a :low profile and they go after someone else.
>
> How do you stop it from responding to TCP port 23 on the outside IP?
> Without, that is, using an additional device to filter the response?
>
>

Something I did once was not to configure the pix with a default gateway.
I then added an alias that the inside hosts used as a default gateway
that dnat'ed all packets they sent offnet to the next hop router outside
of the pix.

In effect, the only packets the pix's outside interface would respond to
were packets sourced from the outside subnet, while all internal hosts
could communicate with the outside world.




> :> In order to adhere to RFC1918, one must thus add some NAT rules to :>
> the router to map that private source IP into a public source IP.
>
> : No, just drop the packets (null route). The whole point is security.
>
> What about MTU path discovery?