cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8246
Views
0
Helpful
8
Replies

ASA 8.3/4 NAT help

rscho
Level 1
Level 1

Hi Forum,

I'm having a cow of a time trying to implement a NAT configuration after having upgraded our ASA5510 recently from IOS 8.2 to 8.4. The upgrade went fine, however we now have a need to add a new NAT rule and I'm not sure whether it's possible.

The upgraded NAT rule and access list works fine at allowing external access to a web server.

access-list 100 extended permit tcp any object obj-WebServer eq http

nat (INSIDE,outside) source static obj-WebServer interface service obj-tcp-source-eq-80 obj-tcp-source-eq-80

access-group 100 in interface outside

However we now need to NAT the SOURCE address (either to a pool or single address) of incoming http requests before forwarding the request to the server. Hence the server will see all requests as originating from a pool with a route heading back to the ASA. The basic issue is that the severs default gateway does not return to the ASA, so "tagging" the source address of external requests to an address or interface associated with the ASA should allow the server to return the traffic to the ASA. I know we shouldn't be doing it this way but we can't see any alternative.

Having read a huge amount of examples we can access the server with the above config (or Object NAT), and we can NAT incoming traffic, however we can't combine the two by having all external http requests Source Natted before forwarding to the server.

Any help would be much appreciated.

1 Accepted Solution

Accepted Solutions

Hi Rudi,

As per your statement:

is "match requests from any source IP with destination port 80 and destination IP=External Interface IP and change (NAT) the source IP to the Inside interface, the destination IP to obj-WebServer and leave the destination port=80".

The untranslate rule should then restore the original source IP so that traffic can return to the originating host.

The only reason I can see why "service obj-tcp-source-eq-80 obj-tcp-source-eq-80" fails to match any traffic is that the ASA is looking at the original packets source port, which could be anything, rather than it's destination port of 80. But that wouldn't make any sense!

The first part is correct as per your understanding, but not the second part. The first port is for the public ip and the second is for the private ip, so logically both are the destination ports for the reqwuest coming from the client.

I would request you to check that the service object configuration should be this:

object service obj-tcp-source-eq-80

  service tcp destination eq 80

and also could you add the following ACL:

access-list 100 extended permit tcp any object obj-WebServer eq www

It should definitely work, I do not see any reason why it shouldn't.If it still doesnt work then I would say taking caoptures and logs is the right way to go. Just to check if the request hits the outside interafce on port 80 only?? and if it is getting tarnslated correctly??

These shoudl be your correct capture commands:

access-list cap permit ip host host

access-list cap permit ip host host

access-list cap1 permit ip host host

access-list cap1 permit ip host host

cap capin access-list cap1 interface INSIDE

cap capout access-list cap interface outside

and then try connecting and take the output of "show cap capin" and "show cap capout"

Let me know what are the results of these 3 steps. Please follow them in the same order.

Thanks,

Varun

Thanks,
Varun Rao

View solution in original post

8 Replies 8

varrao
Level 10
Level 10

Hi Rudi,

Here's you're solution:

