The public address cannot be the same as the public interface address

[FlorianCokl]

Hello,

I thought I had found a nice way to add Service(s) to be available publicly. I thought that this site would allow me to add autmatically the NAT and ACL entries, you would ususally have to do in 2 separate steps, in just one step. So I jumped right in.

However, I was pretty surprised by the Error-Message I got from ASA. You can see it for yourself in the printscreen I attached.

There's only 1 WAN-address available in this scenario!

I understand the message, I just can't believe that this is it? I can't believe I am the only one with that outcome, right?

ASA 8.4 with ASDM 6.4

[Jouni Forss]

Hi,

Sadly I don't really use ASDM myself.

Do you want to configure NAT so that a certain ports connections from your outside interface IP are forwarded to a certain port and certain host on your local network?

I can provide the CLI format configuration for that atleast.

- Jouni

[varrao]

Hi Florian,

Wat you might be trying to do is to map the complete outside interface to the single server, which is not advisable, since it would block other management accesses or services running on that interface.

Wat you can definitely do is to port forward on the ASA, which means you can use a specific port on the public ip rather than the complete interface. On the CLI the command would look like this:

On the screen at the bottom you would see an option for "specify public service" select that option and then define your service or port on the ASA outside interface.

Thanks,

Varun

[FlorianCokl]

Hello Varoun,

your statement:

"On the screen at the bottom you would see an option for "specify public service" select that option and then define your service or port on the ASA outside interface."

Isn't that meant to change the port on the outside to something different than what was defined in the 3rd box under "Private Service"?!

I understand that in this way:

I have configured a Service Group called HELIXSIMM which reflects tcp-udp/44444. I am using the Network Objekt HOST-MACMINISERVER together with the HELIXSIMM Service Group to be offered to the outside with the exact same protocols and ports. If I'd like them to be different on the outside I'll use this option.

[varrao]

Hi Florian,

The public port can be the same as the private port or different. That depends on what you want. Let me explain you wat we r trying to achieve by it.

Lets say someone on the internet access the server on tcp port 44444.

The request would hit the outside interface on port 44444 and would get translated to port 44444 on the private server ip. If you want to change the port on outside you can make it 44445 or anything that you want.

This is the logic of port translation on ASA. Remember, do not use the whole interface IP to nat to a server, it would use the whole IP address, instead use ports on the IP.

Thanks,

Varun

[FlorianCokl]

Hello Jouni,

there's nothing sad about it - I use both. It's just that I prefer the ASDM over the CLI when it comes to ASA. With IOS routers or switches it's is vice versa.

Of course I can do it with CLI, and by that I mean I am fully capable ....

Yet, I thought I had a found a nice way to activate Services to the outside with just 1 step needed to do so. Usually you do the NAT and afterwards you do the ACL. Meaning: you create the necessary config for NAT and after that you punch the holes into the firewall reflecting the ports of previously configured NAT. The picture I attached that shows the site of ASDM which is supposed to offer a consolidation of these 2 Jobs (= creating NAT and punching holes), isn't willing to do so. It only does if you change the IP to anything else different from the outside interface's IP. But what if you have only 1 IP instead of a range. That is pretty common. I can't follow the logic here.

Apropos logic:

Do I really have to use these 2 line NAT-entries, meaning "object-oriented-nat"? Is this just a new way of complicating everything? I thought it was easier (with 8.2), especially when it comes to VPN, to explicitly deny certain traffic from being natted (which makes perfectly sense in context of VPNs) than what you have to do now where you have to define every little aspect of traffic.

[Jouni Forss]

Hi,

I'll agree with you that the change from 8.2 -> 8.3 doesn't seem to make things easier with NAT. Atleast when you've used the 8.2 (and pre) format for years. Though I think after a while of getting used to it should be fine. It does seem though that alot of "moving parts" were added when changing to the NAT format.

I've done port forward in the new software mostly for different IP address than the outside interface. In general Port Forwarding is something we like to avoid always but do them if theres no other way.

Basic configuration would be

object network HOST1-TCP80

host 10.10.10.10

! nat (inside,outside) static interface service tcp

