Pix/ASA: DNS rewrite and Packet U-Turns part II

Network

Internet----(outside)pix/asa(inside)----client
                    (dmz)
                      I
                      I
                    server

Now let's consider a pix/asa with three interfaces: inside, outside and dmz. Client PC in the inside network cannot access the server in the dmz eventhough we have the correct nat configuration in the firewall. We soon found out that the client PC is resolving server's hostname to its public ip. Problem is the pix/asa will forward the packet to the outside interface because the destination in the packet header is the server's public ip.

Solution 1:
DNS doctoring to the rescue

global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
static (inside,dmz) 192.168.100.0 192.168.100.0 netmask 255.255.255.0
static (dmz,outside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255 dns

By adding the dns keyword in the static nat for the server, we are telling the pix to rewrite the dns query response so that the client pc will resolve the server's hostname to its private ip. So then the pix will correctly route to the dmz interface when client PC sends a packet to the server.
Make sure that you have DNS inspection configured for DNS Doctoring to work.

policy-map global_policy
class inspection_default
...
inspect dns

Solution 2:
Another way to get around the problem is to configure the pix to do a nat translation for packets from inside hosts going to the server in the dmz. But instead of natting the source address in the packet header, we tell it to nat the destination address.

!
! Nat for inside-to-outside traffic
!
global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Nat for inside-to-dmz traffic to server
!
static (inside,dmz) 192.168.100.0 192.168.100.0 netmask 255.255.255.0
!
! Nat for dmz-to-outside traffic to server
!
static (dmz,outside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255
!
! Destination Nat for the server's IP
!
static (dmz,inside) 172.20.1.10 10.10.10.10 netmask 255.255.255.255


More detailed info from the Cisco sample configuration.

Pix/ASA: DNS rewrite and Packet U-Turns part I

Topology

                                    I--Client
Internet----(Outside)ASA(Inside)----I
                                    I--Server

Problem

An internal host cannot reach the a public server in the DMZ arm of the pix/asa. The reason is because the public server's hostname is resolved by DNS to its public ip address and the pix/asa will not route a packet to the outside interface then u-turn it back to its inside interface.

Solution 1: We tell the pix/asa to hack into the DNS query response such that the client host will resolve the server's hostname to it's private ip address.
Make sure that you have DNS inspection configured for DNS Doctoring to work.

policy-map global_policy
class inspection_default
...
inspect dns

! Nat/Global for outbound traffic
!
global (outside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Static nat for inbound traffic to the server.
! The DNS keyword at the end enables DNS Doctoring
!
static (inside,outside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255 dns
!

It beats going to each and every workstation on your network and adding the server's hostname/ip address in their etc/hosts file.

Solution 2.
On pre-7.2 verion of the security appliance software, the pix/asa will not forward clear (unencrypted) traffic back the same interface where it was recieved from. On 7.1, it will allow the packet to take a U-turn but only for encrypted traffic.
So if the firewall is running 7.2 software, we can get around these limitations and allow the client host to access the server using the resolved public ip address.

! To allow packet U-turn
!
same-security-traffic permit intra-interface
!
! global statement for outbound traffic
!
global (outside) 1 interface
!
! global statement for intra-interface traffic
!
global (inside) 1 interface
nat (inside) 1 192.168.100.0 255.255.255.0
!
! Static nat for inbound traffic
!
static (inside,outside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255
!
! To map the public ip of the server to its private ip
! for intra-interface traffic.
!
static (inside,inside) 172.20.1.10 192.168.100.10 netmask 255.255.255.255
!

For a more detailed explanation, read this sample configuration from Cisco.

Router: Surfing without Split-tunnelling

Scenario: Users connect remotely via Cisco VPN client. They connect to your router. They need to access the Internet while logged-in but you don't want to configure split-tunnelling. You want the VPN client to access the internet thru the router and not by split-tunneling so that you can later enable url-filtering or use audit-trail to monitor their browsing activities.
Config:

username cisco password cisco123
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local
!
crypto isakmp policy 3
encr 3des
authentication pre-share
group 2
!
crypto isakmp client configuration group RAS
key cisco123
domain cisco.com
pool ippool
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto dynamic-map dynmap 10
set transform-set myset
!
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
! User's traffic will be redirected to this loopback interface
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip nat inside
!
interface Ethernet0/1
ip address 192.168.20.1 255.255.255.0
ip nat inside
!
interface Ethernet0/0
...
ip nat outside
ip policy route-map redir

crypto map clientmap
!
ip local pool ippool 192.168.1.100 192.168.1.200
ip nat inside source list NAT interface Ethernet0/0 overload
!
ip access-list extended NAT
deny ip 192.168.20.0 0.0.0.255 192.168.1.0 0.0.0.255
permit ip 192.168.20.0 0.0.0.255 any
permit ip 192.168.1.0 0.0.0.255 any
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
!
! This route map redirects vpn client traffic to Loopback0
!
route-map redir permit 10
match ip address 101
set interface Loopback0



On the pix/asa, check this sample configuration from Cisco for a similar "vpn-on-a-stick" setup.