Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Incoming NAT rule

I am trying to configure an incoming NAT rule.  As such, I want a routable address to be able to be translated to an internal one.

However, I’m unsure exactly how that is set up.  I’m assuming that you want it to be static, and therefore bidirectional.  How do you know if the initial setup is outside to inside or vice versa? (or does it matter if it is bi-directional?)  So far on my test network I don’t seem to be able to achieve doing this.    The test that I am using is making the non-routable 192.168.2.4 into a 10.64.204.97.   ( I am thinking that for this test if I were to correctly set it up, when I ping the address of 10.64.204.97, I would really be pinging 192.168.2.4, but so far no combination of the above seems to return a good ping.)

Do you have any advice on the best way to do this?  The documentation on it I have found so far has not been helpful to me.

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Incoming NAT rule

Hi Heather,

In 8.3, the commands will look like this instead:

object network obj-192.168.2.4

     host 192.168.2.4

     nat (inside,outside) static 10.64.204.97

access-list outside_access_in permit icmp any host 192.168.2.4
access-group outside_access_in in interface outside

To answer your question, yes this will work bidirectionally. When someone tries to ping 10.64.204.97, the ASA will translate the packet and forward it to 192.168.2.4. Likewise, if 192.168.2.4 goes out to the Internet, it will appear as if the traffic is coming from 10.64.204.97 after it passes through the ASA.

Hope that helps.

-Mike

25 REPLIES

Re: Incoming NAT rule

Hi,

What exactly do you want to do?

If you want an incoming NAT rule, most likey is a STATIC NAT (by the way is this an ASA or IOS device)?

Federico.

Cisco Employee

Re: Incoming NAT rule

Hi Heather,


What version of code is your firewall running? This will affect the commands you need to use. In addition to the static, you'll also need to setup your access rules.


If you post a copy of your configuration, we should be able to give you the commands you need.


Here is a really general example:


static (inside,outside) 10.64.204.97 192.168.2.4 netmask 255.255.255.255

access-list outside_access_in permit icmp any host 10.64.204.97

access-group outside_access_in in interface outside


Hope that helps.


-Mike

New Member

Re: Incoming NAT rule

Hi Mike,

I believe that I'm running the latest version, 8.32.

So with the above statement, you are setting it up bi-dierctionally so that when the outside pings the external address, the ASA routes it to the internal address, right?

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

In 8.3, the commands will look like this instead:

object network obj-192.168.2.4

     host 192.168.2.4

     nat (inside,outside) static 10.64.204.97

access-list outside_access_in permit icmp any host 192.168.2.4
access-group outside_access_in in interface outside

To answer your question, yes this will work bidirectionally. When someone tries to ping 10.64.204.97, the ASA will translate the packet and forward it to 192.168.2.4. Likewise, if 192.168.2.4 goes out to the Internet, it will appear as if the traffic is coming from 10.64.204.97 after it passes through the ASA.

Hope that helps.

-Mike

New Member

Re: Incoming NAT rule

HI Mike,

What is the benefit to doing network object nats vs just regular nats?

Also, I don't know if you are familar with ASDM, but where do the access_list commands show up on it?  I thought they would make changes to the access list area, but they don't.  My learning of this ASA has been a hybrid of CLI and ASDM, so I try to make sure I understand how it works on both fronts.

Thanks, btw, that worked great!

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

Glad to hear that worked for you. In 8.3, it's best to do as much as possible in the Auto/Object NAT section as the ASA will do a better job about ordering the configuration and choosing the correct statement to match the traffic. The Manual NAT section can be used when you need to do translations based on the destination or for NAT exemption.

In ASDM, the 'access-list' commands will show up in the Configuration > Firewall > Access Rules pane once you apply them with the 'access-group' command. Otherwise, you'll see them listed under Configuration > Firewall > Advanced > ACL Manager.

-Mike

New Member

Re: Incoming NAT rule

Hi Mike,

A question came up with this last night during live testing.  This rule worked great to allow our webserver to be accessible via the internet.  However, we needed another inside to outside NAT rule to allow us out to the internet.   I have noticed that you cannot have two static NAT rules both going from internal to external, even if the parameters for each are different, or if they're associated with an object.  Can you tell me why that is?    I noticed that when I did this, and then pinged the external address for the webserver, the reply came from the address (or pool of addresses) that I had set up for the external surfing rule.  Obviously the two rules are getting mixed up with each other, but I'm having trouble rectifying logically why that is.

I was able to achieve my objective by using the static rule for the webserver and then using a dynamic PAT rule for getting out to surf the internet and access other outside resources.  I am not 100% sure that this is the best long term solution for us.  Are there drawbacks for using PAT address translation indefinately in this way?

