Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'd successfully configured an IPSEC VPN as per this question:-

How to disable dns doctoring for IPSEC VPN connections for ASA 5510

However I ran into the problem that remote users are often on a home network on the 192.168.x.x range and therefore this conflicts with a vpn that joins them to another 192.168.x.x.

So having googled the problem I found this article which exactly explains my problem, and a potential solution:-

http://nimlabs.org/~nim/dirtynat.html

But it's not for a cisco ASA.

So for my VPN:-


                10.1.0.x
                    |
                   dmz
                    |
192.168.0-15.x  ------- nat ----- outside-2 10.1.96-111.x
inside --- [cisco asa 5510] -- outside 91.x.x.x
                                 |
                                 |allocated 10.1.120.x
                                 |  
                                 |
                              [cisco vpn client] (potentially on 
                                                   192.168.x.x)

Cisco Nat rules to disable natting for VPN pool to the inside and dmz interfaces, but keep apply nat to outbound internet connections.

access-list inside_nat0 extended permit ip 192.168.0.0 255.255.240.0 10.1.16.0 255.255.252.0 
access-list inside_nat0 extended permit ip 10.1.120.0 255.255.255.0 192.168.0.0 255.255.240.0 
access-list inside_nat0 extended permit ip 192.168.0.0 255.255.240.0 10.1.120.0 255.255.255.0 
access-list outside_nat0 extended permit ip 10.1.16.0 255.255.252.0 192.168.7.0 255.255.255.224 
access-list outside_nat0 extended permit ip 10.1.120.0 255.255.255.0 10.1.16.0 255.255.252.0 
access-list outside_nat0 extended permit ip 10.1.16.0 255.255.252.0 10.1.120.0 255.255.255.0 
access-list outside_nat0 extended permit ip 10.1.120.0 255.255.255.0 192.168.0.0 255.255.240.0 
access-list outside_nat0 extended permit ip 192.168.0.0 255.255.240.0 10.1.120.0 255.255.255.0 
access-list dmz_nat0 extended permit ip 10.1.120.0 255.255.255.0 10.1.16.0 255.255.252.0 
access-list dmz_nat0 extended permit ip 10.1.16.0 255.255.252.0 10.1.120.0 255.255.255.0 
nat (inside) 0 access-list inside_nat0
nat (inside) 1 0.0.0.0 0.0.0.0
nat (outside) 0 access-list outside_nat0
nat (outside) 2 10.1.120.0 255.255.255.0
nat (dmz) 0 access-list dmz_nat0
nat (dmz) 2 0.0.0.0 0.0.0.0

global (outside) 1 91.x.x.x
global (outside) 2 91.x.x.x
global (dmz) 3 10.1.19.1

So my attempt to get this method to work was to create a virtual interface on the outside network with a static nat mapping the unusual 10.1.96.0/20 to our regular internal 192.168.0.0/20.

interface Ethernet0/1.116
 vlan 116
 nameif outside-2
 security-level 0
 ip address 10.1.96.1 255.255.240.0 
!

static (inside,outside-2) 10.1.96.0 192.168.0.0 netmask 255.255.240.0 dns tcp 1000 100 udp 1000

Output from show route:-


Gateway of last resort is 91.x.x.x to network 0.0.0.0

C    10.1.16.0 255.255.252.0 is directly connected, dmz
C    10.1.96.0 255.255.240.0 is directly connected, outside-2
S    10.1.120.2 255.255.255.255 [1/0] via 91.x.x.x, outside
C    10.254.10.0 255.255.255.252 is directly connected, FOCtrlIntf
C    91.x.x.x 255.255.255.0 is directly connected, outside
S*   0.0.0.0 0.0.0.0 [1/0] via 91.208.x.x, outside
C    192.168.0.0 255.255.240.0 is directly connected, inside

However this doesn't appear to work. My guess is that somehow nat isn't being applied once I'm connected to the vpn, but I'm sure other people must have this same problem and the solution of renumbering our internal lan is definitely a last resort!

share|improve this question
add comment

1 Answer

Allocate them an IP from the 172.16.0.0/12 range?

share|improve this answer
    
The problem is that the user's home network is in the 192.168.x.x/16 range, so pushed routes for networks in that /16 may cause the VPN user to lose their route to the internet and thus the VPN as a whole. It doesn't matter a whole lot what IP the VPN server gives them. –  sysadmin1138 Jul 20 '11 at 11:45
    
Thanks for your contribution both, if you look at the diagram the allocated range is 10.1.120.x so this won't conflict with users home networks. –  gilesw Jul 20 '11 at 14:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.