Inbound connections on a 515e without NAT

Hello,

try and add the following to your config:

nat (inside) 0 access-list permit_web

Does that make a difference ?

Regards,

GNT

B Squared wrote:

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

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.

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.

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.

I hope this helps.

Ryan

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

The OP clearly had a valid identity static under the terms of the section "Identity NAT" in

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.

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

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

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

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