nat (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service service obj-tcp-source-eq-80 obj-tcp-source-eq-80

Let me know if this resolves it.

Thanks,

Varun

Thanks,
Varun Rao

Sorry I should've given the example as well,

In the below nat statement:

nat  (outside,INSIDE) source dynamic any interface destination static  interface obj-WebServer service service obj-tcp-source-eq-80  obj-tcp-source-eq-80

the traffic coming from outside would be dynamically patted to your inside interface and the destination for outside users is your outside interface, which would get untarnslated to your server private ip. You can use any other IP address as well instead of inside interface, I just picked up this nat statement as a reference.

Thanks,

Varun

Thanks,
Varun Rao

rscho
Level 1
Level 1

Thanks for your suggestion Varun,

In order for you suggestion to match any traffic I have to modify it like so:

nat  (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service any obj-tcp-source-eq-80

It then successfully NATs incoming traffic to the inside interface and forwards it to the server. Unfortunately it also causes other outbound network services to fail because I presume all return traffic is caught by the any statement in the inbound NAT rule. Using "show NAT" I can see the default outbound NAT translating hits increasing but no corresponding untranslate hits. At the same time the untranslate hits for the inbound rule is increasing with no change to the translate hits. So the same traffic appears to be translated & untranslated by two different NAT rules.

I don't know why the original "service obj-tcp-source-eq-80  obj-tcp-source-eq-80" statement doesn't match any traffic but it seems it failure to is the problem.

Any other suggestions?

Hi Rudi,

I am not really sure why you ahve this nat statement:

nat  (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service any obj-tcp-source-eq-80

because this doesn't look right to me, what the above nat statement means is , request coming from outside on the outside interface on any port shpould be translated to port 80 on the webserver, so even if the request is cvoming for port 22 on the outside interface shoudl be directed to port 80 on webserver. So this should not be the case. In 8.3 nat, with the ability to nat both source and destination, also makes it very necessary to be very specific in your source and destination, so that it does not fall into any other nat statement.

Can you tell me what happens if you use:

nat  (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service obj-tcp-source-eq-80 obj-tcp-source-eq-80

What this means is, if siomeone tries to access your webserver with the public ip, then it would be forwarded to port 80 only on real ip of the webserver.

Can you tell me what hap[pens if you use the above nat statement???

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

We're using ASA 8.4(2) if that makes any difference.

If I use

nat (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service obj-tcp-source-eq-80 obj-tcp-source-eq-80

then no external connections to obj-WebServer to are successful. Executing "show NAT" I can see the following

Manual NAT Policies (Section 1)

1 (outside) to (INSIDE) source dynamic any interface   destination static interface obj-WebServer service obj-tcp-source-eq-80 obj-tcp-source-eq-80

    translate_hits = 0, untranslate_hits = 35

Auto NAT Policies (Section 2)

1 (INSIDE) to (outside) source dynamic obj_any interface 

    translate_hits = 12, untranslate_hits = 12

So in Section 1 somehow untranslate hits are occuring but no translate hits.

On syslog I see access denied messages from external browser to the EXTERNAL ASA address

Source IP             Source Port          Destination IP               Destination Port

111.111.111.111     38057                    ExternalIP                         80

so it appears NO translation from ExternalIP to obj-WebServer is occurring.

If I change the NAT rule to

nat (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service any obj-tcp-source-eq-80

then I immediately see translate hits and external traffic can reach obj-WebServer. Of course because I am now grabbing inbound traffic destined for ANY port and NATing to obj-WebServer other outbound traffic fails.

My understanding of the statement

nat (outside,INSIDE) source dynamic any interface destination static interface obj-WebServer service obj-tcp-source-eq-80 obj-tcp-source-eq-80

is "match requests from any source IP with destination port 80 and destination IP=External Interface IP and change (NAT) the source IP to the Inside interface, the destination IP to obj-WebServer and leave the destination port=80".

The untranslate rule should then restore the original source IP so that traffic can return to the originating host.

Is that correct?

The only reason I can see why "service obj-tcp-source-eq-80 obj-tcp-source-eq-80" fails to match any traffic is that the ASA is looking at the original packets source port, which could be anything, rather than it's destination port of 80. But that wouldn't make any sense!

As always any ideas are appreciated

Hi Rudi,

As per your statement:

is "match requests from any source IP with destination port 80 and destination IP=External Interface IP and change (NAT) the source IP to the Inside interface, the destination IP to obj-WebServer and leave the destination port=80".

The untranslate rule should then restore the original source IP so that traffic can return to the originating host.

The only reason I can see why "service obj-tcp-source-eq-80 obj-tcp-source-eq-80" fails to match any traffic is that the ASA is looking at the original packets source port, which could be anything, rather than it's destination port of 80. But that wouldn't make any sense!

The first part is correct as per your understanding, but not the second part. The first port is for the public ip and the second is for the private ip, so logically both are the destination ports for the reqwuest coming from the client.

I would request you to check that the service object configuration should be this:

object service obj-tcp-source-eq-80

  service tcp destination eq 80

and also could you add the following ACL:

access-list 100 extended permit tcp any object obj-WebServer eq www

It should definitely work, I do not see any reason why it shouldn't.If it still doesnt work then I would say taking caoptures and logs is the right way to go. Just to check if the request hits the outside interafce on port 80 only?? and if it is getting tarnslated correctly??

These shoudl be your correct capture commands:

access-list cap permit ip host host

access-list cap permit ip host host

access-list cap1 permit ip host host

access-list cap1 permit ip host host

cap capin access-list cap1 interface INSIDE

cap capout access-list cap interface outside

and then try connecting and take the output of "show cap capin" and "show cap capout"

Let me know what are the results of these 3 steps. Please follow them in the same order.

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

You've solved the problem! Following your suggestion I checked the obj-tcp-source-eq-80 object and found it defined as:

object service obj-tcp-source-eq-80

  service tcp source eq 80

The object was created using ASDM some time ago and I'm not sure of the original purpose. When creating the new NAT rule I obviously only read the 80 part of the name and blindly assumed the object was what I needed. When I saw you suggestion above the penny dropped.

I've since tested the rule and it works as expected. It's reassuring that my knowledge of NAT isn't completely screwed up and that I've just made a stupid mistake.

Thanks for your patience, perserverence and for taking the time to share some of your considerable knowledge with others.

Regards,

Rudi

Glad to know it worked....The "any" key word working, just lit the bulb in my head . Let me know if you face any other issues.

Thanks,

Varun

Thanks,
Varun Rao
Review Cisco Networking for a $25 gift card