Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Cisco (http://www.velocityreviews.com/forums/f27-cisco.html)
-   -   Temporary extra global ip on Pix 501 (http://www.velocityreviews.com/forums/t35471-temporary-extra-global-ip-on-pix-501-a.html)

BG 09-21-2004 02:06 PM

Temporary extra global ip on Pix 501
 
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



Walter Roberson 09-21-2004 03:59 PM

Re: Temporary extra global ip on Pix 501
 
In article <UzW3d.8283$WW4.128446@news4.e.nsc.no>,
BG <young_neils@hotmail.com> 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?

PES 09-21-2004 10:39 PM

Re: Temporary extra global ip on Pix 501
 

"BG" <young_neils@hotmail.com> wrote in message
news:UzW3d.8283$WW4.128446@news4.e.nsc.no...
> 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.



Seth 09-22-2004 12:15 AM

Re: Temporary extra global ip on Pix 501
 
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" <young_neils@hotmail.com> wrote in message
news:UzW3d.8283$WW4.128446@news4.e.nsc.no...
> 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
>
>




Walter Roberson 09-22-2004 03:56 PM

Re: Temporary extra global ip on Pix 501
 
In article <6oqdndX6z4pmWc3cRVn-oQ@comcast.com>,
Seth <google@iisadvisor.com> 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

PES 09-22-2004 11:50 PM

Re: Temporary extra global ip on Pix 501
 

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:cis7c3$7kf$1@canopus.cc.umanitoba.ca...
> In article <6oqdndX6z4pmWc3cRVn-oQ@comcast.com>,
> Seth <google@iisadvisor.com> 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.




All times are GMT. The time now is 12:44 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.