«

We are assisting a customer who will be getting a new block of public IP's
assigned to them.

Many users accessing the internal hosts from outside the firewall do so via
IP. Some also use DNS name resolution

To make the transition gradual, we want to direct all requests to both the
current public IP and the NEW public IP to be translated to the current,
single internal IP host.

According to Cisco, PIX only permits a one-to-one mapping. Therefore, the
following is not possible:

Current Public IP 192.800.800.800 port 80 ---> inside host 10.0.0.1 port 80
New Public IP 192.900.900.900 port 80 ---> inside host 10.0.0.1 port 80

According to a Cisco FAQ:

The Cisco Secure PIX Firewall only allows a single one-to-one translation
for a local (inside) host. If you have more than two interfaces on the Cisco
Secure PIX Firewall, you can translate a local address to different
addresses on each respective interface but only one translation per
interface is allowed for each address.

So we would have to get another interface for the PIX, which I do not
believe is possible with their current license.

Are there any other options to accomplish this? My last resort would be to
see if we can add an additional inside IP number to the same 10.0.0.1 host,
so we could add a translation to this new internal IP. PIX should allow
this, even though it is really mapping to the same internal host.

Ideas would be welcomed...

Thanks,

Scot

In article <>,
Scot Desort <> wrote:
:We are assisting a customer who will be getting a new block of public IP's
:assigned to them.

:Many users accessing the internal hosts from outside the firewall do so via
:IP. Some also use DNS name resolution

:To make the transition gradual, we want to direct all requests to both the
:current public IP and the NEW public IP to be translated to the current,
:single internal IP host.

:According to Cisco, PIX only permits a one-to-one mapping. Therefore, the
:following is not possible:

:Current Public IP 192.800.800.800 port 80 ---> inside host 10.0.0.1 port 80
:New Public IP 192.900.900.900 port 80 ---> inside host 10.0.0.1 port 80

That is correct. Otherwise, when the PIX went to initiate packets
outward, it would not know which IP to use.

The closest you can get to what you want is to use PIX 6.3(3) and
policy routing. That would allow you to use different public IPs
to different addresses -- for example, if it was mainly one big
customer that used the old IP and they had a well defined address
block, you could set the PIX up to translate the old address when
the source was that particular block, and otherwise translate the
new address for everyone else.

:So we would have to get another interface for the PIX, which I do not
:believe is possible with their current license.

You say they have a PIX 515e. The 515e supports 3 interfaces in
the Restricted license, and has always done so. (The PIX 515 [no 'e']
Restricted used to support only 2 interfaces, but that was upgraded to
3 interfaces as of PIX 5.1(2).)
--
"Infinity is like a stuffed walrus I can hold in the palm of my hand.
Don't do anything with infinity you wouldn't do with a stuffed walrus."
-- Dr. Fletcher, Va. Polytechnic Inst. and St. Univ.

> That is correct. Otherwise, when the PIX went to initiate packets
> outward, it would not know which IP to use.

> The closest you can get to what you want is to use PIX 6.3(3) and
> policy routing. That would allow you to use different public IPs
> to different addresses -- for example, if it was mainly one big
> customer that used the old IP and they had a well defined address
> block, you could set the PIX up to translate the old address when
> the source was that particular block, and otherwise translate the
> new address for everyone else.

Unfortunately, the packets will be originating from hundreds of different
IP's spread all over. No real way to even define them.

I found another post in this newgroup with a similar question. Here is a
snippet:

====
:Basically, I want to use two ranges of public IP's. I can't use NAT
n the internal network.
:If I can't add a secondary IP, can I somehow map both IP's to go
:through the firewall?

Yes. Just ensure that the second IP range is routed to the PIX
outside address in the first range. After that, any static/nat's
you have will take care of allowing the IPs to be accepted. If the
IPs are going to different interfaces then you do not need to do
anything else. If the IPs are going to the same interface, then you
will need to add at least one 'route' statement to point the second
range to the appropriate router behind the desired interface.

