Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3790
  • Last Modified:

Cisco ASA 5510 - web server

Hi All,

I have a web server set up for public access through our Cisco ASA 5510 (see diagram below)
The web application will only answer to http header requests (URL) that are referenced in the license file.
In this case: http://www.abc-web-server.com (this is used as the example in the diagram)

The outside access to the web server works perfectly.

Trying to access the webserver (using the same URL) from within the network doesnt - this is obviously because traffic cannot leave and then renter the same firewall port - or so it seems...
I have read many example of this being able to happen by using the following command: "same-security-traffic permit" (see web link below)
http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s1_72.html#wp1289167

I have tried this and both variations of the command, aand have not been able to achieve what I am looking for.

Does anyone know which comman if any will alow me to achieve this?
Has anyone else worked with a similar problem? Is there a more simple work around?


Many thanks!

Craig
web-server.PNG
0
chouckham
Asked:
chouckham
  • 7
  • 4
  • 3
  • +3
5 Solutions
 
JasonTracyCommented:
There are two options I know of.  One is the "DNS Rewrite" command.  This is supposed to see outbound DNS requests and rewrite them so the reponse gives the client the internal IP address.  The option for this is a checkbox if using the GUI when you setup the NAT for the webserver.
Here is a link to Cisco that discusses it, they call it "DNS doctoring" here:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml

The other option (the one I use on my network) is to setup the same domain on your internal DNS server, but instead of the public addresses, just put the internal addresses.

Either way, the goal it to give your clients the web server's true internal address instead of its NAT address outside the firewall.
0
 
Pete LongConsultantCommented:
Agree use DNS doctoring

Note this replaced the alias command, you need a to write a Static the WRONG
way round and put the "dns" on the end of the command.

Syntax

static (inside,outside) {Inside IP} {Outside IP} netmask 255.255.255.255 dns


Here is a working example with the equivalent OLD alias command.


Static (inside,outside) 10.254.254.10 123.123.123.123 netmask 255.255.255.255 dns

alias (inside) 10.254.254.10 123.123.123.123 255.255.255.255


or as stated above create a DNS forward lookup zone on your server called abc-web-server.com and create a A (host) record called www that points to the internal IP address of your web server.
0
 
PugglewuggleCommented:
DNS doctoring (aka rewriting) has never worked for me and I've setup lots of these ASAs.
What I always use is a thing called "hairpinning." It is completely transparent and is a much better solutions (in my opinion) than DNS doctoring. Basically, the ASA will re-route traffic based on the public IP in the destination address of a request. What this means is that you can access the internal web/whatever server with it's public IP and the client machines can tell no difference - there is no need to have internal DNS for this either - the hairpinning takes care of it all.
 The only consideration in this would be to assign the server two private IP addresses and use one for requests and the other for management (as the one for requests becomes invisible to inside users once everthing is hairpinned.
Hairpinning is very simple and basically involves only one command:
static (inside,inside) <insert public IP of server here> <insert private IP of server here> netmask 255.255.255.255
Here is a link to the documentation on how to do this, but it's so simple my command should get you up and running!
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#solution2
Cheers! Let me know if you have any questions!
0
New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

 
lrmooreCommented:
dns doctoring only works if your primary dns server is outside your network so that the dns requests actually go through the firewall.
If the web server is in a dmz, the hairpinning won't work either.
If in a dmz, then use two nat statements for d-nat
 static (dmz,outside) <public ip> <private ip> netmask 255.255.255.255
 static (dmz,inside) <public ip> <private ip>  netmask 255.255.255.255

ref:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968c8.shtml


0
 
PugglewuggleCommented:
That's right, good 'ol destination NAT.
However, the question says the server is in the same network as the clients (although the drawing shows it weird). In this case hairpinning on the same interface is the solution to the problem.
Cheers!
0
 
JasonTracyCommented:
While the debate on DNS doctoring vs hairpinning vs destination NAT vs internal DNS is almost like a MAC / PC / Linux debate, I'd like to make my final case for internal DNS entries:

Assuming you already have an internal DNS server, having a private DNS entry for internal web servers is preferable since it does not touch the PIX/ASA at all.  I don't know what volume you currently have, but as best practice, I like to have the fewest devices involved with any network traffic.  If you use internal DNS, the traffic goes right from the client to the server (if the server is on the internal network), or only through the DMZ if it is there.  Hairpinning and destination NAT add more complexity to the PIX confiiguration, and use more CPU since there is more to process.  I'll admit that in most enviroments, the PIX isn't above 10% CPU, so this usually isn't an issue.

However, any time I can get a job done with less CPU used, I tend to prefer that route.
0
 
PugglewuggleCommented:
And I'd like to make my case for hairpinning:
THE reason to too use hairpinning is this: it is completely transparent and requries no other configuration - there is nothing to go wrong and it will work with every host on the specified interface without any configuration or tinkering with DNS, DNS doctoring, rewriting, or any other sort of complication. It... just works. :-)
One command will solve your problem 100%.
Cheers!

