Changing public (outside) IP's on Cisco PIX 515e

Discussion in 'Cisco' started by Scot Desort, Jul 13, 2004.

  1. Scot Desort

    Scot Desort Guest

    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 Desort, Jul 13, 2004
    #1
    1. Advertising

  2. 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.
     
    Walter Roberson, Jul 13, 2004
    #2
    1. Advertising

  3. Scot Desort

    Scot Desort Guest

    > 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
    :eek: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, Jul 13, 2004
    #3
  4. Scot Desort

    v500.com Guest

    "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
     
    v500.com, Jul 13, 2004
    #4
  5. 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
    |:eek: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
    :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?

    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.
     
    Walter Roberson, Jul 13, 2004
    #5
  6. In article <cd1ei3$d8v$>,
    Walter Roberson <-cnrc.gc.ca> 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
     
    Walter Roberson, Jul 14, 2004
    #6
  7. 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!
     
    Walter Roberson, Jul 14, 2004
    #7
  8. Scot Desort

    josiahbryan

    Joined:
    Jan 13, 2009
    Messages:
    1
    followup

    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?
     
    josiahbryan, Jan 13, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page