Temporary extra global ip on Pix 501

Discussion in 'Cisco' started by BG, Sep 21, 2004.

  1. BG

    BG Guest

    We're gonna change ISP and I thereby need to change the outside interface on
    the Pix 501. In order to have the mail server working with the updated DNS I
    need to run both the new and the old interface IPs for about 24 hrs. I have
    seen configs like this:

    global (outside) 1 XXX.XXX.XXX.XXX
    global (outside) 2 xxx.xxx.xxx.xxx

    and with NATing for both interfaces. Both does this really work? Is there
    any way to have 2 adresses on the outside interface like I intend?


    BG
    BG, Sep 21, 2004
    #1
    1. Advertising

  2. In article <UzW3d.8283$>,
    BG <> wrote:
    :We're gonna change ISP and I thereby need to change the outside interface on
    :the Pix 501. In order to have the mail server working with the updated DNS I
    :need to run both the new and the old interface IPs for about 24 hrs. I have
    :seen configs like this:

    :global (outside) 1 XXX.XXX.XXX.XXX
    :global (outside) 2 xxx.xxx.xxx.xxx

    :and with NATing for both interfaces. Both does this really work? Is there
    :any way to have 2 adresses on the outside interface like I intend?

    You can have multiple global (outside) statements that refer to different
    IP address ranges, but for each policy number, you must have at least
    one matching nat (inside) statement with the same policy number,
    and the address ranges designated by those inside policies cannot overlap.
    So if you have an inside host 192.168.1.2 then it cannot be included
    in both

    nat (inside) 1 192.168.1.2 and
    nat (inside) 2 192.168.1.2

    in order to provide the policies 1 and 2 for the global (outside) 1
    and 2 statements.

    Another way of putting this is that each inside host must normally
    be mapped to an outside address in only one way. The PIX 501 does not
    have multiple outside interfaces, so you cannot be directly connecting
    both ISPs to it simultaneously, and there's no good way for you say
    "use this external IP if it came from one ISP, but use this other
    external IP if it came from the other ISP."


    There -are- ways to do it that are fully supported, but you need
    to understand the PIX fairly well to configure them correctly.

    If the mail server that will be in DNS transition is outside of your
    network, then you can configure your PIX so that if someone attempts
    to go to the old address, they will get redirected to the new address
    anyhow. This usualy works at the IP level, so be careful if the mail host
    also has http services you need to get to!

    The mechanism you would use for this would be either the nearly-
    dead 'alias' command [not supported by PDM], or the newer "reverse nat"
    facilities (6.2 or later). If AAA is the old IP that your inside hosts
    might try to access, and you want it redirected to the external address
    BBB instead, then you can configure

    static (outside, inside) AAA BBB netmask 255.255.255.255

    Notice that the order of the interfaces has been reversed from the
    normal 'static' command!

    Unfortunately, the above has the side-effect that if people send
    directly to BBB then the reply that returns to them will be re-written
    to appear to be from AAA. It is possible that would cause problems
    with the adaptive security algorithm -- it might refuse those
    return packets that were really addressed to BBB.


    If the mail server that will be in DNS transition is inside of your
    network, then you can configure your PIX so that if someone attempts
    to go to the old address, the -source- IP will be rewritten to one of
    a known set of source IPs, which will then be detected for the
    reply packets and the reply destinations will be re-written to the
    original sources. This mechanism always you to distinguish between
    the same internal destination as named from different outside IP addresses
    [e.g., reached from different ISPs] and to return the packet to the
    correct address... provided that the next hop along can figure out which
    is which. Which it usually won't be able to do in your configuration.
    To run this configuration properly, you either need multiple outside
    interfaces (not possible on the 501), or you need the kind of nat'ing
    I'm talking about to happen downstream at the router at the junction
    of where both ISPs merge into a common data stream to connect to the 501.

    The PIX technique involved is reverse nat again, but done with
    global (inside) and nat (outside) rather than the usual global (outside)
    and nat (inside). If you have 6.3(2) or later, you might also get
    policy nat involved to handle everything properly -- you might need
    to put an access list on to the nat statement in order to constrain
    what it is working for. The good point about going with the access list
    is that you can specify port numbers in that access list, so you can
    have different mapping behaviour for different services.


    You definitely cannot, though, simply do

    static (inside, outside) OLDOUTSIDEIP MAILSERVERIP netmask 255.255.255.255
    static (inside, outside) NEWOUTSIDEIP MAILSERVERIP netmask 255.255.255.255

    The PIX must at all times, taking into account all the constraints
    that can be imposed by reverse nat and policy nat and nat exemption,
    for incoming connections have a unique mapping between any one
    outside source IP and any one destination inside IP. If you are working
    with multiple ISPs then your outside source IPs are going to be "any"
    for both ISPs (because anyone around the world might have followed
    either DNS entry and so might end up arriving via either ISP), so you
    have, in this simple but non-functional configuration just above,
    effectively tried to map "any" source to MAILSERVERIP destination
    and "any" source to the same MAILSERVERIP destination, violating the
    unique mapping constraints. If the PIX allowed you to put in the
    commands at all, when it came time to send out reply packets,
    it would not be able to figure out whether to use OLDOUTSIDEIP or
    NEWOUTSIDEIP as the source IP on the reply packets.


    Frankly, unless you are well experienced with the PIX and your
    outside nat-able routers, then if your transitional DNS records
    are ending up at the -same- inside destination on your 501, then
    I would recommend that you not even make the attempt to configure
    all the necessary magic. Find some other way. Just allow those
    people to not reach your system during the transition time, or put
    up a -second- mail server internally that relays to the first, or
    [if your OS supports it] configure your mail server to listen on
    multiple IPs. (Though I have to keep in mind that if you are
    talking about setting up multiple global's, then your mail server
    is likely outside rather than inside....)


    Will the old ISP already be turned off during the transitional
    period you are concerned about? Remember, some systems are likely
    to cache your old DNS entry for about a week (no matter what lifetimes
    you've been putting in your SOA records). If the old ISP will be turned
    off, then you are faced with the question of how the old IP is going
    to be routed to the new outside IP; if you do not have IP portability
    and the co-operation of both ISPs involved, it is not going to work
    at all... and even with their co-operation, they will probably mess
    up the hand-over unless you are an important corporate client entitled
    to speak right to the techs on both sides and able to negotiate
    particular transition times.
    --
    How does Usenet function without a fixed point?
    Walter Roberson, Sep 21, 2004
    #2
    1. Advertising

  3. BG

    PES Guest

    "BG" <> wrote in message
    news:UzW3d.8283$...
    > We're gonna change ISP and I thereby need to change the outside interface
    > on the Pix 501. In order to have the mail server working with the updated
    > DNS I need to run both the new and the old interface IPs for about 24 hrs.
    > I have seen configs like this:
    >
    > global (outside) 1 XXX.XXX.XXX.XXX
    > global (outside) 2 xxx.xxx.xxx.xxx
    >
    > and with NATing for both interfaces. Both does this really work? Is there
    > any way to have 2 adresses on the outside interface like I intend?
    >
    >
    > BG
    >
    >


    That's not going to work as you expect. The only way conceivably possible
    to do this it to use to address on your mail server and policy route based
    on the source address. In your example if you think of the source and
    destination addresses at different points and how the nat decision is made,
    I think you will see where I'm coming from. AFAIK the PIX can only do
    policy nat, not policy routing. You need to just get your dns mirrored to
    the proper destination server a few days in advance. Ask that they set the
    minimum ttl to a small value like 5 minutes. If this don't get your email
    availability to an acceptable level, you will have a bigger task then you
    realize.
    PES, Sep 21, 2004
    #3
  4. BG

    Seth Guest

    I think you guys are over thinking this. All you have to do is:

    1. put in another static on the pix for the mail exchange using the IP
    address that your new ISP will provide to you
    2. Add the nated IP on your mail server and configure it to listen for SMTP
    traffic
    3. After you ensure that you can connect to the new IP from outside of you
    network, change your mail exchange so that it uses the IP from your new ISP.
    4. After that is done, you want your outgoing connections to use your new
    ISP. The trick is to ensure that forward and revese DNS match. You can do
    this step at any time.
    5. Change your global so that it uses the IP of your new provider.

    If you do these steps correctly, you won't have any downtime.


    "BG" <> wrote in message
    news:UzW3d.8283$...
    > We're gonna change ISP and I thereby need to change the outside interface

    on
    > the Pix 501. In order to have the mail server working with the updated DNS

    I
    > need to run both the new and the old interface IPs for about 24 hrs. I

    have
    > seen configs like this:
    >
    > global (outside) 1 XXX.XXX.XXX.XXX
    > global (outside) 2 xxx.xxx.xxx.xxx
    >
    > and with NATing for both interfaces. Both does this really work? Is there
    > any way to have 2 adresses on the outside interface like I intend?
    >
    >
    > BG
    >
    >
    Seth, Sep 22, 2004
    #4
  5. In article <>,
    Seth <> wrote:
    :I think you guys are over thinking this. All you have to do is:

    :1. put in another static on the pix for the mail exchange using the IP
    :address that your new ISP will provide to you

    Ending at the same IP as before, or a different IP? I pointed out
    that you can't end at the same IP and port unless you proceed very
    carefully.

    :2. Add the nated IP on your mail server and configure it to listen for SMTP
    :traffic

    That would be the "different IP" option, and assumes that the mail
    server *can* listen to a second IP. This possibility is one I suggested
    instead of all the reverse or policy nat possibilities,
    marked with a "if the OS supports it" conditional.

    :3. After you ensure that you can connect to the new IP from outside of you
    :network, change your mail exchange so that it uses the IP from your new ISP.

    MX record changes take time to propogate. A number of systems take the
    DNS TTL as a hint; it isn't uncommon for a DNS change to live on
    somewhere for 1-2 weeks after it should have expired.

    :4. After that is done, you want your outgoing connections to use your new
    :ISP. The trick is to ensure that forward and revese DNS match. You can do
    :this step at any time.

    :5. Change your global so that it uses the IP of your new provider.

    Suppose you are starting from inside your PIX and attempting to connect
    to the OP's mail server. Suppose further that the DNS MX update hasn't
    reached your DNS cache yet. Then you connect to the old IP, but with
    your proposal, the reply would come from the new IP. The IPs would not
    match, so your PIX would not allow the reply through, and as far as
    your network is concerned, the remote MTA would be unavailable.

    Networks NOT protected by a SPI (Stateful Packet Inspection) firewall
    would not notice that the reply IP was different, and so smtp would get
    through fine for them.

    :If you do these steps correctly, you won't have any downtime.

    Unfortunately if you do the steps as you outline, you -will- have
    downtime until the MX changes reach all SPI firewalled sites that
    are allowed to send mail to you.

    When you are changing over IPs and DNS records, you have to think
    about "race conditions", with outside DNS caches introducing random and
    uncontrollable delays.
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
    Walter Roberson, Sep 22, 2004
    #5
  6. BG

    PES Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cis7c3$7kf$...
    > In article <>,
    > Seth <> wrote:
    > :I think you guys are over thinking this. All you have to do is:
    >
    > :1. put in another static on the pix for the mail exchange using the IP
    > :address that your new ISP will provide to you
    >
    > Ending at the same IP as before, or a different IP? I pointed out
    > that you can't end at the same IP and port unless you proceed very
    > carefully.
    >
    > :2. Add the nated IP on your mail server and configure it to listen for
    > SMTP
    > :traffic
    >
    > That would be the "different IP" option, and assumes that the mail
    > server *can* listen to a second IP. This possibility is one I suggested
    > instead of all the reverse or policy nat possibilities,
    > marked with a "if the OS supports it" conditional.
    >
    > :3. After you ensure that you can connect to the new IP from outside of
    > you
    > :network, change your mail exchange so that it uses the IP from your new
    > ISP.
    >
    > MX record changes take time to propogate. A number of systems take the
    > DNS TTL as a hint; it isn't uncommon for a DNS change to live on
    > somewhere for 1-2 weeks after it should have expired.
    >
    > :4. After that is done, you want your outgoing connections to use your new
    > :ISP. The trick is to ensure that forward and revese DNS match. You can do
    > :this step at any time.
    >
    > :5. Change your global so that it uses the IP of your new provider.
    >
    > Suppose you are starting from inside your PIX and attempting to connect
    > to the OP's mail server. Suppose further that the DNS MX update hasn't
    > reached your DNS cache yet. Then you connect to the old IP, but with
    > your proposal, the reply would come from the new IP. The IPs would not
    > match, so your PIX would not allow the reply through, and as far as
    > your network is concerned, the remote MTA would be unavailable.


    This was the point I was trying to make. However, I disagree with Walter on
    this. I think regardless of stateful packet inspection or not, the SMTP
    will be unreachable. Any ip stack that can do a three way handshake when
    the return packets have an invalid source address(and possibly source port
    if it hits a global and misses a static) is scary. Basically the
    converstation would look like this.

    A=unknown mailserver
    B=mail server behind pix
    C=src ip for return packets

    ip(a),tcp(dynamic | 25),ip(b),tcp(25),syn(1),ack(0)
    ip(c),tcp(25),ip(a),tcp(dynamic | 25),syn(1),ack(1)

    Then
    ip(a),tcp(dynamic | 25),ip(b),tcp(25),rst(1)

    Game over

    >
    > Networks NOT protected by a SPI (Stateful Packet Inspection) firewall
    > would not notice that the reply IP was different, and so smtp would get
    > through fine for them.
    >
    > :If you do these steps correctly, you won't have any downtime.
    >
    > Unfortunately if you do the steps as you outline, you -will- have
    > downtime until the MX changes reach all SPI firewalled sites that
    > are allowed to send mail to you.
    >
    > When you are changing over IPs and DNS records, you have to think
    > about "race conditions", with outside DNS caches introducing random and
    > uncontrollable delays.
    > --


    If you are concerned about 0 downtime on incoming email, go ahead and set
    your new ip address with a different a record. Configure an mx record to
    point to this a record. Any priority level will work, assuming the old ip
    will not be used immediately and the new ip is not yet in use.
    PES, Sep 23, 2004
    #6
    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.
Similar Threads
  1. Jeff
    Replies:
    2
    Views:
    3,640
  2. Andre
    Replies:
    7
    Views:
    687
    Andre
    Feb 20, 2005
  3. Michael Schuberl
    Replies:
    8
    Views:
    1,627
    Michael Schuberl
    May 8, 2006
  4. Hoffa
    Replies:
    0
    Views:
    671
    Hoffa
    Oct 25, 2006
  5. Hoffa
    Replies:
    1
    Views:
    1,415
    Walter Roberson
    Oct 25, 2006
Loading...

Share This Page