nat (inside,outside) static interface service tcp 8080 80

access-list OUTSIDE-IN permit tcp any object HOST1-TCP80 eq 80

EDIT: Had the ports the wrong way in the NAT statement

And if you check this configuration from CLI you have to use 2 show commands to check the configuration instead of the one you used before. "show run static"

I'm not sure if theres another way to do the same NAT but I've just doen them like the above configuration.

- Jouni

[llamaw0rksE]

A most interesting thread.  I am the quintessential new ASA and new Cisco user and have walked through all of the above already in my short journey.  Simple case too,  one static WANIP and a bunch of servers to port forward on the inside lan and some IP subnets or individuals to narrow down access via ACLs.   I too struggled with the ADSM, in that I tried that public server page,  I tried NAT rules from the nat rule page, I tried acl rules from the ACL manager.  All big mistakes.

I did not know one had do tell the router where the next hop was, via a separate command.  I did not know that acl rules not attached to an interface were useles.  etc etc.  I did not know that dynamic pat, snat or whatever you want to call it wasnt automatically generated.   I have used CLIs but copying lines of text to implement packet flows not understood is terrible.  The ADSM is great as it pictorially shows you the results of ones horrible programming skills LOL. From the nat rules page, to ACL page to packet tracing.

Suffice to say,

I have avoided using the public server but may try it now that I am braver.

I learned how to create Static NAT rules via the objects menu (and dont laugh, more recently how to access the embedded nat rule via the NAT rules menu selection - see that small sliver of a button to the right of the ADD button. Yeah that one! 

I learned to make ACL rules from the Access Rules selection at the top (not acl manager) because you have to tie in each rule to an interface (which is missing in acl manager).

The other important item that caught my eye was your discussion of order.  The docs all say acl before NAT.  This is kind of true, if you look at the packet tracer the router does an unnat before acl then nat.  Dont ask me, but it seems to verify if a valid nat rule is in place before applying ACLs, then after applying acls, actually applies nat rule.  

Before or after is not a big item it just guides one into which services/ports the ACL really has to encoutner and deal with.

I really like the ADSM so far, but learning my way around it was more difficult than it should be.

I would like to be able to program manual nat or twice nat and then VPNs. (ipsec and ssl)

[FlorianCokl]

Hello Alex,

true - so true

The Public Server Site - yes - ahm, like I tried to say: It'll work if you have a range of WAN-IPs at your hand. I couldn't use this site, or the funtionality of this site, if the Service (lets say SMTP from the Mailserver at 172.17.17.50) was to be natted onto the same IP that the outside interface received already. Anything than that you'll find the according entries in NAT and ACL to be made automatically for you. This behaviour is just awkward to me

However, that doesn't mean I wasn't able to translate the Services needed - totally misconseived if anybody had thought that. I just made one NAT-entry after the other, then a lot less entries in the ACL (because I used Service Groups) but reflecting exactly the ports previously configured in NAT.

Apropos NAT then ACL vs. ACL then NAT:

For the ASA it isn't of any meaning, if you boil it down. In the end I believe that the NAT should be done first and then open the doors in the ACL reflecting the needs of NAT. Why? Well, incoming packets are inspected by ACLs first and NAT is the very last function applied to the packet/flow. In my opinion this is a form of "nice-engineering" if you do NAT first. Every packet once allowed traveling out-2-in will (under no circumstances) get lost in translation or somewhere else.

[llamaw0rksE]

My beef is with the UNNAT process as though it checks to see first if there is a NAT rule that makes sense before applying the ACL.  

Lets say I need an external clients  mapped port of 80 (they are only allowed outbound of 80 on their corporate internet access), to the real port 4050 on my inside server. 

One would think I need to implement ACL on port 80 for that external client static IP (corporate incoming) based on the fact the documenation says ACLs first.  I discovered that I had to actually allow 4050 as well.    Now that my setup is accurate I am tempted to revisit but I have a sneaking suspicion that  with UNNAT occurring then ACL, then NAT, its not a clear path or answer.  I sell and use Zyxel routers and they clearly put NAT first, then ACLS which I prefer and thus the acl rule is always applied to the real port.