<Longish explanation>

I'm stumped with an IP address Range issue I fear can't be easily solved
:(
Suppose a Pix with 5.1(2) and a router (3640) with Ios 11.2(9)+ (yes yes
I know, I hope it'll be 12.1 soon).

"Server"
|
| Internal network
|
Pix
|
|................. .100, mapped "Server"
| DMZ, 10.64.1/24
|
router
|\\\\
various connections

Server is mapped with static to DMZ, let's pretend 10.64.1.100 .
the router has several connections, some frame relay, some isdn ecc (not
important). The other side of the connections (commercial partners)
sometimes have overlapping networks, can't/won't use nat, or are
generally not under our control.
So some connections can't handle the 10.64.1/24 address range, however
being usually outbound connections those are handled by

int eth 0/0
 ip nat inside

int SOMEINT
 ip address SOMEINTADDR 255.255.255.0
 ip nat outside

ip route <REMHOST> SOMEINT

ip nat outside source static <Outside/Global IP of REMHOST> <REMHOST>

ip nat inside source route-map SOME-MAP interface SOMEINT overload

route-map SOME-MAP
 match ip address SOME-LIST

ip access-list extended SOME-LIST
 permit ip host 10.64.1.100 host <REMHOST>


e.g. nat outside address to a range of our liking and overload the
outgoing connection to the address specified on the interface. Not the
best configuration probably, but working.

Now, even with multiple concurrent connections like those there are no
problems since the entries in the nat translation table are complete
ip/port-ip/port.
Now there comes an inbound/outbound connection with nat, which does mean
a static mapping:

ip nat inside source static 10.64.1.100 <SOMEOTHERNET>.100
int SOMEOTHERINT
 ip address <SOMEOTHER_NET>.1 255.255.255.0
 ip nat outside

You probably can see where this is leading to - collision. For example,
if a connection from SERVER (through the pix) to the remote net is in
action there is an IP-IP entry in the address translation table. If at
the same time Server tries to initate a connection to REMHOST (need of
overload/PAT on SOMEINT) this does fail, outgoing packets to REMHOST
have a <SOMEOTHERNET>.100 source address instead of SOMEINTADDR,
communication fails.

Now AFAIK there is no way in Ios 11.2 to change this (if there is better
way to do this please tell me where to look in the documentation and
you'll have solved my problems. Sample conf would be nice, too :).
A solution would be moving a connection to another router, but isn't
really scalable (one router for every connection)
Same for "one server for every connection" <grin>

The pix is not capable to perform specific NAT based on
SOURCEIP[port]-DESTIP[port] (like FW-1), only fixed nat through static,
based on SOURCEIP, or dynamic with a pool, so it isn't even possible to
nat the internal address to different (fixed) DMZ addresses based on
destination ports.

I'm wondering if it is possible (although after a quick glance in the
manual I fear not) adding secondary addresses to the pix/interfac DMZ
and the router/interface Ethernet (say in 172.16.1/24), static the
server to 172.16.1.100, having effectively another DMZ on the same
physical network. Point the routing for the new connection to
router/eth-newDMZ-addr instead of router/eth-DMZ-addr, and avoid nat
collision on the router (since the source address would be different).
This would be somewhat scalabale also, since that additional DMZ can be
as small as necessary (/29 would be fine), and could be located in every
address range not already used somehwere else in the pix or the router
(of course I suppose adding too much additional addresses to the
interface could create problems.. OTOH with more different numbered DMZs
you have less probability none of those are usable on the other side of
the connection).

Any idea how to implement this ? Or how to implemement some other
scalable solution for this issue in any other way ?

Heiko

-- 
-- PREVINET S.p.A.            [EMAIL PROTECTED]
-- Via Ferretto, 1         ph  x39-041-5907073
-- I-31021 Mogliano V.to (TV) fax x39-041-5907087
-- ITALY

_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to