Thanks again

Heather

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

Can you share the NAT config that you have? I tested this on my ASA and it worked as expected. I have:

object network obj_any
  subnet 192.168.1.0 255.255.255.0

  nat (inside,outside) dynamic interface

object network server

  host 192.168.1.1

  nat (inside,outside) static 10.1.1.1

With this configuration, I can access the host at 192.168.1.1 from the outside by using 10.1.1.1. Likewise, when 192.168.1.1 goes out it looks like 10.1.1.1. Anyone else in the 192.168.1.0 subnet goes out looking like the outside interface of my ASA.

-Mike

New Member

Re: Incoming NAT rule

Ok, that is similar to what I was decribing, where you use a static for the web server and then a dynamic for outgoing traffic.  Is that a reasonable long term solution?  I had read that static nats were the way to go, but it seems like using dynamic nats for web surfing traffic is more ideal.

My nat rules are, I think, as follows:

nat (INSIDE,OUTSIDE) source dynamic any interface
!
object network obj-192.168.204.0
nat (INSIDE,OUTSIDE) static xxx.xx204.84 dns

That works fine for what I need, but why can't there be two static NATs assigned to different specific IP addresses or pools going from inside to outside?

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

The reason that the outbound traffic is using the dynamic rule is because it is configured in the manual NAT section. All of the NAT rules in this section will be processed in order before any of the object/auto nat rules take effect.

Your configuration will certainly work fine. However, if you want your web server to use the static rule when it goes out to the Internet, you would want to move the dynamic rule down into the object/auto NAT section like the example I posted above.


Hope that helps.

-Mike

New Member

Re: Incoming NAT rule

Ok, interesting.  I thought last night I configured two object nats and they did not work.

They may have both been static nats, though.

So you're saying that with this configuration, we can get into the web server as described, but return traffic will be routed dynamically rather than statically?  Are there implications to that?

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

You're absolutely correct. There are no real implications to sticking with the current setup unless you start adding more translations in the future and the manual NAT overlaps and takes precedence. Doing as much as possible in the auto/object NAT section will help you avoid these overlaps in the future and thus simplify the config process for you.

-Mike

New Member

Re: Incoming NAT rule

Hi Mike,

One more question that has arisen with this:  Would this NAT affect VPN traffic at all?  Perhaps this is a silly question, but we're trying to troubleshoot a VPN setup.  I don't know much about this yet, but I do know that my static rule has been one change since it allegedly "worked".  Now apparently traffic is not getting out or in for that VPN connection.

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

Most of the time you would want to setup an identity NAT rule when your inside hosts talk to the VPN hosts. For example:

VPN subnet: 10.1.1.0/24

VPN terminates on outside interface

Internal subnet: 192.168.1.0/24

object network obj-10.1.1.0

   subnet 10.1.1.0 255.255.255.0

object network obj-192.168.1.0

   subnet 192.168.1.0 255.255.255.0

!

nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-10.1.1.0 obj-10.1.1.0

This will tell the ASA not to translate any traffic passing between your internal subnet and the VPN subnet. If that's not quite what you're looking for, let us know.

Hope that helps.

-Mike

New Member

Re: Incoming NAT rule

Mike,

So this NAT rule would effectively tell it not to use the existing Dynamic PAT rule when accessing the

VPN connection, right?  (which is the existing external access NAT atm)

The difficulty in configuring this process is that we have another department (to which we are establishing a VPN) who is trying to help us get this set up, but their network configuration is not the same as ours, so I think a lot of what they believe to be true is not true for us.  They have set up this VPN, but there are no NATs associated with it.  (it does not work....although intermittantly they can ping us, but we can never ping them)

They seem to be of the opinion that because of our gateway setup, we will never be able to access both the internet AND them.  I believe this to be false.  We are using our interfaces as gateways because we have only layer 2 switches, which do not have routing functions.  Right now, we can get out to the internet, and we can get out to other subnets, and thanks to the NATs we did here, we can get traffic to and from our webserver out to the internet.   Therefore, I do not believe our problem to be a gateway issue, but rather a setup issue.

With the syntax that you have listed, would that allow a specific set of rules for connection to this vpn and back, without disturbing the other rules, right?

