«

Can the pix handle the same network on both inside and outside interfaces. I
simply want the pix to protect some machines in the 10.15.0.0/24 from other
machines in the 10.15.0.0/24 range

i.e Like a filter between hosts

Gary

In article <nRVMd.19820$Vg3.8086@lakeread05>,
Gary <> wrote:

:Can the pix handle the same network on both inside and outside interfaces.

No, definitely not.


:I simply want the pix to protect some machines in the 10.15.0.0/24 from other
:machines in the 10.15.0.0/24 range
:i.e Like a filter between hosts


{10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
______________________10.1?.0.x___________________ _|
|
--- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}


PIX #1:

ip address inside 10.15.0.1 255.255.255.0
ip address outside 10.16.0.1 255.255.255.252
static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
route outside 10.18.0.0 255.255.255.0 10.16.0.2

access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0 255.255.255.0

access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0 255.255.255.0

access-group cloud1to2 in interface inside
access-group cloud2to1 in interface outside

PIX #2:

ip address inside 10.15.0.1 255.255.255.0
ip address outside 10.16.0.2 255.255.255.252
static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
route outside 10.17.0.0 255.255.255.0 10.16.0.1

access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0 255.255.255.0

access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0 255.255.255.0

access-group cloud2to1 in interface inside
access-group cloud1to2 in interface outside


In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
remote device 10.15.0.x, and devices in cloud 2 have to address
10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
addressing by direct IP address, they will just have to know that. If they
are using hostnames or urls with hostnames, the translation will happen
provided that you make the appropriate adjustments to include a DNS
server or two.
--
WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,v onNeumann}D ?

"Walter Roberson" <> wrote in message
news:cu1cr3$ljf$...
> In article <nRVMd.19820$Vg3.8086@lakeread05>,
> Gary <> wrote:
>
> :Can the pix handle the same network on both inside and outside
interfaces.
>
> No, definitely not.
>
>
> :I simply want the pix to protect some machines in the 10.15.0.0/24 from
other
> :machines in the 10.15.0.0/24 range
> :i.e Like a filter between hosts
>
>
> {10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
> ______________________10.1?.0.x___________________ _|
> |
> --- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}
>
>
> PIX #1:
>
> ip address inside 10.15.0.1 255.255.255.0
> ip address outside 10.16.0.1 255.255.255.252
> static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
> route outside 10.18.0.0 255.255.255.0 10.16.0.2
>
> access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
> access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0
255.255.255.0
>
> access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
> access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0
255.255.255.0
>
> access-group cloud1to2 in interface inside
> access-group cloud2to1 in interface outside
>
> PIX #2:
>
> ip address inside 10.15.0.1 255.255.255.0
> ip address outside 10.16.0.2 255.255.255.252
> static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
> route outside 10.17.0.0 255.255.255.0 10.16.0.1
>
> access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
> access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0
255.255.255.0
>
> access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
> access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0
255.255.255.0
>
> access-group cloud2to1 in interface inside
> access-group cloud1to2 in interface outside
>
>
> In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
> remote device 10.15.0.x, and devices in cloud 2 have to address
> 10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
> addressing by direct IP address, they will just have to know that. If they
> are using hostnames or urls with hostnames, the translation will happen
> provided that you make the appropriate adjustments to include a DNS
> server or two.
> --
> WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,v onNeumann}D ?

Are you saying I will need 2 PIX's to do this.

I cannot see what you are detailing here - Looks like 2 PIX's reflecting the
address space to basically route between 2 - 10.15.0.0 interfaces.

DNS is not relevant at all as they will always be referenced by IP.

I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX the
right device?

BTW What does the WW{...}D mean in your signature. I see the great names
etc - Is the WWD some programming language

Gary

Gary

In article <maXMd.19831$Vg3.4942@lakeread05>,
Gary <> wrote:

> Are you saying I will need 2 PIX's to do this.
>
> I cannot see what you are detailing here - Looks like 2 PIX's reflecting
> the address space to basically route between 2 - 10.15.0.0 interfaces.
>
> DNS is not relevant at all as they will always be referenced by IP.
>
> I guess is I need 2 PIX's to do this it begs the questions - Is a PIX
> the right device?

As an alternative for this specific requirement, the Transparent Cisco IOS
Firewall might be a better fit, as introduced in 12.3(7)T, unless you
require specific functionality from PIX, which is not available in CBAC
(Cisco IOS Firewall).

Cheers,

Matt

--
Matthew Melbourne

In article <maXMd.19831$Vg3.4942@lakeread05>,
Gary <> wrote:
:Are you saying I will need 2 PIX's to do this.

I'm not sure at the moment.

Suppose you have just 1 PIX. Recall what I said about it not
being possible for the two interfaces to be in the same subnet.
So let the inside of the PIX be in 10.15.0/24, and let the outside
be in some other range (e.g., 10.16.0.1/29). One can then use
static (inside, outside) 10.15.0.23 10.15.0.23 netmask 255.255.255.255
and so on for each invidual 10.15.0/24 IP that is on the inside of
the PIX; this will allow the outside of the PIX to proxy arp for those
IPs, so if the PIX is put onto the same segment as the other 10.15.0/24
then the PIX will transparently grab traffic for those inside IPs
even though the PIX outside interface is in a different subnet.

