outside initiated traffic to access internal network range through pix firewall with translation

Hi,

I have a pix sat between 2 internal networks:-

(inside)10.0.0.0 ----> Pix <---- 192.168.1.0(outside)

I need to allow the 192 traffic to be able to contact the 10 network without
translation, I've been working on it for days with no joy if i enable nat
and translate the 10.0.0.x to a 192.168.1.x address i can contact it fine
but i need to be able to access 10.0.0.x directly through the
pix.(outside ---> in).

Is this possible? if so how?

Many Thanks,

Wehay.

 

:I have a pix sat between 2 internal networks:-

inside)10.0.0.0 ----> Pix <---- 192.168.1.0(outside)

:I need to allow the 192 traffic to be able to contact the 10 network without
:translation, I've been working on it for days with no joy if i enable nat
:and translate the 10.0.0.x to a 192.168.1.x address i can contact it fine
:but i need to be able to access 10.0.0.x directly through the
ix.(outside ---> in).

:Is this possible? if so how?

Depends which PIX version you have. From PIX 6.2, you can use

access-list nonat permit ip 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0
nat (inside) 0 access-list nonat

However, this has two very important side effects:

a) Proxy ARP will not be active for 10.0.0.x on the outside interface; and
b) 192.168.1.x will be able to connect to any 10.0.0.x host when the
outside access-group permissions permit, even if there is no 'static'
statement permitting the destination host to receive new connections.

If you have PIX 6.3(2) or later, you can use

access-list nonat permit ip 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0
static (inside,outside) 10.0.0.0 access-list nonat


Note that if you also have a plain static for one of the 10.0.0.x IPs, such as

static (inside,outside) 192.168.3.17 10.0.0.99 netmask 255.255.255.255

with the intention that that static be used for communication with
other outside destinations (e.g., external www sites), then the two solutions
above react differently. In the first solution, the nat 0 access-list takes
priority over every other kind of translation. In the second solution, the
policy static is lower priority, with the plain static being second
priority, so the plain static would take effect and the policy static
would be ignored. You cannot successfully mix plain static NAT or static PAT
(port translation) and either policy static or policy nat: the non-policy
static forms are higher priority than policy static or NAT [but
nat 0 access-list is highest priority of all.]


Looking at the way you have your diagram set up, where the destinations
you want not to be translated being the same as the outside network,
I am led to wonder whether you are really trying to use the PIX as a
transparent filter -- to have it in the network and not interfering
with any traffic except to block some access ? If so, then you will
find that up through the latest PIX 6 [6.3(4)], the PIX is NOT
suitable as a transparent filter. (This is addressed in PIX 7.0 which
should be available for download within days; 7.0 can be used
on the PIX 515/515E, 525, and 535, but not the 501 or 506/506E or 520.
The 520 will never be supported; the others should be in time.)

Some of the ways that PIX 6 is not suitable to be a transparent filter:

- no broadcasts will be permitted through. No ARP, no DHCP, no
NETBIOS resource advertisements.

- Only IP will be permitted through. No IPX, no Appletalk, etc.

- TCP connections will time out after inactivity. On a completely
transparent filter, it would not matter if a TCP connection was
idle for a week (or a month) because all the non-forbidden packets
would be let through. On a PIX, though, through PIX 6, TCP packets are
only permitted if they fit into one of the active connections (or
are acceptable candidates for starting new connections.)

- RPC pinholes are only held open for a limited time. RPC is
mostly associated with NFS and NIS, but Remote Procedure Call (RPC)
is also the same kind of mechanism used by Microsoft's Endpoint Mapper
(TCP 135). The general idea is that host A does not know what port
a particular service is located at on host B, so it contacts a
well-known port (111 for Sun RPC, 135 for MS RPC) and asks about
the service, and gets told the port number. The PIX monitors those
transactions and automatically opens the filters for a short time
to allow the connection to proceed [but it doesn't do a very
thorough job of it ] This can get to be a serious problem if
you have NETBIOS over TCP/IP used to locate a service, such as
many of the transactions used by MS Exchange, or programs such as
OrCad; the same problem happens with Sun RPC and the FlexLM license
server. With MS Exchange in particular, both ends of the transaction
remember the port that was negotiated and feel free to just blindly
go ahead and try to use the same port, sometimes *weeks* after
the original connection [I know -- I've traced the IP + port quad
back through our extensive firewall logs several times.]

- Only a very very limited number of IP options are supported.

- TCP Precedence is not supported; no other form of QoS is supported
either [this is addressed in PIX 7.0]

- sequence number randomization will be done, unless specifically turned off

- 802.1Q VLAN information is not carried through

- TCP Maximum Segment Size (MSS) will be overridden, unless this is
specifically turned off


I'm sure I've missed some other ways.

 

Walter,

Wow thanks for taking the time to go into all that for me. I feel some what
ashamed of the description i gave now. i'll explain the full scenario.

We are implementing a MPLS network to connect the european sites together.
there will be 4 sites and an internet gateway. the main site SITE1 will be
where all the main systems are, and this has 2x 2mb circuits with dual hsrp
and those CE routers are connected to a switch which i have enabled 3 ports
TRUNKED (2 for the routers and 1 for the outside interface of the PIX) as
the internet link will be delivered to my PIX firewall as a VLAN (ios
6.3(4)).

SITE1 :- has internal address range 10.0.0.0/22 but they will be advertised
on the MPLS as /23 as to do some crude load balancing, the network range
between the CE router and the PIX is the 192.168.1.x range.

SITE2:- has internal address range 10.0.4.0/22 but the CE router is sat on
directly on that network.

SITE3:- 10.0.8.0/22 as site2

SITE4:- 10.0.12.0/22 as site2

and yes you were right i am trying to use the PIX as a transparent filter,
but to give us the control of which ports are open and shut. as well as
Terminate VPN's, and be the internet gateway for all sites.

I need SITE2 (and the others) to be able to access the central systems on
SITE1 by using the 10.0.0.x ip address else the "crude load balancing"
(10.0.0.0/23 & 10.0.2.0/23 being advertised) will be ignored as i'd have to
access the systems by publishing 10.0.0.x as 192.168.1.x.

by what you've said it sounds like my hands are tied and i'll either have to
hope IOs Ver7 is released in the next couple of days or i'll be publishing
them on the 192.168.1.0 network.

Much Appreciated!!

 

Just a thought,

We do have another pix setup in which I have the DMZ (172.16.2.0/24) access
the Internal network (172.16.1.0/24) directly. On the PIX i am trying to set
up i have a 4 port network card added.

Could I advertise the 192.168.1.0 network out of one of the "DMZ" interfaces
and treat that as the outside interface and disable the Outside interface
(ethernet0)?

If so how? i've tried all the config i can think of but still not getting
any joy.