PIX: access port mapped IP using external address

Discussion in 'Cisco' started by peter breugle, May 6, 2004.

  1. I have a single DHCP external interface. static map port map from
    external address to internal machine:

    This gives internal host a name, maps port 8080 to the internal host
    This works:

    name 192.168.2.10 bobby
    access-list outside_access_in permit tcp any any eq 8080
    static (inside,outside) tcp interface 8080 bobby www netmask
    255.255.255.255 0 0

    when an external user goes to the outside interface on 8080 they got
    routed to host "bobby". Bobby is listening to http on the www:80 port.
    So far so good.


    I want my internal users to be able to access "bobby" using the external
    IP:port

    e.g..

    Lets say my external address is 207.237.23.12
    Outside users can access bobby as http://207.237.23.12:8080

    the static statement maps the port:ip combo to bobby. The access-list
    permit allows 8080 traffic through.

    I want to be able to access Bobby (192.168.2.10) from inside using the
    same IP:port for development. It actually should have to go through the
    same access-list filters that outside users must pass through.

    The external map works. A $40 linksys router does this by default. (OK -
    lets be fair, no ACL) How can I do this on a PIX?

    I actually port map several machines so a single alias statement won't
    fly (I don't think that is what it is for anyway - right?).

    So far as I know, you can't associate a port with an Alias statement.

    Why can't I specify that traffic going to the IP of my outside interface
    goes back in just as real outside traffic? In effect a loop-back. I
    think a global statement will do this, but I can't figure out the exact
    syntax.

    - p -
     
    peter breugle, May 6, 2004
    #1
    1. Advertisements

  2. peter breugle

    òTTó Guest

    Hi Peter,

    Try this one

    alias (inside) 192.168.2.10 207.237.23.12 255.255.255.255

    regards oTTo
     
    òTTó, May 6, 2004
    #2
    1. Advertisements

  3. peter breugle

    mh Guest

    PIX will not allow a packet back thru the same interface it entered on.

    If you have a 3 port PIX create a dmz and move your server to the dmz.
     
    mh, May 6, 2004
    #3
  4. I tried the alias. I cleared Xlat etc, but no joy..

    I've searched around and seen a few other people who to do this using
    alias. Nobody seemed to get that to work. Part of the problem is that I
    am port forwarding on the external interface to a specific machine and I
    want to be able to use the same url e.g.. xx.xx.xx:8080 from the inside.
    If I understand Alias correctly, it will just rewrite the IP, but I need
    to also go through the port mapping as well.

    - p -
     
    peter breugle, May 6, 2004
    #4
  5. Sigh... Not what I wanted to hear.. I can't use a DMZ for this.

    I have a 501. Can I do this with a single route or create another
    external interface on the 501 so that I route - maybe with addition of
    alias - inside/outside2/outside(capture port map)/inside?
     
    peter breugle, May 6, 2004
    #5
  6. peter breugle

    mh Guest

    I don't believe so ...


    You might want to consider getting another 501 and another "low" speed
    Internet connection. Your developers could then change their PC's
    default route ( use route add in command mode) to point to the 2nd PIX
    when they wanted to do testing using the outside IP address of the
    server in question.
     
    mh, May 7, 2004
    #6
  7. :I've searched around and seen a few other people who to do this using
    :alias. Nobody seemed to get that to work. Part of the problem is that I
    :am port forwarding on the external interface to a specific machine and I
    :want to be able to use the same url e.g.. xx.xx.xx:8080 from the inside.
    :If I understand Alias correctly, it will just rewrite the IP, but I need
    : to also go through the port mapping as well.

    If it were just the url and not the port number that was involved,
    the solution would be a change to how dns was handled, so that the
    hostname resolved to the external IP for external users, and to the
    internal IP for internal users. 'alias' is the old-style way of handling
    that if the DNS is external; a new flag on the 'static' command is
    the new-style way of handling it if the DNS is external. If the DNS
    is internal, you would use a "split DNS" configuration on the DNS
    server itself.

    But that would only get you the IP level. The PIX has no way of
    handling the port mapping except when traffic goes -through- the PIX
    from one interface to another. The PIX will not (at least up to 6.3(3),
    might change in 7.0) loop-back to the same interface under any
    circumstances. Furthermore, if you were to just put an outside router
    in and reflect the packets to the PIX, it would detect the packet
    as not being "new" and would refuse it. In order for the PIX to believe
    that it is a new packet, the packet must get re-written by the outside
    layer -- such as if your outside router not only reflected the packet
    but also NAT'd it.

    If you had a PIX 515 or higher model, and a VLAN-aware switch inside,
    you could work with logical interfaces. The PIX 501, 506, 506E and 510
    do not support logical interfaces.


    Do you already have a router able to do NAT on loopback ports? If not,
    then there are some tricks you can pull by using a second PIX 501
    in conjunction with the existing PIX 501. I'd have to think more about
    the easiest way to impliment that. "Second PIX 501" only in the sense
    that PIX 501's are not so expensive, can do the NAT, have the switch
    port (i.e., multiple connections), and you already know how to configure
    the device; you might plausibly be able to find a $50-$100
    "cable/DSL gateway router" to fill the same function.
     
    Walter Roberson, May 7, 2004
    #7
  8. well Yes I kind of do have a router capable of doing Nat'ing. I have my
    linksys BEF41 router that I was retiring. I guess I could use that for
    loop back as a blind intermediary. Is that what you are suggesting?

    - p -
     
    peter breugle, May 7, 2004
    #8
  9. :well Yes I kind of do have a router capable of doing Nat'ing. I have my
    :linksys BEF41 router that I was retiring. I guess I could use that for
    :loop back as a blind intermediary. Is that what you are suggesting?

    Yup. It might result in an inefficient connection, but as long as
    you have enough external switch or bridged router ports, you can
    probably get it to work. It might help to add a 'route' statement
    for that external IP pointing to the BEF41 with the default route
    still going directly to the router.

    The PIX will accept the packet if the source IP has been re-written
    before the packet gets back to the outside interface.
     
    Walter Roberson, May 7, 2004
    #9
  10. Is this what you are suggesting? Just want to make sure that I have a
    handle on this. All I really want to do is allow my internal users to
    talk to my Pix on the external address on an equal footing as external
    users.

    So using a second el-cheapo router:

    1 - outside -> Pix
    2 - Static outside portmap -> inside
    this gives outside users access to my internal machine.

    Now the game
    3 - Put BEF41 on inside. Assign it a new subnet.
    4 - Configure the BEF to route ALL TRAFFIC to external address
    5 - On Pix set route for external address to go to Linksys
    6 Internal traffic to the outside IP will go through the static mapping
    defined for portmap in (2)


    The linksys will re-nat the address so the Pix won't recognize the
    source as inside. Is that the idea?

    If that is what you are suggesting (and its not like I don't have the
    BEF sitting in a box) why couldn't I define a second (internal or
    external) interface, NAT that as well, route or even just alias the
    internal on the specific IP for external to the second and then route
    second back to the default outside. The Pix would not see the same xlat
    on the external coming from inside because the packet went through two
    hops - or do I REALLY NOT GET IT? (which is likely)

    Sorry - I am a programmer, but a network nit-wit and trying to make
    sense of how the Pix is thinking about this. Please don't flame me.

    - p -
     
    peter breugle, May 8, 2004
    #10
  11. :Is this what you are suggesting?

    "Suggesting" is too strong a term. It's a hack. It should work.
    But I don't endorse implimenting it. If someone were to ask how to
    scoop up dog dirt with a PIX 501, I'd probably answer that too.


    :All I really want to do is allow my internal users to
    :talk to my Pix on the external address on an equal footing as external
    :users.

    You can't do that with a PIX 501. The closest you can come with a PIX 501
    is to allow your internal users noticably *slower* access to your
    internal addresses. [Note for those who haven't been following the details:
    he needs port translation, not just address translation, so DNS changes
    aren't enough for him.]


    :So using a second el-cheapo router:

    :1 - outside -> Pix
    :2 - Static outside portmap -> inside
    :this gives outside users access to my internal machine.

    :Now the game
    :3 - Put BEF41 on inside. Assign it a new subnet.

    No, the BEF41 would have to go on the *outside* for the scheme to work.
    You have to have the data pass *through* the PIX from one interface
    to another. If your BEF41 is on the inside then your internal packets
    would be trying to go from the inside to the PIX to the inside,
    which is precisely what will not work in any released version of PIX.


    :If that is what you are suggesting (and its not like I don't have the
    :BEF sitting in a box) why couldn't I define a second (internal or
    :external) interface, NAT that as well, route or even just alias the
    :internal on the specific IP for external to the second and then route
    :second back to the default outside.

    Define a second interface on what? On the PIX 501, you can't define
    additional interfaces: there is only inside and outside and any
    data that isn't going through from one interface to the other is
    dropped.


    :Sorry - I am a programmer, but a network nit-wit and trying to make
    :sense of how the Pix is thinking about this. Please don't flame me.


    The algorithm is something like the below, if you find reading
    code easier to understand than our text saying that The PIX
    Just Won't Do That.


    /* initialize */
    source_port = 0;
    destination_port = 0;

    /* check packet */
    packet_protocol = find_protocol( packet );
    source_IP = find_source_IP( packet );
    destination_IP = find_destination_IP( packet );

    if ( have_connection_entries( packet_protocol, source_IP, destination_IP ) ) {
    if ( packet_protocol == TCP || packet_protocol == UDP ) {
    source_port = find_source_port( packet );
    destination_port = find_destination_port( packet );
    connection_entry =
    find_connection_entry( packet_protocol, source_IP, destination_IP,
    source_port, destination_port );
    if ( connection_entry != NULL && packet_protocol == TCP ) {
    tcp_sequence = find_tcp_sequence_number( packet );
    if ( connection_entry->source_tcp_sequence == tcp_sequence ) {
    drop_packet(); /* it's a duplicate */
    }
    }
    }
    new_connection = FALSE;
    } else {
    new_connection = TRUE;
    }

    destination_interface = routing_lookup( destination_IP );
    source_security_level = security_level_lookup( source_interface );
    destination_security_level = security_level_lookup( destination_interface );

    if ( source_security_level == destination_security_level ) {
    drop_packet();
    }

    /*
    no need to test if the source and destination interfaces are the
    same. If they were, then the two security_level_lookups would have
    returned the same result, so the packet would have been already dropped
    */

    if ( new_connection && source_packet_level < destination_packet_level ) {
    /*
    check for nat 0 access-list exemption or static, and drop the
    packet if one is not found.
    */
    ...
    }

    if ( new_connection &&
    fails_acl( source_interface, packet_protocol, source_IP, destination_IP,
    source_port, destination_port ) ) {
    drop_packet();
    }

    /*
    only now that routing is known and the translation entry checked
    and the acl has passed do we actually process any applicable NAT/PAT
    to find the mapped address. Before here, we just had to know it
    existed.
    */
    ,...
     
    Walter Roberson, May 8, 2004
    #11
  12. peter breugle

    mh Guest

    Would this work ???


    1. Place an Ethernet hub (MUST be a real hub - suggest NETGEAR DS-104)
    between the current PIX and upstream Internet access device.

    2. Place a 2nd PIX in "parallel" with the first PIX , connecting the
    inside interface of the 2nd PIX to the same LAN as the existing PIX
    and the outside interface to the new hub ( from step #1)

    3. Configure developers work station routing ( assuming Windows based)
    to add a route for "booby" to their routing table that points to the
    2nd PIX

    i.e. route add 207.237.23.12 mask 255.255.255.255 <IP for pix #2>
    metric 1



    Bake until done ...
     
    mh, May 8, 2004
    #12
  13. peter breugle

    mh Guest

    Would this work ???


    1. Place an Ethernet hub (MUST be a real hub - suggest NETGEAR DS-104)
    between the current PIX and the upstream Internet access device.

    2. Place a 2nd PIX in "parallel" with the first PIX , connecting the
    inside interface of the 2nd PIX to the same LAN as the existing PIX
    and the outside interface to the new hub ( from step #1)

    3. Configure developers work station routing ( assuming Windows based)
    to add a route for "booby" to their routing table that points to the
    2nd PIX

    i.e. route add 207.237.23.12 mask 255.255.255.255 <IP for pix #2>
    metric 1



    Bake until done ...
     
    mh, May 8, 2004
    #13
  14. :Would this work ???

    :2. Place a 2nd PIX in "parallel" with the first PIX

    :3. Configure developers work station routing ( assuming Windows based)
    :to add a route for "booby" to their routing table that points to the
    :2nd PIX

    You could probably work something along these lines. The second
    PIX would not do any port translation, but it would nat the outgoing
    packet source into the same IP address range as the outside range handled
    by the first PIX. The first PIX would receive the packet, and
    as far as it could tell, the packet came from outside. But the result
    would still be that both devices would be involved for *every* packet
    in the flow, so the speed is not going to be "on equal footing" with
    packets from the outside.

    You wouldn't need to use a hub on the outside: a switch would do,
    as would a router with two interfaces bridged to the same subnet.
     
    Walter Roberson, May 8, 2004
    #14
  15. Just to recap the original question for others:

    External traffic on single IP to internal machine with static port map.
    want to access internal machine using external IP for dev purposes.
    Can't do it on a PIX:501 and trying to understand why.

    This was very helpful and the pseudo code clarifies the logic. Sorry to
    put you through this.

    To recap your answer:

    I can't loop the traffic back through the 501 because the internal
    interface has a higher security than the external. I can't add another
    external interface on the 501 because I am limited to only two. I CAN
    stick a $49 dollar linksys outside the PIX.

    I don't think I have to have to do any clever routing. The Linksys does
    this loopback by default. You are right. This is a horrible hack. I am
    afraid that this would also make IPSEC a nightmare.

    In your pseudo it would seem like traffic from higher can pass through
    lower with proper routing and ACL, but as you say, that won't work. If I
    understand what you said earlier about NAT Pools, the reason is that
    even if defined another Nat pool, there would still be TWO on the SAME
    interface and the pix would either drop the packet because of that
    (perhaps it has an internal super-nat table) or because it really does
    just drop packets coming and going to the same interface regardless of
    routing or ACL instructions.

    Thank you for taking the time to walk me through this. The short answer
    remains, I can't do it on the 501.

    I read somewhere last night that one possible way to achieve this trick
    with a higher end PIX (with more interfaces than 501) would be to assign
    an external interface as a loopback e.g.. eth2 as 127.0.0.1 and route
    eth1 (internal) traffic destined for the external IP (eth0) to eth2
    (127.0.0.1) and then back to eth0. Perhaps this might work if the PIX
    doesn't compare packets across NAT pools on different interfaces?

    - p -
     
    peter breugle, May 8, 2004
    #15
  16. OK duh... Read your reply to MH. I think I just got it. The Pix isn't
    really a router. Is that the basic answer?
     
    peter breugle, May 8, 2004
    #16
  17. :OK duh... Read your reply to MH. I think I just got it. The Pix isn't
    :really a router. Is that the basic answer?

    It depends on what you define 'router' as.

    I have several times presented arguments to show that the PIX *is*
    a router. It is used to connect multiple broadcast domains based
    upon layer 3 information, which is the basic definition of a router.
    It just isn't very flexible in choosing what to route where, and
    it has the restriction of never routing a packet back out the same
    interface it came in (or in the same interface it went out of.)
    So it's a router, but it doesn't have much in the way of modern router
    features.

    You asked earlier if something was my "suggestion". My -suggestion-
    would be to change the requirement so that you don't need to do
    the port re-writing. Without the port re-writing issue, you'd have
    the standard ip-rewiring issue, which there are supported approaches to.
     
    Walter Roberson, May 8, 2004
    #17
  18. peter breugle

    mh Guest

    You wouldn't need to use a hub on the outside: a switch would do,
    Agreed; I suggested that hub because I know it works well and is dirt
    cheap

    I have one of these hubs on both my PIX 501's outside interface so I
    can connect a sniffer at any time to capture inbound/outbound traffic.
    no span commands, no fuss no muss; works everytime...
     
    mh, May 8, 2004
    #18
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.