Now the question becomes how to reverse the process, and allow the
10.15.0/24 on the "outside" of the PIX to be visible inside.
What can be tried is, e..g.,

static (outside,inside) 10.15.0.88 10.15.0.88 netmask 255.255.255.255 outside
route outside 10.15.0.88 255.255.255.255 10.16.0.1

I have confirmed that if that is set up that the PIX will build
translations as if it is going to send the packet out, but I have not
yet been able to confirm that the PIX actually sends the packets out.
Using 'capture' against the inside interface, I can see that the
packets are accepted by the inside interface, but capture against the
outside interface does not appear to show the packet leaving.
My equipment here is not set up to be able to test the scenario
by placing devices on both sides.


:I cannot see what you are detailing here - Looks like 2 PIX's reflecting the
:address space to basically route between 2 - 10.15.0.0 interfaces.

Sort of. It's the ole switcheroo: if you need to talk about IPs that
you can't talk about, then you talk about other IPs instead and let
the PIX translate them into the real IPs.


:I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX the
:right device?

Probably not with 6.x. I cannot tell from the feature summaries for 7.0
whether it will be possible in 7.0.
--
Live it up, rip it up, why so lazy?
Give it out, dish it out, let's go crazy, yeah!
-- Supertramp (The USENET Song)

"Walter Roberson" <> wrote in message
news:cu3097$oao$...
> In article <maXMd.19831$Vg3.4942@lakeread05>,
> Gary <> wrote:
> :Are you saying I will need 2 PIX's to do this.
>
> I'm not sure at the moment.
>
> Suppose you have just 1 PIX. Recall what I said about it not
> being possible for the two interfaces to be in the same subnet.
> So let the inside of the PIX be in 10.15.0/24, and let the outside
> be in some other range (e.g., 10.16.0.1/29). One can then use
> static (inside, outside) 10.15.0.23 10.15.0.23 netmask 255.255.255.255
> and so on for each invidual 10.15.0/24 IP that is on the inside of
> the PIX; this will allow the outside of the PIX to proxy arp for those
> IPs, so if the PIX is put onto the same segment as the other 10.15.0/24
> then the PIX will transparently grab traffic for those inside IPs
> even though the PIX outside interface is in a different subnet.
>
> Now the question becomes how to reverse the process, and allow the
> 10.15.0/24 on the "outside" of the PIX to be visible inside.
> What can be tried is, e..g.,
>
> static (outside,inside) 10.15.0.88 10.15.0.88 netmask 255.255.255.255
outside
> route outside 10.15.0.88 255.255.255.255 10.16.0.1
>
> I have confirmed that if that is set up that the PIX will build
> translations as if it is going to send the packet out, but I have not
> yet been able to confirm that the PIX actually sends the packets out.
> Using 'capture' against the inside interface, I can see that the
> packets are accepted by the inside interface, but capture against the
> outside interface does not appear to show the packet leaving.
> My equipment here is not set up to be able to test the scenario
> by placing devices on both sides.
>
>
> :I cannot see what you are detailing here - Looks like 2 PIX's reflecting
the
> :address space to basically route between 2 - 10.15.0.0 interfaces.
>
> Sort of. It's the ole switcheroo: if you need to talk about IPs that
> you can't talk about, then you talk about other IPs instead and let
> the PIX translate them into the real IPs.
>
>
> :I guess is I need 2 PIX's to do tyhis it begs the questions - Is a PIX
the
> :right device?
>
> Probably not with 6.x. I cannot tell from the feature summaries for 7.0
> whether it will be possible in 7.0.
> --
> Live it up, rip it up, why so lazy?
> Give it out, dish it out, let's go crazy, yeah!
> -- Supertramp (The USENET Song)

Do not mind using 2 PIX's but need to know if it will work before I buy
another.

Is your solution a real one that will work or best guess. It looks good to
me.

Gary

In article <BC8Nd.20417$Vg3.11209@lakeread05>,
Gary <> wrote:
o not mind using 2 PIX's but need to know if it will work before I buy
:another.

:Is your solution a real one that will work or best guess. It looks good to
:me.

I have used a similar solution to deal with overlapping address spaces
for a VPN tunnel:

172.16.N/24 -- remote vpn concentrator <==VPN==> our PIX 172.16/16

On our pix,

name 192.P.Q.R ALocalServer
name 172.16.N.80 RemoteHostIP
name 172.17.N.80 LocalMappedIP

access-list vpn2remote permit ip host ALocalServer host RemoteHostIP

static (outside,inside) RemoteHostIP LocalMappedIP netmak 255.255.255.255 0 0

crypto map vpn-map 1000 match address vpn2remote

