Multiple Public IP Addresses To Be Used For DMZ - ASA 5505 - IOS 8.4(2)

[Arvo Bowen]

I'm trying to figure out how to forward an IP address to my DMZ servers allowing me to use the ACL to control access to the servers within my DMZ interface (LAN).  I can't figure out if the ASA handles that automatically when a NAT rule is created, or maybe when an ACL is created, or do I need to add it when configuring the interface (outside)?  Ex: IP Address: 1.1.1.1, 2.2.2.2, 3.3.3.3

Notes:

- I'm using the ASDM but can use CLI if needed.

- All IP address are fictitious of course.

- I currently have a public IP address of 1.1.1.1 that is used for all traffic coming from the ASA (including my NATed inside traffic).

- My local LAN subnet is 10.10.10.0/24.

- My DMZ subnet for my servers is 10.10.20.0/24.

- I have an IP address I want to use (public) of 2.2.2.2 that would be forwarded to my DMZed server of 10.10.20.2.

- I have an IP address I want to use (public) of 3.3.3.3 that would be forwarded to my DMZed server of 10.10.20.3.

[Jouni Forss]

Hi,

I am not sure if I understood you correctly.

Are you just asking how to configure Static NAT for your DMZ servers and allow traffic to them?

If so the basic NAT configuration format would be

object network SERVER-1

host 10.10.20.2

nat (DMZ,outside) static 2.2.2.2 dns

object network SERVER-2

host 10.10.20.3

nat (DMZ,outside) static 3.3.3.3 dns

The above 2 "object network" create the Static NAT between the internal private and external public IP addresses.

access-list OUTSIDE-IN remark Allow traffic to DMZ servers

access-list OUTSIDE-IN permit tcp any object SERVER-1 eq www

access-list OUTSIDE-IN permit tcp any object SERVER-2 eq ftp

access-group OUTSIDE-IN in interface outside

The above creates an ACL which allows for example HTTP traffic to SERVER-1 and FTP traffic to SERVER-2. Finally the last command attaches the ACL to the "outside" interface. If you already have an ACL attached to the "outside" interface then you naturally use that one.

Those are just simple examples.

Please let me know if I understood you incorrectly if I missed something

- Jouni

[Arvo Bowen]

Jouni,

Would Line A be the same thing as line B?

Line A:

nat (dmz,outside) source static any 2.2.2.2 inactive

Line B:

nat (dmz,outside) static 2.2.2.2 inactive

What's the point of the source and any keywords?  I just ask because I'm trying to understand why the ASDM is adding them.

Thanks!!!

[Jouni Forss]

Hi,

The Line A is a Twice NAT / Manual NAT format and this would not do a Static NAT between the internal and external IP address

The Line B is an Network Object NAT configuration line that is located under an "object network

The "source" defines that after it you will define the NAT for the source addressess. The parameter "any" will just simply state that any source address will apply to this configuration.

You also seem to have the "inactive" parameter at the end of the commands which means they are not in use.

The Line A doesnt make sense configurationwise.

The Line B is the NAT configuration line under some object so I cant see whats its source address is. (unless its the one I mentioned in my first reply)

EDIT: Typos

- Jouni

[Arvo Bowen]

Wow, tons of useful info with you guys!!!  Thanks!

The inactive is on purpose because I'm trying to learn where to config certain things in the ASDM, I didn't want anything to go live yet. 

Yes Line B was your network object line.  The way you described it makes perfect sense!

Although now in my config the following was added...

object network WBS1_DMZ
 host 10.10.20.2
 description webserver
object network WBS1_EXTERNAL
 host 2.2.2.2

~~~~~ OTHER CONFIG ~~~~~

!
object network WBS1_DMZ
 nat (dmz,outside) static WBS1_EXTERNAL

I'm guessing that the ! is saying that it's continued from another object network that was already created?

edited: changed nat rule from (any,any) to (dmz,outside)

[Jouni Forss]

Hi,

