Inbound connections on a 515e without NAT

Discussion in 'Cisco' started by B Squared, Apr 20, 2006.

  1. B Squared

    B Squared Guest

    All,

    I have a PIX 5i5E configured that permits outbound connections
    from inside our network. However I can't get it to permit inbound
    ones. I know this should be fairly simple, I think the complication
    is we aren't doing NAT, and are using the same addresses inside as
    outside. Here's the revelant part of our configuration.


    PIX Version 7.0(4)2

    ! we use NAT control but use our real addresses on the inside
    nat-control
    global (outside) 1 interface
    nat (inside) 1 0.0.0.0 0.0.0.0

    interface Ethernet0
    nameif outside
    security-level 0
    ip address A.B.50.14 255.255.255.0

    interface Ethernet1
    nameif inside
    security-level 100
    ip address A.B.70.1 255.255.255.0

    route outside 0.0.0.0 0.0.0.0 A.B.50.1 1

    ! So far this part works as it should, here's
    ! the part I'm having trouble with. Lets say I
    ! I have a web server at A.B.70.50, From what I've
    ! read, I would have thought the following would
    ! permit inbound traffic to it.

    access-list permit_web extended permit tcp any host A.B.70.50 eq 80
    access-group permit_web in interface outside

    static (inside,outside) A.B.70.50 A.B.70.50 netmask 255.255.255.255

    But, this fails. My thinking was to allow a connection for the address
    of the web server. So when this failed, I thought, maybe I allow
    the connection on the outside interface, like:

    static (inside,outside) A.B.50.14 A.B.50.14 netmask 255.255.255.255

    Even though, if this worked, it would allow inbound connections to every
    system behind A.B.50.14 on the PIX. But even this doesn't work.

    I've looked pretty carefully through _Cisco PIX Firewalls_ (Behrens, et
    al) and through other postings in this group, but they all use NAT /
    PAT. In fact, it seems as though the static(,) command pretty much
    expects some form of address translation, and isn't very happy unless it
    occurs.

    Thanks in advance for any help.

    B Squared
    =========================================================================
    I've gone to hundreds of fortune-tellers' parlors, and have been told
    thousands of things, but nobody ever told me I was a policewoman
    getting ready to arrest her. --Unknown NYC Detective
     
    B Squared, Apr 20, 2006
    #1
    1. Advertisements

  2. B Squared

    help Guest

    Hello,

    try and add the following to your config:

    nat (inside) 0 access-list permit_web

    Does that make a difference ?

    Regards,

    GNT
     
    help, Apr 20, 2006
    #2
    1. Advertisements

  3. If you are using the same addresses inside as outside, then you
    should remove the global/nat pair -- it would be redundant and would
    confuse the issue.

    Yes, that should be valid.

    Is your WAN router routing A.B.70.* to A.B.50.14 ?
    No, you cannot static the entire outside IP to anything, as some
    ports are reserved for accessing the PIX itself... and it would mess up
    things like VPNs if it were to succeed. And in your configuration
    as it stands, it would also violate the constraint,
    "Do not use a mapped address in the static command that is also defined
    in a global command for the same mapped interface."
    http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_70/cref_txt/s.htm#wp1145074

    No, static'ing a port for outside interface IP forwards traffic addressed
    to that interface IP. static'ing the outside interface IP has no effect
    on traffic flowing -through- the PIX via other IP addresses.

    Looking at what you have presented here, it appears to me that the
    WAN routing step is your likely problem.
     
    Walter Roberson, Apr 20, 2006
    #3
  4. Please do not top-post. It might be easier for -you-, but it isn't
    easier for the many readers of your posting, and it puts the burden
    of the editing work on anyone replying to your post.
    I haven't gone very deep into PIX 7, but in PIX 6 that would be
    a definite error. In PIX 6, when you have an access-group applied to
    an interface, the PIX internally manipulates the indicated access-list
    in order to permit return traffic and other traffic as required by
    the Adaptive Security Algorithm. If there is another reference to that
    access-list, then the internal alterations to the access-list
    would take effect in the other context as well. In this case, you
    would suddenly have NAT "disabled" for connections where it should
    instead be "static" NAT. The differences are subtle when one is
    static'ing an IP to itself, but one of the differences is that when
    NAT is "disabled" then proxy ARP is turned off for that IP, which
    could cause you to lose all communications to that IP from the outside.
     
    Walter Roberson, Apr 20, 2006
    #4
  5. B Squared

    rdymek Guest

    You are accurate in that the PIX does prefer to NAT. It is not a
    router, and NAT is *generally* the best option, and when NAT is
    augmented with all the other security features of the PIX, it adds a
    better layer of protection as to not reveal real addresses outside the
    PIX. However, although the PIX does prefer NAT, there is a way around
    it, and is a built-in feature. I believe another person on this
    posting also mentioned it, but it seems to have been overlooked. You
    need to use nat0 to accomplish this.

    Here's a Cisco article that discusses NAT, and has a good section on
    nat 0.

    http://www.cisco.com/en/US/partner/...cts_tech_note09186a00800b6e1a.shtml#multi_nat


    I hope this helps.

    Ryan
     
    rdymek, Apr 20, 2006
    #5
  6. I haven't seen any indication that that is true.
    I haven't seen any indication that that is true, either.
    Every transit packet delivery starts by applying the routing tables
    to determine the output interface. PIX doesn't allow packets to
    enter and exit the same [logical] interface (except 7.x's provisions
    when a VPN is involved), but there is no requirement that a router
    handle same-interface traffic.

    A router is a device that joins multiple broadcast domains, and
    the PIX meets that definition.

    There are some people who are campaigning quite hard to get rid
    of NAT because of the protocol perversions and overhead it imposes.
    cf. Melinda Shore, whose long experience deserves respect even if one
    might happen to disagree with specific conclusions.
    That sentance is based upon the assumption that the PIX prefers
    NAT and that anything else must be worked around. However,

    static (inside,outside) X.Y.Z.W X.Y.Z.W netmask 255.255.255.255

    is no "work-around": it is exactly the same level as

    static (inside,outside) X.Y.Z.W A.B.C.D netmask 255.255.255.255

    such as would be used for static NAT.

    Identity static goes back at least as far as PIX 4.1; see in particular
    the example

    static (inside,outside) 10.0.0.0 10.0.0.0 0 0 classc

    http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_41/pixcfg41/pix41cmd.htm#wp4262

    The OP clearly had a valid identity static under the terms of the
    section "Identity NAT" in
    http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/s.htm#wp1026694

    As such, using nat 0 access-list would render the existing static
    redundant, and would effectively only have the result of disabling
    proxy ARP -- nothing that is going to help the OP's situation.

    The entire situation can be simply explained by the WAN router
    not routing the internal (public) IP range to the PIX outside IP.
    No nat 0 access-list is needed.
     
    Walter Roberson, Apr 21, 2006
    #6
  7. B Squared

    rdymek Guest

    There are some points I agree with, and some I disagree with, but going
    back and fourth on disagreements that don't directly apply won't help
    the OP.

    Something that needs some addressing though is the discussion about nat
    0 vs. identity static. Some of what has been said is accurate, but
    only to a point. There is a major difference between how nat 0 can be
    deployed. I mentioned using 'nat 0 access-list'. This method is
    employing nat-exclusion. However nat 0 <net IP> employs identity nat.
    The effects seem identical to many admins, but they are totally
    different. NAT exclusion (using an ACL) actually disables NAT for the
    addresses and networks listed. Identity NAT follows the exact same
    process as regular NAT just NATing the internal address to itself.
    This means that if you're doing identity NAT, you're using the same
    overhead as any other NAT (not to mention you're explicitly introducing
    all the "protocol perversions" you mentioned). Cisco CSPFA course,
    Cisco TAC, and much of my own experience state that using nat 0
    access-list is preferred if NAT is not required.

    This link under the NAT section describes NAT nicely:
    http://www.cisco.com/en/US/partner/...erence_chapter09186a00801727ab.html#wp1032129

    I don't believe we have enough information to determine that it is or
    isn't a routing problem. Can you provide the route table for the
    router on the outside interface? If it were a routing problem (and
    assuming NAT was working properly), then I'd believe you would neither
    have outbound or inbound communication - in this case outbound works
    fine. The packet acknowledgements or any data destined to the 'host'
    wouldn't make it back if that network were not routed to the PIX.

    Is there any particular reason why you feel inclined to use
    nat-control? You've said that you're not performing NAT, and are using
    all original private addresses, yet this is enabled. By disabling this
    (no nat-control) you can completely take NAT out of the scenario. Then
    it will just pass traffic through with all the original source IP's and
    no defined static entries or anything at all relating to NAT. Only if
    you want to define NAT you could, but it wouldn't be required (whereas
    with nat-control enabled its required for EVERY host on your network to
    have a NAT (even if its identity nat) to pass traffic.

    Ryan
     
    rdymek, Apr 21, 2006
    #7
  8. B Squared

    rdymek Guest

    There are some points I agree with, and some I disagree with, but going
    back and fourth on disagreements that don't directly apply won't help
    the OP.

    Something that needs some addressing though is the discussion about nat
    0 vs. identity static. Some of what has been said is accurate, but
    only to a point. There is a major difference between how nat 0 can be
    deployed. I mentioned using 'nat 0 access-list'. This method is
    employing nat-exclusion. However nat 0 <net IP> employs identity nat.
    The effects seem identical to many admins, but they are totally
    different. NAT exclusion (using an ACL) actually disables NAT for the
    addresses and networks listed. Identity NAT follows the exact same
    process as regular NAT just NATing the internal address to itself.
    This means that if you're doing identity NAT, you're using the same
    overhead as any other NAT (not to mention you're explicitly introducing
    all the "protocol perversions" you mentioned). Cisco CSPFA course,
    Cisco TAC, and much of my own experience state that using nat 0
    access-list is preferred if NAT is not required.

    This link under the NAT section describes NAT nicely:
    http://www.cisco.com/en/US/partner/...erence_chapter09186a00801727ab.html#wp1032129

    I don't believe we have enough information to determine that it is or
    isn't a routing problem. Can you provide the route table for the
    router on the outside interface? If it were a routing problem (and
    assuming NAT was working properly), then I'd believe you would neither
    have outbound or inbound communication - in this case outbound works
    fine. The packet acknowledgements or any data destined to the 'host'
    wouldn't make it back if that network were not routed to the PIX.

    Is there any particular reason why you feel inclined to use
    nat-control? You've said that you're not performing NAT, and are using
    all original private addresses, yet this is enabled. By disabling this
    (no nat-control) you can completely take NAT out of the scenario. Then
    it will just pass traffic through with all the original source IP's and
    no defined static entries or anything at all relating to NAT. Only if
    you want to define NAT you could, but it wouldn't be required (whereas
    with nat-control enabled its required for EVERY host on your network to
    have a NAT (even if its identity nat) to pass traffic.

    Ryan
     
    rdymek, Apr 21, 2006
    #8
    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.