When our local server wants to talk to RemoteHostIP (which overlaps one
of our internal networks), we address the packets to LocalMappedIP
instead. The PIX sees the reverse nat [notice the interface order
change], it rewrites the destination IP that we used internally
into the real destination IP and then notices that that the result
matches the vpn tunnel ACL vpn2remote so it pushes the traffic through
the tunnel. It so happens that all of the hosts that RemoteHostIP
needs to talk to on our side are in public IP space, not in the overlapped
IP space [well, it's not really an accident -- we use public IP space
for any host that has to be remotely reachable] so in our situation
there is no issue about having to get the remoted end to do the same
kind of mapping trick. The trick can in theory be done with only
one side doing the mapping, by using both a
static (outside,inside) and a static (inside,outside)
but I haven't tested that.


o not mind using 2 PIX's but need to know if it will work before I buy
:another.

That's what lab tests are for. You do enough PIX work that you should have
an extra PIX 501 or two on hand specifically to be able to test out
scenarios and test out PIX software upgrades and to syntax-check
notable configuration rewrites before putting the revised config
onto a production system.

Keep in mind that entry PIX 501's have that 10 user license, so
you probably would want to go for PIX 506E if you have more than ~20
hosts on each side.

Other thing to keep in mind is that having a PIX or two in the
middle is *not* the same as having a "transparent filter": there are
differences in UDP handling and especially differences in TCP handling
when it comes to long-running connections. And if you have netbios
in there, it really becomes a pain as the PIX doesn't rewrite
addresses that are flowing through TCP 139 [or so the TAC told me
two days ago.]

You also have a problem if the devices on the two "clouds" are on
the same segment without any choke-point inbetween: in such a case,
anyone could get around the filter by simply directly addressing the
remote system instead of addressing the mapped IP corresponding
to the remote system.

If you do have a choke point, then considering that everyone on
one side is going to have to use other IPs to address everyone on
the other side, it probably makes more sense to simply put in one
PIX total and re-number the hosts on one side so they are no longer
in 10.15.0/24.
--
Are we *there* yet??

PIX 7.0 software will do this, as it can be a transparent firewall, but
software is to be released later this year....

L@rs
"Gary" <> wrote in message
news:nRVMd.19820$Vg3.8086@lakeread05...
> Can the pix handle the same network on both inside and outside interfaces.
> I
> simply want the pix to protect some machines in the 10.15.0.0/24 from
> other
> machines in the 10.15.0.0/24 range
>
> i.e Like a filter between hosts
>
> Gary
>
>

> :Can the pix handle the same network on both inside and outside
interfaces.
>
> No, definitely not.
>
>
> :I simply want the pix to protect some machines in the 10.15.0.0/24 from
other
> :machines in the 10.15.0.0/24 range
> :i.e Like a filter between hosts
>
>
> {10.15.0/24 cloud 1} ---- 10.15.0.1 [PIX #1] 10.16.0.1
> ______________________10.1?.0.x___________________ _|
> |
> --- 10.16.0.2 [PIX #2] 10.15.0.1 ---- {10.15.0/24 cloud 2}
>
>
> PIX #1:
>
> ip address inside 10.15.0.1 255.255.255.0
> ip address outside 10.16.0.1 255.255.255.252
> static (inside, outside) 10.17.0.0 10.15.0.0 netmask 255.255.255.0 dns
> route outside 10.18.0.0 255.255.255.0 10.16.0.2
>
> access-list cloud1to2 deny ip host 10.15.0.39 host 10.18.0.82
> access-list cloud1to2 permit ip 10.15.0.0 255.255.255.0 10.18.0.0
255.255.255.0
>
> access-list cloud2to1 deny ip host 10.18.0.82 host 10.17.0.81
> access-list cloud2to1 permit ip 10.18.0.0 255.255.255.0 10.17.0.0
255.255.255.0
>
> access-group cloud1to2 in interface inside
> access-group cloud2to1 in interface outside
>
> PIX #2:
>
> ip address inside 10.15.0.1 255.255.255.0
> ip address outside 10.16.0.2 255.255.255.252
> static (inside, outside) 10.18.0.0 10.15.0.0 netmask 255.255.255.0 dns
> route outside 10.17.0.0 255.255.255.0 10.16.0.1
>
> access-list cloud2to1 deny ip host 10.15.0.82 host 10.17.0.81
> access-list cloud2to1 permit ip 10.15.0.0 255.255.255.0 10.17.0.0
255.255.255.0
>
> access-list cloud1to2 deny ip host 10.17.0.39 host 10.18.0.82
> access-list cloud1to2 permit ip 10.17.0.0 255.255.255.0 10.18.0.0
255.255.255.0
>
> access-group cloud2to1 in interface inside
> access-group cloud1to2 in interface outside
>
>
> In this setup, devices in cloud 1 have to address 10.18.0.x to talk to
> remote device 10.15.0.x, and devices in cloud 2 have to address
> 10.17.0.x to talk to remote device 10.15.0.x in cloud 1. If they are
> addressing by direct IP address, they will just have to know that. If they
> are using hostnames or urls with hostnames, the translation will happen
> provided that you make the appropriate adjustments to include a DNS
> server or two.
> --
> WW{Backus,Church,Dijkstra,Knuth,Hollerith,Turing,v onNeumann}D ?


OK> One more detail. The machines either side of the PIX's cannot change
what IP's they talk to. They can only talk to 10.15.0.0/24 address's. Can we
use ARP on the PIX's to somehow allow this?

Gary