The "!" mark is just included in some parts of the CLI format configuration. It doesnt serve any real critical purpose. I guess it just separates certain part of the configuration from eachother

It seems that the configuration you posted above is configuring the other Static NAT I mention in my first reply.

The only difference is that instead of entering the public IP address 2.2.2.2 directly after the "static" parameter, you have instead configured the IP 2.2.2.2 inside its own "object network" WHICH you then use in the NAT configuration.

There is nothing preventing from doing it like this although I would have to say that from a purely CLI users perspective it creates a more complicated NAT configuration as we cant see the public IP address used directly in the NAT command and therefore have to see whats under the "object network WBS1_EXTERNAL" to determine that IP address.

- Jouni

[Arvo Bowen]

In your example above, should the following...

object network SERVER-1

host 10.10.20.2

nat (DMZ,outside) static 2.2.2.2 dns

be changed to the following...

object network SERVER-1

host 10.10.20.2

nat (outside,DMZ) static 2.2.2.2 dns

because when I have it changed to the latter I get no error, when I use your way I get the following error pop up...

"regular translation creation failed for icmp src dmz:10.10.20.2 dst outside:123.123.123.123 (type 0, code 0)"

[Jouni Forss]

Hi,

This configuration

object network SERVER-1

host 10.10.20.2

nat (outside,DMZ) static 2.2.2.2 dns

Would tell the ASA that:

• The host with IP address 10.10.20.2 is located behind ASA interface "outside"
• The host with IP address 10.10.20.2 should be translated to the IP address 2.2.2.2 on the "dmz"

From what I gather from your original information is that the host with the IP address 10.10.20.2 is behind interface "dmz" and should be translated to the public IP address 2.2.2.2 on the "outside". So it could be connected to from behind the "outside" interface with the IP address 2.2.2.2.

So to my understanding the configuration should be

object network SERVER-1

host 10.10.20.2

nat (DMZ,outside) static 2.2.2.2 dns

Ofcourse I might have missunderstood something in your original post.

- Jouni

[Arvo Bowen]

That is correct, but why would it be giving me that error then?

[Jouni Forss]

Hi,

To be honest it would probably be easiest to see the configuration in CLI format to see if there is any obvious problem there.

Would also have to know the IP address you are PINGing.

- Jouni

[Arvo Bowen]

It ended up being an extra NAT rule not needed.  For anyone else having this issue it might help to use the packet tracer in the TOOLS menu at the top of the ASDM.

I started out by trying to send an icmp (echo-reply) from the "outside int" with source ip being an outside ip ex: 127.127.127.1 then set up the destination ip as my outside ip ex: 2.2.2.2...  When I hit start I got back "The packet is allowed".  So that was good.

Then I tried the traffic back to the outside...  Source (some ip inside my dmz) ex: 10.10.20.2 and Destination (random public ip) ex: 127.111.111.1...  When I hit start I got back "The packet is dropped".  Then it told me about this little nat rule I forgot I put in there a while back.  So I removed the old NAT rule and BAM!  It started working great.

Hope it helps someone, if it does be sure to rate this reply as helpful. 

[Julio Carvajal]

Hello Arvo,

For traffic being sourced from those servers on the DMZ you do not need any ACL as the traffic will be going from a higher to a lower security level ( DMZ to OUTSIDE) but for traffic being generated on the lower security side you must use an ACL to allow the traffic ( lower to higher )

Hope that I could understood your question

Regards

[Arvo Bowen]

jcarvaja,

Thanks!  I never really thought of it that way...  Sometimes I wish the levels didn't exist...  I like to feel like I know each and every packet is accounted for with a rule. 

[Jouni Forss]

Hi,

If you dont want to use the "security-level" value with the ASAs then you can  simply configure an ACL to the ASA interface. As soon as you configure an ACL to the ASA interface then that will be the factor that controls the traffic for that interface.

The "security-level" wont affect the traffic flow anymore but the ACL will

- Jouni

[Arvo Bowen]

Yea I noticed that with the ASDM, as it removes the security level line that is there by default.    Thanks