static (inside,inside) <insert public IP of server here> <insert private IP of server here> netmask 255.255.255.255

Open in new window

0
 
lrmooreCommented:
Actually, two commands. Can't do hairpinning without this, too:
 same-security-traffic permit intra-interface

Still simple, though.
<8-}

0
 
PugglewuggleCommented:
Indeed! Good call! :)
Cheers!
0
 
chouckhamAuthor Commented:
Hi All,

I appreciate the response on this question! ...some great replies and quite a few good ways of achieving the same result.
I am going try and evaluate them and split the points based on the best results for my situation. Will update the ticket towards the end of the week.

Again thank you!!!

Craig
0
 
Pete LongConsultantCommented:
- Ive learned something myself from this question:) I bookmarked it after the responses but have only just had the chance to revisit and digest both Pugglewuggle and lrmoore's excellent replies.

Its not usually the done thing for a posting expert to ask question in another posters question but it might be relevant to anyone else searching the PAQ (And I don't know the answer :)

Does destination NAT also need a "same-security-traffic permit intra-interface" I'm guessing it should but the Cisco documentation does not have it in the config?

PL
0
 
chouckhamAuthor Commented:
Hi,

Using your example of:

same-security-traffic permit intra-interface
static (inside,inside) <insert public IP of server here> <insert private IP of server here> netmask 255.255.255.255


This would relate to the following with my configuration:

same-security-traffic permit intra-interface
static (inside_core,inside_core) xxx.xxx.xxx.4 172.16.200.50 netmask 255.255.255.255


Should this mean that I should be able to ping xxx.xxx.xxx.4 and get a reply from 172.16.200.50? - currently this doesnt work.
The web address www.mywebapplication.com is set up in DNS to xxx.xxx.xxx.4 when using this url from the internal network, the site is just timing out..

Any ideas?

Thanks,
Craig
0
 
chouckhamAuthor Commented:
Managed to get it working fine with the Inernal DNS Server option.

0
 
chouckhamAuthor Commented:
Hi,

Although i have this working with the internal DNS server, I would like to explore the other options above... Could anyone help me with the ASA "hairpinning"?

Thanks,
-Craig
0
 
JasonTracyCommented:
Should that be reversed?

static (inside_core,inside_core) 172.16.200.50 xxx.xxx.xxx.4  netmask 255.255.255.255
0
 
yogeshrrCommented:
this works fine with PIX firewall version 6.1  with the help of below command
alias (inside) <public-ip> <private-ip> 255.255.255.255
but even i faced problem when we recently migrated PIX to ASA 8.0 now still the problem is there n only i think resolution will be nat dmz ip address of web server to internal IP address and put that entry in internal DNS server and achive this meaning two natings are required.
one to nat DMX Ip of web server to public ip and other to nat DMZ IP of web server to internal IP

thanks,
Yogesh
0
 
PugglewuggleCommented:
Can you please post a config chouckham?
0
 
yogeshrrCommented:
u mean PIX config?
0
 
lrmooreCommented:
Where you been, pug?
0
 
PugglewuggleCommented:
Lol busy as imaginable! The economy is crazy and I'm chasing contracts and jobs trying to keep up!

Yes, a PIX config.
0
 
yogeshrrCommented:
hi ,u can see the attached file pl let me also know what is the work arround with this issue as in new setup we are doing patting with same internal IP we cant put duplicate entry using alias command so i think dats a limitation now.
pix.txt
0
 
PugglewuggleCommented:
Just a quick question: have you tried the Cisco PIX 6.x to ASA 7 or 8.x migration tool? It's pretty good for getting the configuration translated between devices.

http://www.cisco.com/pcgi-bin/tablebuild.pl/pix
0

Featured Post

Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

  • 7
  • 4
  • 3
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now