Solved: Re: Incoming NAT rule - Page 2

heather.burke · ‎10-19-2010

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.

heather.burke · ‎10-28-2010

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!

mirober2 · ‎10-28-2010

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

heather.burke · ‎10-29-2010

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

mirober2 · ‎10-29-2010

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

heather.burke · ‎10-29-2010

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!

mirober2 · ‎10-29-2010

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

heather.burke · ‎11-01-2010

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!

mirober2 · ‎11-01-2010

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

heather.burke · ‎11-01-2010

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?

mirober2 · ‎11-01-2010

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

heather.burke · ‎11-01-2010

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?)