08-18-2011 05:47 AM - edited 03-11-2019 02:13 PM
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.
Solved! Go to Solution.
08-24-2011 09:24 PM
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
access-list cap permit ip host
access-list cap1 permit ip host
access-list cap1 permit ip 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
08-18-2011 05:55 AM
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
08-18-2011 05:59 AM
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
08-24-2011 05:53 AM
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?
08-24-2011 06:01 AM
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
08-24-2011 05:09 PM
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
08-24-2011 09:24 PM
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
access-list cap permit ip host
access-list cap1 permit ip host
access-list cap1 permit ip 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
08-24-2011 11:02 PM
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
08-24-2011 11:15 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide