Noob ASA (port forwarding) Question

If you are NAT'ing/PAT'ing the outside interface to 192.168.0.101 and trying to allow outside traffic to hit the internal 192.168.0.101 host, your outside ACL needs to reference the address of your outside interface.

Hm, that's what I had originally and it wasn't working. Even with my public IP in there, Shields Up is still showing all the ports as closed.

When I'm testing with Packet Tracer, should I simply use my public IP with the ports I'm testing or would I use my private IP? Everything comes up ok when I use the public IP when I've set that as the destination in my security policy.

dynamik wrote: »

Hm, that's what I had originally and it wasn't working. Even with my public IP in there, Shields Up is still showing all the ports as closed.

When I'm testing with Packet Tracer, should I simply use my public IP with the ports I'm testing or would I use my private IP? Everything comes up ok when I use the public IP when I've set that as the destination in my security policy.

Check any local firewalls on the inside host. Is there anything else between the host and the ASA that would block the traffic.

Do you have a route on the ASA to the subnet the inside host is in?

No, this was working with an antiquated Windows 2003 server running RRAS, which handled the NAT/port forwarding before I switched over to the ASA. If I move the cables back over, it works fine, and I can access it internally fine.

1) change the outside ACL entry to have your Outside interface IP address as the DST address.

access-list OUTSIDE-ACL permit tcp any host interface eq 443

2) you need a ACL entry for your inside interface as well (interface the internal hosts hang off...) As the traffic is coming from a lower level interface to an higher level interface.

access-list INSIDE-ACL permit x.x.x.x host 192.168.0.101 eq 443

3) With Pkt Tracer you have specified the Outside interface as where you want the test run... so you should be using a SRC IP of something outside your network... and then defining the ip address of your outside interface (The outside DST for your NAT).

As outside hosts will be connecting to your Outside Global NAT address not your inside hosts address.

Make these changes and let us know how you go

Something like this.

static (Inside,Outside) tcp 5.5.5.5 smtp 10.5.5.5 smtp netmask 255.255.255.255
static (Inside,Outside) tcp 5.5.5.5 www 10.5.5.5 www netmask 255.255.255.255
static (Inside,Outside) tcp 5.5.5.5 https 10.5.5.5 https netmask 255.255.255.255
access-list Outside_access_in extended permit tcp any host 5.5.5.5 eq smtp
access-list Outside_access_in extended permit tcp any host 5.5.5.5 eq www
access-list Outside_access_in extended permit tcp any host 5.5.5.5 eq https

A.P.A wrote: »

1) change the outside ACL entry to have your Outside interface IP address as the DST address.

access-list OUTSIDE-ACL permit tcp any host interface eq 443

2) you need a ACL entry for your inside interface as well (interface the internal hosts hang off...) As the traffic is coming from a lower level interface to an higher level interface.

access-list INSIDE-ACL permit x.x.x.x host 192.168.0.101 eq 443

3) With Pkt Tracer you have specified the Outside interface as where you want the test run... so you should be using a SRC IP of something outside your network... and then defining the ip address of your outside interface (The outside DST for your NAT).

As outside hosts will be connecting to your Outside Global NAT address not your inside hosts address.

Make these changes and let us know how you go

I don't think he needs the Inside ACL....he's allowing all to less secure interfaces already.

You are mis-interpreting the inside acl... that covers the return traffic... but what about the original request from the outside host?

the inside acl says any source traffic to destination lower security levels.... which is allowed by default... as higher security interfaces can send traffic out to lower security interfaces always unless explicitly denied...

Think about where the traffic is coming from and going to.....

It's coming from outside lower security..... ACL Outside lookup... Passes

Then it follows the NAT rule.. passes

Then it has another ACL lookup as it's trying to go from a lower security interface (Outside) to a higher security interface(Inside) - Fail!

Remember the ASA\PIX does not allow traffic from [SRC]lower to [DST]higher security levels unless a explicit ACL is entered....

I lost my implicit "any less secure" rule when I specified those on the incoming interface. I just put all/all in for the time being.

I'm still not showing those ports as being open when I run an external scan. I don't see anything on the server that would be blocking it.

If this is not a production box, go ahead and allow any any from the outside and see if it works then. If not, double check the host IP (i know, this is simple). If the host IP is correct there has to be an issue with the services running on the host. Maybe they aren't running or there is something else preventing that traffic from getting where it needs to go.

Let us know how it goes.

You can set up a capture to see what packets the ASA is dropping.

It's production, but it's ours, so I can play a little bit. After awhile though, people got sick of not getting email, so I had to move back to the old setup. All I did was move cables around and everything worked. I'm sort of stumped because this seems like it's so much more difficult than it should be. The IP information, services, etc. are all good.

dynamik wrote: »

It's production, but it's ours, so I can play a little bit. After awhile though, people got sick of not getting email, so I had to move back to the old setup. All I did was move cables around and everything worked. I'm sort of stumped because this seems like it's so much more difficult than it should be. The IP information, services, etc. are all good.

Have you considered using the CLI, rather than ASDM? The ASDM is great for looking at things, but I personally like the CLI better for configuration because of some of the things the ASDM does to the config.

The code I posted earlier should work. I have the exact same config running and it works fine.

Is this an Exchange box? in support of webmail?

Yea, and I came to the same conclusion as I did when I considered juggling chainsaws

I'll post the config tomorrow, and it is indeed an Exchange box.

Thanks for all your help.

have you actually tried to connect to the port from the outide interface and see if the nat is working correctly??

I have a feeling the external port scan will not work..... remember the ASA is a security device it shouldn't be allowing port scans....

Run the actual connection test as there seems to be absolutely nothing wrong with your config now... but as CT said... show us the CLI config as I prefer to view that as well

Yea, it was live. Internet access and everything else was fine. I wasn't in a position where I could try connecting externally, but no email came in the entire time it was in place. It started up again as soon as I switched back to the old device. I'll post the config in the morning. Thanks again.