Inbound connections on a 515e without NAT

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

 

Hello,

try and add the following to your config:

nat (inside) 0 access-list permit_web

Does that make a difference ?

Regards,

GNT

 

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.

 

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.

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


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

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.

 

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

 

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