We have several IP ranges hiding behind a single interface on our main
PIX.

[Note: if you are running a new enough version of PIX, then on
the 515 and higher models, you can have multiple logical interfaces
on the same physical interface, by using VLANs. Each logical interface
should be a different security level.]
====

I didn't fully understand the responder's instruction to add a route
statement. The original poster is not running NAT, and my customer is. So
perhaps that is what the responder was referring to -- routing the packets
OUT from the inside to the router on the public side of the firewall? Does
the response make sense to anyone else?


--
Scot

"Scot Desort" <> wrote in message news:<>...
> We are assisting a customer who will be getting a new block of public IP's
> assigned to them.
>
> Many users accessing the internal hosts from outside the firewall do so via
> IP. Some also use DNS name resolution
>
> To make the transition gradual, we want to direct all requests to both the
> current public IP and the NEW public IP to be translated to the current,
> single internal IP host.
>
> According to Cisco, PIX only permits a one-to-one mapping. Therefore, the
> following is not possible:
>
> Current Public IP 192.800.800.800 port 80 ---> inside host 10.0.0.1 port 80
> New Public IP 192.900.900.900 port 80 ---> inside host 10.0.0.1 port 80
>
> According to a Cisco FAQ:
>
> The Cisco Secure PIX Firewall only allows a single one-to-one translation
> for a local (inside) host. If you have more than two interfaces on the Cisco
> Secure PIX Firewall, you can translate a local address to different
> addresses on each respective interface but only one translation per
> interface is allowed for each address.
>
> So we would have to get another interface for the PIX, which I do not
> believe is possible with their current license.
>
> Are there any other options to accomplish this? My last resort would be to
> see if we can add an additional inside IP number to the same 10.0.0.1 host,
> so we could add a translation to this new internal IP. PIX should allow
> this, even though it is really mapping to the same internal host.
>
> Ideas would be welcomed...
>
> Thanks,
>
> Scot

Scot,
I think it is possible to create a virtual interface and assign new IP
address to it:
nameif <vlan_id> <if_name> <security_lvl>
You will endup with one physical int - interface0 (outside)with
security level 0
and logical int - interface2 (outside 2)shall we
say with security level 10

Then you can do acces lists and static translations

Regards

Daniel

In article <>,
Scot Desort <> wrote:
|I found another post in this newgroup with a similar question. Here is a
|snippet:

|:>Basically, I want to use two ranges of public IP's. I can't use NAT
|:>on the internal network.
|:>If I can't add a secondary IP, can I somehow map both IP's to go
|:>through the firewall?

|:Yes. Just ensure that the second IP range is routed to the PIX
|utside address in the first range.


:I didn't fully understand the responder's instruction to add a route
:statement. The original poster is not running NAT, and my customer is. So
erhaps that is what the responder was referring to -- routing the packets
:OUT from the inside to the router on the public side of the firewall? Does
:the response make sense to anyone else?

You didn't look closely to see who wrote that response. I recognize my
writing when I see it

The posting you refer to was dealing with the case where the PIX was
being asked to handle multiple disjoint internal subnets. You asked
about handling multiple IP addresses, without specifying whether they
were the same subnet or different subnets and without specifying whether
they had to appear to be the same or different subnets internally.
[Sorry if I'm mixing your posting up with someone else's.]

If you are asking one PIX interface to handle multiple disjoint subnets,
then because each PIX interface only has one subnet associated with it,
you have to add 'route' statements to tell the PIX which *internal*
interface to send the packets to. Even if you only have two interfaces,
the PIX does not assume that the inside interface will be the destination
for packets -- it assumes that if you don't tell it otherwise, the
proper thing to do is drop the packets in the bit bucket. The PIX is,
after all, designed to only pass packets when you have clearly defined
destinations and permissions, and it is designed to assume that anything
unclear is not permitted.
--
100% of all human deaths occur within 100 miles of Earth.

