I have a Cisco Pix 501 firewall hooked up to my cable modem service which is
_supposed_ to be issuing me a static IP address. Most of the time this is
true, but occassionally (usually if the power goes out or whenever the 501
needs to reaquire the IP address) I get a different one.

The problem I have is I have set up some port forwarding rules (static
mappings) in the 501 and it seems to set the external interface with the IP
address (whatever it is at the moment). So when I do receive a new address,
I have to go in and update all the rules again.

I am not that experienced with the 501, but is that the way it is supposed
to work? Is there a way to bind a rule just to the external interface so I
don't have to worry about IP address changes.

For example, I set a rule to:

Route SSH (port 22) to my Linux box at 10.10.5.2.
My external IP at the time I create the rule 24.3.2.1 (example).
When I create the rule, it uses 24.3.2.1 in the rule.

My cable company suddenly changes it to 24.3.2.2 (example)
All my rules are invalidated and I can't shell into my box remotely.
I view the rule and it still is using 10.10.5.2 (correct) but 24.3.2.1
(incorrect)

Any ideas?

In article <XrKdnRLSk5Yr0HncRVn-tA@giganews.com>,
Tim Mavers <webview@hotmail.com> wrote:
:I have a Cisco Pix 501 firewall hooked up to my cable modem service which is
:_supposed_ to be issuing me a static IP address. Most of the time this is
:true, but occassionally (usually if the power goes out or whenever the 501
:needs to reaquire the IP address) I get a different one.

:The problem I have is I have set up some port forwarding rules (static
:mappings) in the 501 and it seems to set the external interface with the IP
:address (whatever it is at the moment). So when I do receive a new address,
:I have to go in and update all the rules again.

:I am not that experienced with the 501, but is that the way it is supposed
:to work? Is there a way to bind a rule just to the external interface so I
:don't have to worry about IP address changes.

Yes -- but it isn't foolproof. In particular, if you get assigned
a new IP address in the middle of a connection, then the connections
will necessarily go down (the remote end won't believe that the
packets are still from you). Mostly the connections will just time
out due to normal TCP timeout rules -- but if the remote process
is one that only allows one connection at a time to that destination
socket, and 'lingers' to pick up stray traffic, then it could be
several minutes before you can reconnect.

If you happen to have a set up a VPN connection then the
security associations will have to be renegotiated at the very least
(but the connections carried on the VPN might survive). Several
months back, someone indicated that that didn't work well with
PPTP. It also isn't the greatest if your PIX is identifying
itself to the remote end by IP address ('isakmp identity address')
which tends to happen more for VPN client software. If your PIX
is able to successfully convince it that you are still the same
entity, such as authentication by hostname, then the security
associations will be renegotiated fairly quickly even though
your endpoint IP changed.



:Route SSH (port 22) to my Linux box at 10.10.5.2.
:My external IP at the time I create the rule 24.3.2.1 (example).
:When I create the rule, it uses 24.3.2.1 in the rule.

You shouldn't do that -- it breaks some features in subtle ways.


:My cable company suddenly changes it to 24.3.2.2 (example)
:All my rules are invalidated and I can't shell into my box remotely.
:I view the rule and it still is using 10.10.5.2 (correct) but 24.3.2.1
incorrect)

static (inside,outside) tcp interface ssh 10.10.5.2 ssh

where the word 'interface' is a keyword in that context.

However, ssh is a bad example: ssh is one of the two ports
that you cannot do static port forwarding for (the other one
is the port used by PDM): the PIX always assumes the ssh port is
detined for the PIX itself if the IP address matches the interface
IP. It is valid, though, to do something like

static (inside,outside) tcp interface 2222 10.10.5.2 ssh

and then to connect to the ssh port on 10.10.5.2 you would
ask to ssh to port 2222 on the external interface IP of the PIX.
--
Would you buy a used bit from this man??

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:cs1qs4$c5p$1@canopus.cc.umanitoba.ca...
Could you elaborate a bit? What is breaking? It has been working pretty
well so far (for months).

I am using the keyword 'interface' and not specifing any IP address, however
when I view the rule afteward, it has injected the current IP address.

My IP address rarely changes, but unfortunately it does (I subscribe to
dyndns to alleviate some of that), however if I am away from home during an
IP address change, I am locked out of my system until I return home and
update all my rules the 501--which is a pain.

I used to have a Linksys firewall (the typical one you would find a Best
Buy) which worked fairly well, but I got tired of having to reset it for
unexplainable reasons. The PIX is the only that I know where the external
IP address is bound to the rule (or at least is affected where I have to
manually update it). I have also had DLink and Netgear equipment.

Do you mean this is why I can't bind it to the external interface? I have no
need to _ever_ be able to ssh into my box from a remote location (i.e.
outside of my private lan). I also bind 443 (HTTPS) to my box as I have ssh
also listening on that port (for companies that block 22--almost none block
443 and assume it is encrypted traffic anyway).

Thanks for your help,

In article <sPOdnaMGfNEy8HjcRVn-vA@giganews.com>,
Tim Mavers <webview@hotmail.com> wrote:
|"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
|news:cs1qs4$c5p$1@canopus.cc.umanitoba.ca...
|> In article <XrKdnRLSk5Yr0HncRVn-tA@giganews.com>,
|> Tim Mavers <webview@hotmail.com> wrote:
|> :Route SSH (port 22) to my Linux box at 10.10.5.2.
|> :My external IP at the time I create the rule 24.3.2.1 (example).
|> :When I create the rule, it uses 24.3.2.1 in the rule.

|> You shouldn't do that -- it breaks some features in subtle ways.

|Could you elaborate a bit? What is breaking? It has been working pretty
|well so far (for months).

I don't recall the details at the moment. The one I can think
of right now is that if you specify the external IP itself in
a 'global' command instead of the keyword 'interface' then the
PIX thinks the IP is a different entity than the interface and
can end up trying to allocate a port for PAT purposes that is already
in use by the PIX itself (e.g., being used to send out syslog
messages.) Also, sometimes incoming static's don't work properly:
the data just doesn't reach its destination.

:> static (inside,outside) tcp interface ssh 10.10.5.2 ssh

:> where the word 'interface' is a keyword in that context.

:I am using the keyword 'interface' and not specifing any IP address, however
:when I view the rule afteward, it has injected the current IP address.

Hmmm,
npix# config t
npix(config)# static (inside,outside) tcp interface ssh npinhead ssh netmask 2$
npix(config)# show static
static (inside,outside) tcp interface ssh npinhead ssh netmask 255.255.255.255 0 0

It keeps the 'interface' keyword every time I try.



:> However, ssh is a bad example: ssh is one of the two ports
:> that you cannot do static port forwarding for (the other one
:> is the port used by PDM): the PIX always assumes the ssh port is
:> detined for the PIX itself if the IP address matches the interface
:> IP.

That was bad advice. Ports 23 and 1467 are the reserved ports,
and it isn't clear whether you can static PAT those ports if you take the
trouble to come in over a VPN.
--
"The human genome is powerless in the face of chocolate."
-- Dr. Adam Drewnowski