Pix firewall rules and IP address

Discussion in 'Cisco' started by Tim Mavers, Jan 11, 2005.

  1. Tim Mavers

    Tim Mavers Guest

    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?
    Tim Mavers, Jan 11, 2005
    #1
    1. Advertising

  2. In article <>,
    Tim Mavers <> 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, Jan 12, 2005
    #2
    1. Advertising

  3. Tim Mavers

    Tim Mavers Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cs1qs4$c5p$...
    > In article <>,
    > Tim Mavers <> 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).

    > 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.

    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.

    > 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.


    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,
    Tim Mavers, Jan 12, 2005
    #3
  4. In article <>,
    Tim Mavers <> wrote:
    |"Walter Roberson" <-cnrc.gc.ca> wrote in message
    |news:cs1qs4$c5p$...
    |> In article <>,
    |> Tim Mavers <> 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
    Walter Roberson, Jan 12, 2005
    #4
    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. Michael Kiessling

    PIX VPN Firewall-Rules

    Michael Kiessling, Dec 18, 2003, in forum: Cisco
    Replies:
    3
    Views:
    654
    Michael Kiessling
    Dec 19, 2003
  2. Diego B.

    Firewall rules to allow Cisco vpn

    Diego B., Dec 6, 2004, in forum: Cisco
    Replies:
    2
    Views:
    7,778
    mprasad079
    Dec 23, 2012
  3. KAS
    Replies:
    2
    Views:
    5,594
  4. Julian Dragut

    PIX Firewall MAC address VPN IP address

    Julian Dragut, Feb 7, 2006, in forum: Cisco
    Replies:
    1
    Views:
    789
    Walter Roberson
    Feb 7, 2006
  5. James
    Replies:
    2
    Views:
    751
    Chad Mahoney
    Jan 9, 2007
Loading...

Share This Page