6500 FWSM question

Hi,

Is it possible to do the following :

On one 6500 FWSM create the following static :

External IP : 206.47.230.99
Inside Address: 10.250.128.50

On a second 6500 FWSM create the following static :

Inside Address : 10.250.128.50
DMZ Address : 172.16.15.15

Basically 1 static externally translated to another static
internally. Assuming that there were 2 paths (ISP's) available
back out, would the above static mappings preserve the
session. That is would the initial external address of
206.47.230.99 be used to route back as well ?

Thanks,
Joe

 

: Is it possible to do the following :

:On one 6500 FWSM create the following static :

:External IP : 206.47.230.99
:Inside Address: 10.250.128.50

:On a second 6500 FWSM create the following static :

:Inside Address : 10.250.128.50
MZ Address : 172.16.15.15

:Basically 1 static externally translated to another static
:internally.

:Assuming that there were 2 paths (ISP's) available
:back out, would the above static mappings preserve the
:session. That is would the initial external address of
:206.47.230.99 be used to route back as well ?

I'm confused about the way the two 6500's and the two ISPs are
connected.

If the Inside of the first 6500 is connected to the Inside of
the second 6500, then Yes, packets on the DMZ of the second 6500
that were addressed to 172.16.15.15 would become packets addressed
to 206.47.230.99 on the way out.

I would be concerned, though, about whether all dynamic protocols would
work properly; I'm not certain at the moment that all the fixups apply
when going from a higher security interface to a lower security
interface, as would happen on your second 6500, Inside to DMZ.
[e.g., I don't think the SMTP fixup applies to what would be
considered -outgoing- email.]

I don't see where the second ISP fits in to your question ??

 

Thanks for the reply. The two ISP paths are used for different
traffic. We put HTTP on one pipe and other traffic on the other pipe.
I just wanted to be sure that the inbound static would preserve its
state when going back to the original request.

-Joe