http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968c8.shtml
Scenario: You have a small office or a remote site that does not have an internal domain name server to provide Domain Name System (DNS) resolution. Rather, they are using an external DNS server provided by an Internet Service Provider. The corporate Web site is statically translated via NAT from a private IP address to a publicly reachable IP address on a Cisco ASA firewall.
Requirement: The internal users need to access the corporate Web site, which is located on an internal server.
Default ASA configuration result: The internal users cannot reach their corporate site and the packets are dropped by the ASA.
The root of the issue lies in how the ASA handles DNS resolution.
In this scenario, the internal user attempts to access the corporate Web site. In the process, a DNS query is made for the IP address of the corporate site. This request packet travels through the Cisco ASA, which then rewrites the source address of the packet to its own IP address and forwards the request to the external ISP DNS server.
The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, then rewrites the destination address with the user’s system IP, and forwards the packet to the user system.
The user’s system then attempts to open a HTTP session with the corporate Web site.
Since the IP address of the site has resolved to the public IP, the user’s request packet travels from the inside interface of the ASA, where the ASA builds a connection outbound, to the outside interface. The packet is then dropped by the ASA as it does not allow the packet to return to the inside interface. See Figure A.
By changing one option of the static NAT translation statement, we can tell the ASA to resolve the internal DNS lookup query to the internal WWW server IP address instead of the public IP address.
The original ASA static NAT translation statement was:
The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, and then rewrites both the destination address with the user’s system IP, and the DNS query result to the internal WWW server IP address, before forwarding the packet to the user system. See Figure B.
Go to Configuration | Firewall | NAT Rules. Then highlight the static NAT statement and select Edit. Under the Connection Settings heading, select the option for Translate The DNS Replies That Match The Translation Rule. See Figure C.
This should resolve the issue in a quick, clean, solution. As in most cases though, there is more than one possible solution. We can explore the configuration to allow full hair-pinning in another segment.
Scenario: You have a small office or a remote site that does not have an internal domain name server to provide Domain Name System (DNS) resolution. Rather, they are using an external DNS server provided by an Internet Service Provider. The corporate Web site is statically translated via NAT from a private IP address to a publicly reachable IP address on a Cisco ASA firewall.
Requirement: The internal users need to access the corporate Web site, which is located on an internal server.
Default ASA configuration result: The internal users cannot reach their corporate site and the packets are dropped by the ASA.
The root of the issue lies in how the ASA handles DNS resolution.
In this scenario, the internal user attempts to access the corporate Web site. In the process, a DNS query is made for the IP address of the corporate site. This request packet travels through the Cisco ASA, which then rewrites the source address of the packet to its own IP address and forwards the request to the external ISP DNS server.
The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, then rewrites the destination address with the user’s system IP, and forwards the packet to the user system.
The user’s system then attempts to open a HTTP session with the corporate Web site.
Since the IP address of the site has resolved to the public IP, the user’s request packet travels from the inside interface of the ASA, where the ASA builds a connection outbound, to the outside interface. The packet is then dropped by the ASA as it does not allow the packet to return to the inside interface. See Figure A.
Figure A
Click to enlarge.
This interface transversal is known as hair-pinning. By default, the ASA does not permit hair-pinning. While there is more than one way to resolve this problem, in this case, the easiest solution involves the use of DNS doctoring.By changing one option of the static NAT translation statement, we can tell the ASA to resolve the internal DNS lookup query to the internal WWW server IP address instead of the public IP address.
The original ASA static NAT translation statement was:
static (inside,outside) 172.16.20.200 10.10.10.10 netmask 255.255.255.255The revised static NAT translation statement with the DNS doctoring option enabled:
static (inside,outside) 172.16.20.200 10.10.10.10 netmask 255.255.255.255 dns
Revised DNS process
A DNS query is made for the IP address of the corporate Web site. This request packet travels through the Cisco ASA, which then rewrites the source address of the packet to its own IP address and forwards the request to the external ISP DNS server.The DNS server responds to the ASA query with the public IP address for the corporate Web site. The ASA receives the response, and then rewrites both the destination address with the user’s system IP, and the DNS query result to the internal WWW server IP address, before forwarding the packet to the user system. See Figure B.
Figure B
Click to enlarge.
Making this change is easy to do via the Cisco ASA ASDM interface.Go to Configuration | Firewall | NAT Rules. Then highlight the static NAT statement and select Edit. Under the Connection Settings heading, select the option for Translate The DNS Replies That Match The Translation Rule. See Figure C.
Figure C
Click to enlarge.
Be sure to save your changes!This should resolve the issue in a quick, clean, solution. As in most cases though, there is more than one possible solution. We can explore the configuration to allow full hair-pinning in another segment.
1 comment:
Post a Comment