Cisco PIX 501: Can't ping global IP-Adress from NATed IP

Discussion in 'Cisco' started by Michael Schuberl, May 4, 2006.

  1. Hi everyone,

    I am trying to set up a PIX501, IOS6.3.
    By reading various guides, I was able to build following config:

    OUTSiDE addresses are translated to iNSiDE (rfc191:cool:addresses (NAT only,
    no PAT). Thanks to statics, all desired services (e.g. a ntp server, ftp
    server) are reachable from the OUTSiDE.
    However, if I try to reach a service from the iNSiDE by it's OUTSiDE ip
    address, the connection times out.

    Can anybody give advise on how to reach the services by their OUTSiDE
    adress from the iNSiDE?
    Limitations:
    - There is no possibility to set up a DNS, also machines / services must
    comunicate via ip-adresses.

    Your help is greatly appreciated, thanks in advance!
     
    Michael Schuberl, May 4, 2006
    #1
    1. Advertising

  2. In article <op.s81ddkg27mx1hz@localhost>,
    Michael Schuberl <> wrote:
    >I am trying to set up a PIX501, IOS6.3.


    >OUTSiDE addresses are translated to iNSiDE (rfc191:cool:addresses (NAT only,
    >no PAT). Thanks to statics, all desired services (e.g. a ntp server, ftp
    >server) are reachable from the OUTSiDE.
    >However, if I try to reach a service from the iNSiDE by it's OUTSiDE ip
    >address, the connection times out.


    >Can anybody give advise on how to reach the services by their OUTSiDE
    >adress from the iNSiDE?


    You can't do it without extra hardware.

    >Limitations:
    >- There is no possibility to set up a DNS, also machines / services must
    >comunicate via ip-adresses.


    http://groups.google.ca/group/comp.dcom.sys.cisco/msg/717988dde941cbcd
    http://groups.google.ca/group/comp....read/thread/5f4606070854f8ba/b52d76576e914722
     
    Walter Roberson, May 4, 2006
    #2
    1. Advertising

  3. Thanks for your answer Walter Roberson,

    but how am I supposed to secure the following setup then?

    I've got a whole /28 subnet(let's assume x.x.x.0-x.x.x.15).
    The next hop and default route is x.x.x.1 and x.x.x.15 is the broadcast
    address for this net.

    My task is to put more nodes into that range than the remaining 13IPs
    would allow me to do. So I have to use some kind of NAT.
    Also, there are some servers which have to be accessable from other nets
    and from "my subnet".
    Finally, everythink should be secured by the PIX-firewall.

    I thought I should try it like most guides advised to:
    NATing (one-to-one translation) for the servers,
    one IP for NAT/PAT and the remaining IPs for NATing the clients.

    The clients and servers however should be able to communicate via the
    global ip (e.g. x.x.x.2) which doesn't work.

    How can I achieve that? Any solutions are welcome...





    Am 04.05.2006, 19:39 Uhr, schrieb Walter Roberson <>:

    > In article <op.s81ddkg27mx1hz@localhost>,
    > Michael Schuberl <> wrote:
    >> I am trying to set up a PIX501, IOS6.3.

    >
    >> OUTSiDE addresses are translated to iNSiDE (rfc191:cool:addresses (NAT
    >> only,
    >> no PAT). Thanks to statics, all desired services (e.g. a ntp server, ftp
    >> server) are reachable from the OUTSiDE.
    >> However, if I try to reach a service from the iNSiDE by it's OUTSiDE ip
    >> address, the connection times out.

    >
    >> Can anybody give advise on how to reach the services by their OUTSiDE
    >> adress from the iNSiDE?

    >
    > You can't do it without extra hardware.
    >
    >> Limitations:
    >> - There is no possibility to set up a DNS, also machines / services must
    >> comunicate via ip-adresses.

    >
    > http://groups.google.ca/group/comp.dcom.sys.cisco/msg/717988dde941cbcd
    > http://groups.google.ca/group/comp....read/thread/5f4606070854f8ba/b52d76576e914722
     
    Michael Schuberl, May 4, 2006
    #3
  4. In article <op.s81jmove7mx1hz@localhost>,
    Michael Schuberl <> wrote:
    >but how am I supposed to secure the following setup then?


    >My task is to put more nodes into that range than the remaining 13IPs
    >would allow me to do. So I have to use some kind of NAT.


    >The clients and servers however should be able to communicate via the
    >global ip (e.g. x.x.x.2) which doesn't work.


    >How can I achieve that?


    If that was your requirement, then you chose the wrong product.
    The PIX 501 cannot do that by itself, and possibly will never be able
    to do that... and I and others have mentioned that many times
    in this newsgroup.

    Any other model of PIX or ASA that is currently on sale would be able
    to handle the situation [presuming 6.3(2) or later software]
    (though the 506e would require the assistance of a vlan-aware switch.)


    You must either add hardware, change hardware, or give up the
    requirement that internal hosts must be able to access the servers
    by the external IP address instead of by the host name.


    You indicated that adding DNS to the mix was not an option. That
    significantly constrains your software-based solutions.

    It would help if you were to explain -why- DNS is not an option,
    and why internal clients must be able to access the servers via
    the public IP *address* rather than the hostname.
     
    Walter Roberson, May 4, 2006
    #4
  5. Am 04.05.2006, 23:53 Uhr, schrieb Walter Roberson <>:

    > In article <op.s81jmove7mx1hz@localhost>,
    > Michael Schuberl <> wrote:


    > If that was your requirement, then you chose the wrong product.
    > The PIX 501 cannot do that by itself, and possibly will never be able
    > to do that...

    I finally got that in writing ;)

    > and I and others have mentioned that many times
    > in this newsgroup.

    Sorry, I am rather new to this newsgroup. And it seems I didn't prepare
    well.


    > Any other model of PIX or ASA that is currently on sale would be able
    > to handle the situation [presuming 6.3(2) or later software]
    > (though the 506e would require the assistance of a vlan-aware switch.)


    > You must either add hardware, change hardware, or give up the
    > requirement that internal hosts must be able to access the servers
    > by the external IP address instead of by the host name.

    Ok, what hardware should be added in order to be able to acomplish the
    scenario?


    > You indicated that adding DNS to the mix was not an option. That
    > significantly constrains your software-based solutions.
    > It would help if you were to explain -why- DNS is not an option,
    > and why internal clients must be able to access the servers via
    > the public IP *address* rather than the hostname.

    Well there already is a DNS on that network, will that be sufficient?
    Will the PIX be able to translate the lookup-requests then and substitute
    the external for the internal adress? (that "alias"-thing, right?)
    To my mind, the DNS resolves the request to the external IP. Therefore,
    the client will again try to communicate with that address and the PIX
    would still not able to translate that IP to the internal IP.
    In my understanding, another DNS server at the PIX's inside could solve
    that issue. Am I right?

    The reason why I didn't want to set up an DNS is my lack of experience
    with such services and it seems that some costume software we use simply
    isn't using the gethostbyname() function and is therefor doomed to use IPs.
    Also the whole setup already did work without a firewall and fewer nodes
    (it comes down to just plugging in the nodes, setting the default gateway).
    My task is to put that PIX infront of the nodes. The first thing I learned
    back then was: it is not possible to force the PIX to behave in a
    transparent way (e.g. just filter and foreward the traffic for
    x.x.x.0-x.x.x.15 - without NAT), or did I configure something wrong?

    Thanks for your patience Walter Roberson!
    --
    Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
     
    Michael Schuberl, May 5, 2006
    #5
  6. In article <op.s82dvexp7mx1hz@localhost>,
    Michael Schuberl <> wrote:

    >Well there already is a DNS on that network, will that be sufficient?
    >Will the PIX be able to translate the lookup-requests then and substitute
    >the external for the internal adress? (that "alias"-thing, right?)
    >To my mind, the DNS resolves the request to the external IP. Therefore,
    >the client will again try to communicate with that address and the PIX
    >would still not able to translate that IP to the internal IP.


    Have the internal DNS server hand out the internal address, and
    on the 'static' statement for the server, add the 'dns' keyword. Then
    when -external- hosts do a query, the PIX will translate the
    internal IP to the external IP as the DNS response goes out of the
    network.

    >The reason why I didn't want to set up an DNS is my lack of experience
    >with such services and it seems that some costume software we use simply
    >isn't using the gethostbyname() function and is therefor doomed to use IPs.


    If the software can be configured to use the internal IPs for the
    servers, then configure the DNS and static as noted above and everything
    will be fine. [If the software is also used from outside your LAN,
    then configure the external hosts to use the public IP.]

    >My task is to put that PIX infront of the nodes. The first thing I learned
    >back then was: it is not possible to force the PIX to behave in a
    >transparent way (e.g. just filter and foreward the traffic for
    >x.x.x.0-x.x.x.15 - without NAT), or did I configure something wrong?


    The PIX 501 is fine with using the same address internally and externally.
    The catch is that the two interfaces cannot have the same IP subnet,
    so the external interface must be part of a different subnet and
    your WAN router must route the public range to to the IP address
    of the external interface. This is often done by arranging a
    "carrier network" with your ISP -- a distinct /30 or /29 network that is
    there just to allow your WAN equipment to talk to the ISP so
    that the ISP can route the main network to you.
     
    Walter Roberson, May 5, 2006
    #6
  7. Am 05.05.2006, 11:41 Uhr, schrieb Walter Roberson <>:
    > Have the internal DNS server hand out the internal address, and
    > on the 'static' statement for the server, add the 'dns' keyword. Then
    > when -external- hosts do a query, the PIX will translate the
    > internal IP to the external IP as the DNS response goes out of the
    > network.


    So there is no need for that alias-command?!

    > If the software can be configured to use the internal IPs for the
    > servers, then configure the DNS and static as noted above and everything
    > will be fine. [If the software is also used from outside your LAN,
    > then configure the external hosts to use the public IP.]

    Ok, thanks a lot for the advise, I will try to configure the DNS as
    supposed by you.
    Due to the fact that I've never done anything with DNS I've got the
    following (newbie?!) question:
    how to tell the outside clients to use my internal DNS-server to lookup
    the names, rather then the DNSserver located outside? Do I have to
    configure that outside server to foreward lookups for my subnet to my
    internal dns then?!


    > The PIX 501 is fine with using the same address internally and
    > externally.
    > The catch is that the two interfaces cannot have the same IP subnet,
    > so the external interface must be part of a different subnet and
    > your WAN router must route the public range to to the IP address
    > of the external interface. This is often done by arranging a
    > "carrier network" with your ISP -- a distinct /30 or /29 network that is
    > there just to allow your WAN equipment to talk to the ISP so
    > that the ISP can route the main network to you.


    Ok, I understood that. Leaves the question open why the PIX forces this
    behaviour. Maybe for security reasons...


    So far, thanks a lot for your answers and time, Walter Roberson!
     
    Michael Schuberl, May 6, 2006
    #7
  8. In article <op.s84lsmcg7mx1hz@localhost>,
    Michael Schuberl <> wrote:
    >Am 05.05.2006, 11:41 Uhr, schrieb Walter Roberson <>:
    >> Have the internal DNS server hand out the internal address, and
    >> on the 'static' statement for the server, add the 'dns' keyword. Then
    >> when -external- hosts do a query, the PIX will translate the
    >> internal IP to the external IP as the DNS response goes out of the
    >> network.


    >So there is no need for that alias-command?!


    The alias command is deprecated, and not supported by PDM, and
    is gone in 7.x.


    >> If the software can be configured to use the internal IPs for the
    >> servers, then configure the DNS and static as noted above and everything
    >> will be fine. [If the software is also used from outside your LAN,
    >> then configure the external hosts to use the public IP.]


    >Ok, thanks a lot for the advise, I will try to configure the DNS as
    >supposed by you.
    >Due to the fact that I've never done anything with DNS I've got the
    >following (newbie?!) question:
    >how to tell the outside clients to use my internal DNS-server to lookup
    >the names, rather then the DNSserver located outside? Do I have to
    >configure that outside server to foreward lookups for my subnet to my
    >internal dns then?!


    Configure the external DNS with the public IPs, and the internal
    DNS with the internal IPs, and point either kind of client to either.
    The 'dns' keyword on the 'static' command works both ways: if your
    internal users fetch a public IP from an external DNS server then it
    gets translated to the internal IP on its way in, and if your external
    users fetch a private IP from the internal DNS server then it gets
    translated to the external [public] IP on its way out.


    >> The PIX 501 is fine with using the same address internally and
    >> externally.
    >> The catch is that the two interfaces cannot have the same IP subnet,
    >> so the external interface must be part of a different subnet and
    >> your WAN router must route the public range to to the IP address
    >> of the external interface.


    >Ok, I understood that. Leaves the question open why the PIX forces this
    >behaviour. Maybe for security reasons...


    No, it's a simple matter of routing. PIX in general can have
    more than 2 interfaces. If your internal and external interfaces had
    the same IP subnet, then if a packet came from one of the DMZ interfaces
    then the PIX wouldn't know which interface to send it towards.

    Recall that your WAN router is going to have to be in the same subnet
    as your PIX outside interface IP, and your LAN router is going to have
    to be in the same subnet as your PIX inside interface IP, so if your
    inside and outside IP ranges were the same, packets from the DMZ could
    potentially have to go to the inside or outside for the same destination
    IP subnet. In order to manage that kind of situation, you would have
    to explicitly designate, IP by IP, which ones in the subnet were
    internal and which were external. It's theoretically possible, yes,
    and might be practical for a small number of IPs, but it is a situation
    that doesn't scale at all well. Now imagine if the way that the IPs
    were assigned was via an external DHCP server [since, after all,
    hypothetically everything is on the same subnet, you are going to
    expect to be able to DHCP into that subnet via an external server,
    right?] -- you can see how ugly the management of which IP is
    internal or external would become. Much easier to work based upon
    subnets: those scale reasonably well in most environments.


    People keep saying, "The PIX isn't a router!", but routing is
    crucial to the operation of the PIX [at least up through 6.x].
    Very nearly the first thing that the PIX does with a packet is to
    look up the routing information and extract the destination interface.
    Then it uses the source and destination interface information to check
    for an active translation (or to build a new translation), and it isn't
    until after that that it checks the ACLs.
     
    Walter Roberson, May 6, 2006
    #8
  9. Thank you so much!
    Today I searched for your name in this newsgroup.
    I was really astonished: you answered me even though the same questions
    have been asking all the time!
    I owe you one, since I got no further questions atm ;)

    Am 06.05.2006, 18:17 Uhr, schrieb Walter Roberson <>:

    > In article <op.s84lsmcg7mx1hz@localhost>,
    > Michael Schuberl <> wrote:
    >> Am 05.05.2006, 11:41 Uhr, schrieb Walter Roberson
    >> <>:
    >>> Have the internal DNS server hand out the internal address, and
    >>> on the 'static' statement for the server, add the 'dns' keyword. Then
    >>> when -external- hosts do a query, the PIX will translate the
    >>> internal IP to the external IP as the DNS response goes out of the
    >>> network.

    >
    >> So there is no need for that alias-command?!

    >
    > The alias command is deprecated, and not supported by PDM, and
    > is gone in 7.x.
    >
    >
    >>> If the software can be configured to use the internal IPs for the
    >>> servers, then configure the DNS and static as noted above and
    >>> everything
    >>> will be fine. [If the software is also used from outside your LAN,
    >>> then configure the external hosts to use the public IP.]

    >
    >> Ok, thanks a lot for the advise, I will try to configure the DNS as
    >> supposed by you.
    >> Due to the fact that I've never done anything with DNS I've got the
    >> following (newbie?!) question:
    >> how to tell the outside clients to use my internal DNS-server to lookup
    >> the names, rather then the DNSserver located outside? Do I have to
    >> configure that outside server to foreward lookups for my subnet to my
    >> internal dns then?!

    >
    > Configure the external DNS with the public IPs, and the internal
    > DNS with the internal IPs, and point either kind of client to either.
    > The 'dns' keyword on the 'static' command works both ways: if your
    > internal users fetch a public IP from an external DNS server then it
    > gets translated to the internal IP on its way in, and if your external
    > users fetch a private IP from the internal DNS server then it gets
    > translated to the external [public] IP on its way out.
    >
    >
    >>> The PIX 501 is fine with using the same address internally and
    >>> externally.
    >>> The catch is that the two interfaces cannot have the same IP subnet,
    >>> so the external interface must be part of a different subnet and
    >>> your WAN router must route the public range to to the IP address
    >>> of the external interface.

    >
    >> Ok, I understood that. Leaves the question open why the PIX forces this
    >> behaviour. Maybe for security reasons...

    >
    > No, it's a simple matter of routing. PIX in general can have
    > more than 2 interfaces. If your internal and external interfaces had
    > the same IP subnet, then if a packet came from one of the DMZ interfaces
    > then the PIX wouldn't know which interface to send it towards.

    Yes, I am with you. Seems resonable and I don't know why that did not get
    to my mind in the first place.
    *note to self: improve abstract thinking*


    > Recall that your WAN router is going to have to be in the same subnet
    > as your PIX outside interface IP, and your LAN router is going to have
    > to be in the same subnet as your PIX inside interface IP, so if your
    > inside and outside IP ranges were the same, packets from the DMZ could
    > potentially have to go to the inside or outside for the same destination
    > IP subnet. In order to manage that kind of situation, you would have
    > to explicitly designate, IP by IP, which ones in the subnet were
    > internal and which were external. It's theoretically possible, yes,
    > and might be practical for a small number of IPs, but it is a situation
    > that doesn't scale at all well. Now imagine if the way that the IPs
    > were assigned was via an external DHCP server [since, after all,
    > hypothetically everything is on the same subnet, you are going to
    > expect to be able to DHCP into that subnet via an external server,
    > right?] -- you can see how ugly the management of which IP is
    > internal or external would become. Much easier to work based upon
    > subnets: those scale reasonably well in most environments.
    >
    > People keep saying, "The PIX isn't a router!", but routing is
    > crucial to the operation of the PIX [at least up through 6.x].
    > Very nearly the first thing that the PIX does with a packet is to
    > look up the routing information and extract the destination interface.
    > Then it uses the source and destination interface information to check
    > for an active translation (or to build a new translation), and it isn't
    > until after that that it checks the ACLs.


    You're right, during my first search for guides to the PiX, I found
    several articles pretending that "the PiX isn't a router". But obviously
    it works on OSI-layer3 and therefor has what I would call "routing
    features"...

    Thanks for your help!



    --
    Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
     
    Michael Schuberl, May 8, 2006
    #9
    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. Bob Simon
    Replies:
    1
    Views:
    397
    Walter Roberson
    May 25, 2005
  2. Hoffa
    Replies:
    0
    Views:
    717
    Hoffa
    Oct 25, 2006
  3. Hoffa
    Replies:
    1
    Views:
    1,609
    Walter Roberson
    Oct 25, 2006
  4. 1388-2/HB
    Replies:
    2
    Views:
    433
    1388-2/HB
    Jul 13, 2007
  5. Tilman Schmidt

    PIX packets get NATed which shouldn't

    Tilman Schmidt, Aug 27, 2008, in forum: Cisco
    Replies:
    0
    Views:
    364
    Tilman Schmidt
    Aug 27, 2008
Loading...

Share This Page