PIX and STATIC command issues

Discussion in 'Cisco' started by DRice, Nov 20, 2003.

  1. DRice

    DRice Guest

    I have the following entries set up (PIX Version 6.1(4)):

    static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150 telnet
    netmask 255.255.255.255 0 0

    The first two ports (22,443) go to server 192.168.1.127, the third port (23)
    goes to server 192.168.1.150. The first two work correctly, but when I
    telnet (23) to xxx.xxx.xxx.xxx, the first server answers (192.168.1.127). I
    am confused. I basically copied this straight from the Cisco website
    example, substituting my IP addresses. Any ideas?

    Thanks in advance,
    Dan Rice
     
    DRice, Nov 20, 2003
    #1
    1. Advertising

  2. In article <k38vb.11421$>,
    DRice <> wrote:
    :I have the following entries set up (PIX Version 6.1(4)):

    :static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443 netmask 255.255.255.255 0 0
    :static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22 netmask 255.255.255.255 0 0
    :static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150 telnet netmask 255.255.255.255 0 0

    :The first two ports (22,443) go to server 192.168.1.127, the third port (23)
    :goes to server 192.168.1.150. The first two work correctly, but when I
    :telnet (23) to xxx.xxx.xxx.xxx, the first server answers (192.168.1.127).

    Those entries look correct at the moment, but I'm left wondering
    whether xxx.xxx.xxx.xxx happens to be the external IP address of the
    PIX? If it is, then you need to use the word 'interface' instead of
    the actual IP address.

    static (inside, outside) tcp interface 443 192.168.1.127 443 netmask 255.255.255.255 0 0

    and so on.
    --
    "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, Nov 20, 2003
    #2
    1. Advertising

  3. DRice

    DRice Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:bpj3fg$1od$...
    > In article <k38vb.11421$>,
    > DRice <> wrote:
    > :I have the following entries set up (PIX Version 6.1(4)):
    >
    > :static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443 netmask

    255.255.255.255 0 0
    > :static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22 netmask

    255.255.255.255 0 0
    > :static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150 telnet

    netmask 255.255.255.255 0 0
    >
    > :The first two ports (22,443) go to server 192.168.1.127, the third port

    (23)
    > :goes to server 192.168.1.150. The first two work correctly, but when I
    > :telnet (23) to xxx.xxx.xxx.xxx, the first server answers (192.168.1.127).
    >
    > Those entries look correct at the moment, but I'm left wondering
    > whether xxx.xxx.xxx.xxx happens to be the external IP address of the
    > PIX? If it is, then you need to use the word 'interface' instead of
    > the actual IP address.
    >
    > static (inside, outside) tcp interface 443 192.168.1.127 443 netmask

    255.255.255.255 0 0
    >
    > and so on.
    > --
    > "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.


    No, it is one of the IP's in our range, not the actual PIX interface IP.
    Our address range is xxx.yyy.zzz.32 255.255.255.240. 33 is our router, 34,
    is the PIX, 35 is used for internal access, and 36 is used for PAT. Which
    has led me to another issue. I tried using a static xxx.yyy.zzz.37
    192.168.1.150 and created an acl to allow tcp myipaddress any and it won't
    even respond. Something is amiss.

    Dan
     
    DRice, Nov 20, 2003
    #3
  4. DRice

    Rik Bain Guest

    On Thu, 20 Nov 2003 13:17:33 -0600, DRice wrote:

    > "Walter Roberson" <-cnrc.gc.ca> wrote in message
    > news:bpj3fg$1od$...
    >> In article <k38vb.11421$>, DRice
    >> <> wrote: :I have the following entries set up
    >> (PIX Version 6.1(4)):
    >>
    >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443
    >> netmask

    > 255.255.255.255 0 0
    >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22
    >> netmask

    > 255.255.255.255 0 0
    >> :static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150
    >> telnet

    > netmask 255.255.255.255 0 0
    >>
    >> :The first two ports (22,443) go to server 192.168.1.127, the third
    >> port

    > (23)
    >> :goes to server 192.168.1.150. The first two work correctly, but when
    >> I :telnet (23) to xxx.xxx.xxx.xxx, the first server answers
    >> (192.168.1.127).
    >>
    >> Those entries look correct at the moment, but I'm left wondering
    >> whether xxx.xxx.xxx.xxx happens to be the external IP address of the
    >> PIX? If it is, then you need to use the word 'interface' instead of the
    >> actual IP address.
    >>
    >> static (inside, outside) tcp interface 443 192.168.1.127 443 netmask

    > 255.255.255.255 0 0
    >>
    >> and so on.
    >> --
    >> "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.

    >
    > No, it is one of the IP's in our range, not the actual PIX interface IP.
    > Our address range is xxx.yyy.zzz.32 255.255.255.240. 33 is our router,
    > 34, is the PIX, 35 is used for internal access, and 36 is used for PAT.
    > Which has led me to another issue. I tried using a static
    > xxx.yyy.zzz.37 192.168.1.150 and created an acl to allow tcp myipaddress
    > any and it won't even respond. Something is amiss.
    >
    > Dan


    Dan,

    Are the hosts being statically pat'ed included in a nat/global policy
    that does not include the global pat addresses?

    If so you may want to have a look at CSCdy56503 -

    Basically you need to "add in PAT rules for the
    inside host to use the same global address as the static PAT statement."

    The 6.3 documentation has been modified to include this information.

    rik Bain
     
    Rik Bain, Nov 20, 2003
    #4
  5. DRice

    DRice Guest

    "Rik Bain" <> wrote in message
    news:p...
    > On Thu, 20 Nov 2003 13:17:33 -0600, DRice wrote:
    >
    > > "Walter Roberson" <-cnrc.gc.ca> wrote in message
    > > news:bpj3fg$1od$...
    > >> In article <k38vb.11421$>, DRice
    > >> <> wrote: :I have the following entries set up
    > >> (PIX Version 6.1(4)):
    > >>
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443
    > >> netmask

    > > 255.255.255.255 0 0
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22
    > >> netmask

    > > 255.255.255.255 0 0
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150
    > >> telnet

    > > netmask 255.255.255.255 0 0
    > >>
    > >> :The first two ports (22,443) go to server 192.168.1.127, the third
    > >> port

    > > (23)
    > >> :goes to server 192.168.1.150. The first two work correctly, but when
    > >> I :telnet (23) to xxx.xxx.xxx.xxx, the first server answers
    > >> (192.168.1.127).
    > >>
    > >> Those entries look correct at the moment, but I'm left wondering
    > >> whether xxx.xxx.xxx.xxx happens to be the external IP address of the
    > >> PIX? If it is, then you need to use the word 'interface' instead of the
    > >> actual IP address.
    > >>
    > >> static (inside, outside) tcp interface 443 192.168.1.127 443 netmask

    > > 255.255.255.255 0 0
    > >>
    > >> and so on.
    > >> --
    > >> "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.

    > >
    > > No, it is one of the IP's in our range, not the actual PIX interface IP.
    > > Our address range is xxx.yyy.zzz.32 255.255.255.240. 33 is our router,
    > > 34, is the PIX, 35 is used for internal access, and 36 is used for PAT.
    > > Which has led me to another issue. I tried using a static
    > > xxx.yyy.zzz.37 192.168.1.150 and created an acl to allow tcp myipaddress
    > > any and it won't even respond. Something is amiss.
    > >
    > > Dan

    >
    > Dan,
    >
    > Are the hosts being statically pat'ed included in a nat/global policy
    > that does not include the global pat addresses?
    >
    > If so you may want to have a look at CSCdy56503 -
    >
    > Basically you need to "add in PAT rules for the
    > inside host to use the same global address as the static PAT statement."
    >
    > The 6.3 documentation has been modified to include this information.
    >
    > rik Bain


    Phew...that went straight over my head. But I have been staring at this
    stuff all day and now its all like a foreign language.

    DRice
     
    DRice, Nov 20, 2003
    #5
  6. DRice

    DRice Guest

    "Rik Bain" <> wrote in message
    news:p...
    > On Thu, 20 Nov 2003 13:17:33 -0600, DRice wrote:
    >
    > > "Walter Roberson" <-cnrc.gc.ca> wrote in message
    > > news:bpj3fg$1od$...
    > >> In article <k38vb.11421$>, DRice
    > >> <> wrote: :I have the following entries set up
    > >> (PIX Version 6.1(4)):
    > >>
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 443 192.168.1.127 443
    > >> netmask

    > > 255.255.255.255 0 0
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx 22 192.168.1.127 22
    > >> netmask

    > > 255.255.255.255 0 0
    > >> :static (inside,outside) tcp xxx.xxx.xxx.xxx telnet 192.168.1.150
    > >> telnet

    > > netmask 255.255.255.255 0 0
    > >>
    > >> :The first two ports (22,443) go to server 192.168.1.127, the third
    > >> port

    > > (23)
    > >> :goes to server 192.168.1.150. The first two work correctly, but when
    > >> I :telnet (23) to xxx.xxx.xxx.xxx, the first server answers
    > >> (192.168.1.127).
    > >>
    > >> Those entries look correct at the moment, but I'm left wondering
    > >> whether xxx.xxx.xxx.xxx happens to be the external IP address of the
    > >> PIX? If it is, then you need to use the word 'interface' instead of the
    > >> actual IP address.
    > >>
    > >> static (inside, outside) tcp interface 443 192.168.1.127 443 netmask

    > > 255.255.255.255 0 0
    > >>
    > >> and so on.
    > >> --
    > >> "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.

    > >
    > > No, it is one of the IP's in our range, not the actual PIX interface IP.
    > > Our address range is xxx.yyy.zzz.32 255.255.255.240. 33 is our router,
    > > 34, is the PIX, 35 is used for internal access, and 36 is used for PAT.
    > > Which has led me to another issue. I tried using a static
    > > xxx.yyy.zzz.37 192.168.1.150 and created an acl to allow tcp myipaddress
    > > any and it won't even respond. Something is amiss.
    > >
    > > Dan

    >
    > Dan,
    >
    > Are the hosts being statically pat'ed included in a nat/global policy
    > that does not include the global pat addresses?
    >
    > If so you may want to have a look at CSCdy56503 -
    >
    > Basically you need to "add in PAT rules for the
    > inside host to use the same global address as the static PAT statement."
    >
    > The 6.3 documentation has been modified to include this information.
    >
    > rik Bain


    Ok, I think I get what you are getting at (although I can't get CSCdy56503),
    but wouldn't it not work at all if this were the case? It routes the first
    two statics correctly to server1, but the third static gets routed to
    Server1 also, instead of the Server2 address like the command line says.
    It's basically ignoring the local IP entry. I wrote this exactly like the
    cisco webpage (
    http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml ) said to, yet it doesn't work correctly.

    DRice
     
    DRice, Nov 21, 2003
    #6
  7. DRice

    Rik Bain Guest

    On Thu, 20 Nov 2003 22:37:34 -0600, DRice wrote:



    >
    > Ok, I think I get what you are getting at (although I can't get
    > CSCdy56503), but wouldn't it not work at all if this were the case? It
    > routes the first two statics correctly to server1, but the third static
    > gets routed to Server1 also, instead of the Server2 address like the
    > command line says. It's basically ignoring the local IP entry. I wrote
    > this exactly like the cisco webpage (
    > http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml
    > ) said to, yet it doesn't work correctly.
    >
    > DRice



    Can you post the output of:

    show stat
    sh nat
    sh global

    you can change the ip addresses. . .
     
    Rik Bain, Nov 21, 2003
    #7
  8. DRice

    DRice Guest

    "Rik Bain" <> wrote in message
    >
    > Can you post the output of:
    >
    > show stat
    > sh nat
    > sh global
    >
    > you can change the ip addresses. . .


    Here is what I get.

    finifw# sh stat
    static (inside,outside) tcp xxx.yyy.zzz.35 22 192.168.1.127 22 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 443 192.168.1.127 443 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 telnet 192.168.1.150 telnet
    netmask 255.255.255.255 0 0
    finifw# sh nat
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    finifw# sh global
    global (outside) 1 xxx.yyy.zzz.36

    Again, all ports get directed to 192.168.1.127, regardless of what the
    static line says.

    DRice
     
    DRice, Nov 22, 2003
    #8
  9. DRice

    Rik Bain Guest

    On Fri, 21 Nov 2003 18:33:37 -0600, DRice wrote:

    > "Rik Bain" <> wrote in message
    >>
    >> Can you post the output of:
    >>
    >> show stat
    >> sh nat
    >> sh global
    >>
    >> you can change the ip addresses. . .

    >
    > Here is what I get.
    >
    > finifw# sh stat
    > static (inside,outside) tcp xxx.yyy.zzz.35 22 192.168.1.127 22 netmask
    > 255.255.255.255 0 0
    > static (inside,outside) tcp xxx.yyy.zzz.35 443 192.168.1.127 443 netmask
    > 255.255.255.255 0 0
    > static (inside,outside) tcp xxx.yyy.zzz.35 telnet 192.168.1.150 telnet
    > netmask 255.255.255.255 0 0
    > finifw# sh nat
    > nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    > finifw# sh global
    > global (outside) 1 xxx.yyy.zzz.36
    >
    > Again, all ports get directed to 192.168.1.127, regardless of what the
    > static line says.
    >
    > DRice


    OK, so 192.168.1.127 is included in nat/global policy 1, which translates
    to .36, but your statics translate it to .35 (for certain ports).

    From the command reference:

    "If you have a separate translation for all inside traffic that uses a
    different global address, you can still configure the Telnet server
    to use the same address as the static statement by creating a more
    exclusive nat statement just for that server. Because nat statements
    are read for the best match, more exclusive nat statements are matched
    before general statements.

    static (inside,outside) tcp 10.1.2.14 telnet 10.1.1.15 telnet netmask 255.255.255.255
    nat (inside) 1 10.1.1.15 255.255.255.255
    global (outside) 1 10.1.2.14 netmask 255.255.255.255
    nat (inside) 2 0.0.0.0 0.0.0.0
    global (outside) 2 10.1.2.78 netmask 255.255.255.255"

    What that means?

    You have:
    static (inside,outside) tcp xxx.yyy.zzz.35 22 192.168.1.127 22 netmask 255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 443 192.168.1.127 443 netmask 255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 telnet 192.168.1.150 telnet netmask 255.255.255.255 0 0
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    global (outside) 1 xxx.yyy.zzz.36

    Now add:
    nat (inside) 10 192.168.1.127 255.255.255.255
    nat (inside) 10 192.168.1.150 255.255.255.255
    global (outside) 10 xxx.yyy.zzz.35 netmask 255.255.255.255

    This is basically what the bug id i posted earlier states.


    HTH,

    Rik Bain
     
    Rik Bain, Nov 22, 2003
    #9
  10. In article <LLBvb.15947$>,
    DRice <> wrote:
    :Unfortunately, I do not have (or know how to get) the 'bug id's'. They must
    :be at a deeper level on the Cisco website than I can gain access too.
    :Either that, or I am stupid. Either way, thank you very much for clearing
    :that up for me.

    If you put the bug number Rik quoted into the www.cisco.com search
    window, then the results page will recommend using the bug toolkit.
    Click on that, and it will ask for your CCO username and password.
    Enter those in and the bug toolkit will open and display the
    description of the bug.
    --
    Warhol's Second Law of Usenet: "In the future, everyone will troll
    for 15 minutes."
     
    Walter Roberson, Nov 22, 2003
    #10
  11. DRice

    Rik Bain Guest

    On Fri, 21 Nov 2003 22:39:07 -0600, DRice wrote:
    ain
    >
    > Ok, now that I have it in front of me, it makes all the sense in the
    > world. Unfortunately, I do not have (or know how to get) the 'bug id's'.
    > They must be at a deeper level on the Cisco website than I can gain
    > access too. Either that, or I am stupid. Either way, thank you very
    > much for clearing that up for me.
    >
    > DRice


    No worries, that's why we have comp.dcom.sys.cisco . . .
     
    Rik Bain, Nov 23, 2003
    #11
  12. DRice

    DRice Guest

    "Rik Bain" <> wrote in message
    news:p...
    > On Fri, 21 Nov 2003 22:39:07 -0600, DRice wrote:
    > ain
    > >
    > > Ok, now that I have it in front of me, it makes all the sense in the
    > > world. Unfortunately, I do not have (or know how to get) the 'bug id's'.
    > > They must be at a deeper level on the Cisco website than I can gain
    > > access too. Either that, or I am stupid. Either way, thank you very
    > > much for clearing that up for me.
    > >
    > > DRice

    >
    > No worries, that's why we have comp.dcom.sys.cisco . . .


    Well, I completed the following...

    finifw# sh stat
    static (inside,outside) tcp xxx.yyy.zzz.35 22 192.168.1.127 22 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 443 192.168.1.127 443 netmask
    255.255.255.255 0 0
    static (inside,outside) tcp xxx.yyy.zzz.35 telnet 192.168.1.150 telnet
    netmask 255.255.255.255 0 0
    finifw# sh nat
    nat (inside) 10 192.168.1.127 255.255.255.255 0 0
    nat (inside) 10 192.168.1.150 255.255.255.255 0 0
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    finifw# sh global
    global (outside) 1 xxx.yyy.zzz.36
    global (outside) 10 xxx.yyy.zzz.35 netmask 255.255.255.255

    ....and guess what? Server at .127 still answers telnet, not .150. Should I
    throw the PIX at the wall and see if that fixes it?

    DRice
     
    DRice, Nov 24, 2003
    #12
  13. DRice

    DRice Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:bpmsl8$p16$...
    > In article <LLBvb.15947$>,
    > DRice <> wrote:
    > :Unfortunately, I do not have (or know how to get) the 'bug id's'. They

    must
    > :be at a deeper level on the Cisco website than I can gain access too.
    > :Either that, or I am stupid. Either way, thank you very much for

    clearing
    > :that up for me.
    >
    > If you put the bug number Rik quoted into the www.cisco.com search
    > window, then the results page will recommend using the bug toolkit.
    > Click on that, and it will ask for your CCO username and password.
    > Enter those in and the bug toolkit will open and display the
    > description of the bug.
    > --
    > Warhol's Second Law of Usenet: "In the future, everyone will troll
    > for 15 minutes."


    Yea, I got that far only to get "The file or application you are trying to
    access may require additional entitlement or you are trying to access a file
    with an invalid name. Additional entitlement levels are granted based on a
    users relationship with Cisco on a per-application basis."

    So, basically, Cisco doesn't want to help me. I'm 'entitled' to buy their
    products, just not to get them to work. Heh heh.

    DRice
     
    DRice, Nov 24, 2003
    #13
  14. In article <bDrwb.46113$>,
    DRice <> wrote:
    :Yea, I got that far only to get "The file or application you are trying to
    :access may require additional entitlement or you are trying to access a file
    :with an invalid name. Additional entitlement levels are granted based on a
    :users relationship with Cisco on a per-application basis."

    Sounds like you do not have a SmartNet contract.
    --
    Are we *there* yet??
     
    Walter Roberson, Nov 24, 2003
    #14
  15. DRice

    Rik Bain Guest

    On Mon, 24 Nov 2003 11:42:56 -0600, DRice wrote:

    > "Rik Bain" <> wrote in message
    > news:p...
    >> On Fri, 21 Nov 2003 22:39:07 -0600, DRice wrote: ain
    >> >
    >> > Ok, now that I have it in front of me, it makes all the sense in the
    >> > world. Unfortunately, I do not have (or know how to get) the 'bug
    >> > id's'.
    >> > They must be at a deeper level on the Cisco website than I can gain
    >> > access too. Either that, or I am stupid. Either way, thank you very
    >> > much for clearing that up for me.
    >> >
    >> > DRice

    >>
    >> No worries, that's why we have comp.dcom.sys.cisco . . .

    >
    > Well, I completed the following...
    >
    > finifw# sh stat
    > static (inside,outside) tcp xxx.yyy.zzz.35 22 192.168.1.127 22 netmask
    > 255.255.255.255 0 0
    > static (inside,outside) tcp xxx.yyy.zzz.35 443 192.168.1.127 443 netmask
    > 255.255.255.255 0 0
    > static (inside,outside) tcp xxx.yyy.zzz.35 telnet 192.168.1.150 telnet
    > netmask 255.255.255.255 0 0
    > finifw# sh nat
    > nat (inside) 10 192.168.1.127 255.255.255.255 0 0 nat (inside) 10
    > 192.168.1.150 255.255.255.255 0 0 nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    > finifw# sh global
    > global (outside) 1 xxx.yyy.zzz.36
    > global (outside) 10 xxx.yyy.zzz.35 netmask 255.255.255.255
    >
    > ...and guess what? Server at .127 still answers telnet, not .150.
    > Should I throw the PIX at the wall and see if that fixes it?
    >
    > DRice


    Config looks good. Did you "clear xlate" after the changes? If you
    enable logging, so you see the translation being built?
     
    Rik Bain, Nov 24, 2003
    #15
  16. DRice

    DRice Guest

    "Rik Bain" <> wrote in message
    news:p...
    > Config looks good. Did you "clear xlate" after the changes? If you
    > enable logging, so you see the translation being built?


    Bah. I did a clear xlate, and now its forwarding properly. Thanks again.
    I am going to leave it alone now. Heh heh.

    DRice
     
    DRice, Nov 24, 2003
    #16
    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. Hyeon Cheol

    Static command on cisco PIX Firewall

    Hyeon Cheol, Aug 18, 2004, in forum: Cisco
    Replies:
    1
    Views:
    5,931
    Russell Lusignan
    Aug 19, 2004
  2. Nieuws Xs4all
    Replies:
    0
    Views:
    655
    Nieuws Xs4all
    May 26, 2005
  3. Nieuws Xs4all
    Replies:
    2
    Views:
    1,661
    Jan-Willem
    May 26, 2005
  4. Replies:
    0
    Views:
    2,454
  5. zillah
    Replies:
    0
    Views:
    2,162
    zillah
    Dec 27, 2006
Loading...

Share This Page