In article <cd1ei3$d8v$>,
Walter Roberson <> wrote:
:If you are asking one PIX interface to handle multiple disjoint subnets,
:then because each PIX interface only has one subnet associated with it,
:you have to add 'route' statements to tell the PIX which *internal*
:interface to send the packets to.

To clarify: that applies if you are asking the PIX to handle multiple
*internal* subnets. For example, we have the same PIX internal
interface handling some of our 192.* and some of our 207.* subnets.
To make this work, we have an internal LAN router, and we have
'route' statements on the PIX that point the subnets through the
internal interface.

In the case where you only have one internal subnet but you have
multiple external subnets that are all being handled by the one internal
subnet, you do not need to add 'route' statements on the PIX. You do,
though, need to be sure that your next hop outwards will properly
hand the different addresses over to the PIX, either through the
magic of proxy arp, or through explicit route statements at the router
level [routing the public IPs.]
--
Cottleston, Cottleston, Cottleston pie.
A bird can't whistle and neither can I. -- Pooh

In article <> ,
v500.com <> wrote:
:"Scot Desort" <> wrote in message news:<>...
:> We are assisting a customer who will be getting a new block of public IP's
:> assigned to them.

:I think it is possible to create a virtual interface and assign new IP
:address to it:
: nameif <vlan_id> <if_name> <security_lvl>
:You will endup with one physical int - interface0 (outside)with
:security level 0
: and logical int - interface2 (outside 2)shall we
:say with security level 10

:Then you can do acces lists and static translations

That has uses, but it also has restrictions, some of which make it
unsuitable for Scot.

a) It only works with PIX 515, 515E, 520, 525, and 535 (and the FWSM)

b) It requires that your outside interface be an 802.1Q trunk port
[and thus that your next hop over support 802.1Q]

c) It requires that the return packets be routable back to the appropriate
interface. Scot indicates that he could have addresses from all over
connecting to either of the two IPs, so there is no 'route' statement
that Scot would be able to use to send replies to "the interface
the packet came in on." Recall that reply packets are coming from
internal devices, long past the PIX's control to tag any sort of
incoming interface information into, so it all has to work by IP address
alone.

d) In line with the above: multiple default routes isn't going to do
useful things unless one of the interfaces goes down.


There -is- a way that Scot could arrange the packets to get back to the
proper interface. If Scot were to use virtual interfaces (or a second
physical interface), and were to use "reverse NAT", then he could
re-write (PAT) the source IPs as they came in, effectively tagging them
as to the incoming interface. With appropriate return routes to the
re-written source IP addresses, he could get the return traffic back out the
correct interface, with the source IP that the user had used to
connect with. The disadvantage of this technique is that as far as the
internal systems are concerned, *all* of the external traffic comes from
one of those two IPs -- it becomes impossible to (say) anti-spam or
do any useful logging that requires knowing the original IP address.
--
vi -- think of it as practice for the ROGUE Olympics!

[josiahbryan]

Rather new to the *advanced* pix configs - I've been doing basic pix config/maint for the past 3 years.

I'm used to the linux method if adding an alias to an interface, ala "ifconfig eth0:0 1.2.3.4" and "ifconfig eth0:1 5.6.7.8" and so on and so forth.

Basically, is that possible with the PIX? (Running PIX ver 6.3(3))

(Of course, I'd like to be able to do static translation based on incoming IP, but I think I've got that line covered: "static (inside,outside) tcp 1.2.3.4 smtp 10.0.1.51 smtp netmask 255.255.255.255 0 0").

How do I add the "alias" to the outside interface?

Is it as simple as picking a random vlan id for the "nameif X outside2 0"

And then assinging an IP to outside2, and setting up the ACLs, etc accordingly?

Or is there some other black magic to setup an "alias" for the outside IP?