(a series of dramatic events yesterday led to my new ASA's being put into production before they are completely ready, so I cannot experiment quite as easily as I did before)

Thanks again!

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

So this NAT rule would effectively tell it not to use the existing Dynamic PAT rule when accessing the

VPN connection, right?  (which is the existing external access NAT atm)

Yes, that is correct.

With the syntax that you have listed, would that allow a specific set of
 rules for connection to this vpn and back, without disturbing the other
 rules, right?

Correct again. The example I gave sets up a simple NAT exemption, only for traffic between your internal subnet and the remote VPN subnet.

Hope that helps.

-Mike

New Member

Re: Incoming NAT rule

So typing those objects in created a regular NAT rather than the object NATs that we have been creating previously.  Is that correct?  It seems like I was learning that object NATs are the preferable NAT to have.

--Heather

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

Correct again. I mentioned before that a good rule of thumb is to do as much in object NAT as possible. However, this is a case where it is necessary to do manual NAT instead. This is because we need to also specify the destination subnet in the NAT rule (i.e. the remote VPN subnet). Only the manual NAT section can be used when specifying a destination.

-Mike

New Member

Re: Incoming NAT rule

Ok, that makes a lot of sense.  I think the source/destination thing was throwing me off about object NATs, but now I see where the difference is.

Once that rule is in place, when I run a visual tracert, I no longer get any hops.  Does that indicate that the rule is doing what it needs to?  (I think I had 6 or 7 hops before)  I would think that you'd want a VPN tunnel to seem like a direct connection, right?   Due to the complication of the other agency being involved in this set up, it's hard to know what is a problem on my side, and what is a problem on theirs!

Thanks again for your assistance!

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

It's hard to say. By default, the ASA will not show up as a hop in a traceroute because it does not decrement the TTL field in the IP packet. The better way to test would be to check the output of 'show crypto ipsec sa' and see if the encap and decap counters are incrementing for the tunnel when you try to send traffic over it.

You can also check the packet-tracer output to make sure the correct NAT rule is being chosen and the traffic is being sent over the tunnel. Try this on the ASA:

packet-tracer in icmp 8 0

That will simulate a ping from to and the results should tell you which NAT rule is being matched and if the traffic will be encrypted for VPN.

-Mike

New Member

Re: Incoming NAT rule

Hi Mike,

Thanks for that info!  I appreciate your help.

Apparently, stuff is not set up on the other side, so I can not test my changes.  They told me that doing the static NAT statements will send traffic outside of the established VPN tunnel (thus unencrypted).  I do not see how that would be the case.    They are telling me that the ONLY way to get traffic sent through the tunnel is by having the switch before the ASA indicate a route, or otherwise the traffic will not know which way to go.  I have a hard time with this idea.  Since the decision to encrypt or not encrypt data is made on the firewall, I don't see why it would make a difference what information the internal switch has.   It is not like VPN traffic gets a magic new route to their side, it just is encrypted while travelling there.  I thought I would get your take on this, although I realize it might not be your specialty.  I'll also post it in the VPN section where it might be more appropriate, since we are getting a little farther away from my original post here!

I'm sorry for making this "the thread that wouldn't die", but I find your explanations concise and easy to understand, so thanks for that!

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

I'm not sure I fully understand your question, but I believe your assumptions are correct. From the switch's perspective, the packet will be a normal IP packet destined to the remote tunnel endpoint. The original packet will be encrypted and encapsulated within the data portion of this packet. Therefore, the switch would need correct routes for the remote tunnel endpoint (not the remote private subnet) and for your ASA.

Hope that helps.

-Mike

New Member

Re: Incoming NAT rule

Mike,

Ok.  So, would that route be any different when it's encrypted than when it's not?  We have a L2 switch for the inside.  It seems like it cannot handle specific routing.  (I'm still looking at it, but I haven't found anything that leads me to believe it can)  If we were to leave this configuration in place, would it still get traffic to where it needs to go?  I have always been under the assumption that the ASA would decide which traffic was VPN traffic and which was not, and route it accordingly.  (I'm not sure that purchasing a router in place of that switch would actually be the magic bullet here)  We DO have a static route to the outside, using the external switch as a gateway, that I'm starting to consider whether it would be confusing the VPN traffic too.

I notice that there is a "VPN defautl gateway" option in static routes, that might solve the above issue.  However, I'm not sure how you would determine what your VPN gateway is?

Cisco Employee

Re: Incoming NAT rule

Hi Heather,

If the switch is a L2 switch it won't do any routing for you. However, in terms of the routing that is taking place, the IP headers will be routed like any other clear-text IP packet by devices in between the tunnel endpoints.

-Mike

New Member

Re: Incoming NAT rule

Ok, that's exactly what I understood.  They keep talking about the process and how the packets not getting sent the right way.  the fact is, the packets are not getting encrypted, but they are still getting sent the right way.  So to me the problem is about how to get the ASA to properly recognize the VPN traffic and encrypt it.

Thanks again.  I apologize for dragging this thread on and on.  I assume it doesn't help you to have a bunch of open threads, so I can close this out now if that is the case!  (does it work on a "correct answer" basis?)

1043
Views
0
Helpful
25
Replies
CreatePlease to create content