Inbound connections on a 515e without NAT

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

help@globalnettechs.com · Guest

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:

Walter Roberson · Guest

In article <0OmdnZPx5PE1i9rZnZ2dnUVZ_uidnZ2d@scnresearch.com>,
<"B Squared"> wrote:

Walter Roberson · Guest

In article <1145543276.048938.269510@i40g2000cwc.googlegroups.com>,
help@globalnettechs.com <help@globalnettechs.com> wrote:

rdymek@gmail.com · 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/products/hw/vpndevc/ps2030/products_tech_note09186a00800b6e1a.shtml#multi_nat

I hope this helps.

Ryan

Walter Roberson · Guest

In article <1145553306.866751.46350@t31g2000cwb.googlegroups.com>,
rdymek@gmail.com <rdymek@gmail.com> wrote:

rdymek@gmail.com · 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/products/sw/secursw/ps2120/products_command_reference_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@gmail.com · 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/products/sw/secursw/ps2120/products_command_reference_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