ASA NAT Into VPN Tunnel

This scenario is sometimes needed when connecting via VPN to a 3rd party & a requirement is that IP addressing is unique. In this example a server (192.168.0.10) behind the ASA should be NATed to a public IP address (1.2.3.4) when communicating across the VPN, but PATed to the outside interface when communicating with the Internet. The local network is 192.168.0.0/24 & the remote network 172.16.0.0/24.


interface Ethernet0/0
 nameif inside
 security-level 100
 ip address 192.168.0.1 255.255.255.0
!
interface Ethernet0/1
 nameif outside
 security-level 0
 ip address 100.64.0.1 255.255.255.252
!
object network SERVER-INSIDE
 host 192.168.0.10
!
object network SERVER-NAT-IP
 host 1.2.3.4
!
object network REMOTE-NETWORK
 subnet 172.16.0.0 255.255.255.0
!
access-list VPN-TUNNEL extended permit ip object SERVER-NAT-IP object REMOTE-NETWORK
!
object network NAT-LAN
 subnet 192.168.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
nat (inside,outside) source static SERVER-INSIDE SERVER-NAT-IP
destination static REMOTE-NETWORK REMOTE-NETWORK
!
crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac
crypto map OUTSIDE_MAP 10 match address VPN-TUNNEL
crypto map OUTSIDE_MAP 10 set peer 100.64.1.1
crypto map OUTSIDE_MAP 10 set ikev1 transform-set AES256-SHA
crypto map OUTSIDE_MAP interface outside
crypto isakmp identity address
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
!
tunnel-group 100.64.1.1 type ipsec-l2l
tunnel-group 100.64.1.1 ipsec-attributes
 ikev1 pre-shared-key Password123

The key is to use twice NAT so that the 192.168.0.10 address gets NATed only when destined for 172.16.0.0/24. The interesting traffic ACL for the tunnel then covers the 1.2.3.4 public IP address & the VPN will establish with traffic NATed in & out of it. Alternatively if we wanted the 192.168.0.10 address NATed to 1.2.3.4 at all times we could just use object NAT instead:

object network NAT-SERVER
 host 192.168.0.10
 nat (inside,outside) static SERVER-NAT-IP

Kludging NAT for Communications Manager SIP Trunks

Ideally when using a SIP trunk to an external provider for PSTN connectivity with Communications Manager you'd use a Unified Border Element (UBE) in media flow-through mode to handle SIP to SIP inter-working & present a single IP address for NATing on your Internet router. But what happens when the customer is too cheap to pay for a UBE? Well if the SIP trunk requires registration or the SIP headers formatting in a way the CUCM doesn't like then you're out of luck! Otherwise you can kludge an IOS router into handling the NATing to a single IP address.
The problem stems from the fact that unless you enable "MTP required" Communications Manager handles a SIP trunk like an UBE in media flow-around mode - it handles protocol inter-working but the RTP audio streams pass directly between endpoints. This means that you have to NAT port 5060 to the CUCM server for the SIP traffic, but also NAT the phone's subnet too. Even if you do enable using an MTP, with multiple servers there could be multiple MTPs with different IP addresses.
The configuration below works assuming your IP address for NAT is 1.2.3.4, the CUCM server is 10.1.1.2, the phones reside in the 10.1.1.0/24 network & the SIP trunk is 4.3.2.1:

ip inspect name FIREWALL tcp
ip inspect name FIREWALL udp
ip inspect name FIREWALL sip
!
interface FastEthernet0
 description Outside interface
 ip address 1.2.3.1 255.255.255.248
 ip access-group OUTSIDE_IN in
 ip nat outside
 ip inspect FIREWALL in
 ip inspect FIREWALL out
interface FastEthernet1
 description Inside interface
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
!
ip access-list extended OUTSIDE_IN
 permit tcp host 4.3.2.1 host 1.2.3.4 eq 5060
 permit udp host 4.3.2.1 host 1.2.3.4 eq 5060
 deny   ip any any log
access-list 2 remark Voice subnet
access-list 2 permit 10.1.1.0 0.0.0.255
!
ip nat pool phones 1.2.3.4 1.2.3.4 netmask 255.255.255.252
ip nat inside source list 2 pool phones overload
ip nat inside source static udp 10.1.1.2 5060 1.2.3.4 5060 extendable

This kludge works as we've done a static port NAT to the CUCM server & allowed it in the access-list, this allows call control messages in & out. The SIP inspect punches holes in the access-list to allow the RTP inbound (outbound is allowed anyway). The SIP NAT ALG (application layer gateway) fixes the SIP headers to have the right IP addresses & port numbers. You can confirm this via show ip nat translations which shows the phone's being NATed as well as the CUCM server:

Pro Inside global   Inside local          Outside local   Outside global
udp 1.2.3.4:5060    10.1.1.2:5060         4.3.2.1:5060    4.3.2.1:5060
udp 1.2.3.4:5060    10.1.1.2:5060         ---                   ---
udp 1.2.3.4:32366   10.1.1.21:32366       4.3.2.1:30118   4.3.2.1:30118
udp 1.2.3.4:32367   10.1.1.21:32367       4.3.2.1:30119   4.3.2.1:30119
udp 1.2.3.4:26642   10.1.1.24:26642       4.3.2.1:21068   4.3.2.1:21068
udp 1.2.3.4:26643   10.1.1.24:26643       4.3.2.1:21069   4.3.2.1:21069
udp 1.2.3.4:19462   10.1.1.26:19462       4.3.2.1:31900   4.3.2.1:31900
udp 1.2.3.4:19463   10.1.1.26:19463       4.3.2.1:31901   4.3.2.1:31901
udp 1.2.3.4:29940   10.1.1.26:29940       4.3.2.1:20970   4.3.2.1:20970
udp 1.2.3.4:29941   10.1.1.26:29941       4.3.2.1:20971   4.3.2.1:20971
udp 1.2.3.4:25306   10.1.1.28:25306       4.3.2.1:25398   4.3.2.1:25398
udp 1.2.3.4:25307   10.1.1.28:25307       4.3.2.1:25399   4.3.2.1:25399