04-05-2006 01:19 AM - edited 02-21-2020 02:21 PM
I have what I think is a simple scenario but I can't find a way to implement a solution.
I have the following:
VPN Clients<->CiscoPix506e<->Cisco3000
The VPN clients run a IPSEC VPN to the Cisco PIX 506e and can access it's "internal network" just fine.
The Cisco pix runs a VPN to another company where all network traffic is nat'ed to a single RFC1918 IP address before going out of the tunnel (requirement of the other company to avoid address overlap issues)
and everyone on the "internal network" can access that VPN just fine.
I want people using the VPN client to be able to access the other VPN. I think that the forced NAT to the external company VPN is a problem.
All examples for VPN to VPN transversal I see specify that NAT must be disabled along the entire path. I can't do that in this situation. Is it possible to make this work?
I'm guessing with one good ACL statement all my problems will be solved.
I've attached a PDF example network diagram to help explain the situation.
Networks Address' of each are the following (real address's change to protect the innocent :) ):
VPNCLIENTS
192.168.10.0/24
Internal Network
192.168.1.0/24
External VPN End point
192.168.20.0/24
Address used for NAT on VPN
172.16.1.1/32
relevant IOS config
ip local pool VPN-CLIENTS 192.168.10.1-192.168.10.254
access-list inside permit ip any any
access-list NONAT permit ip 192.168.1.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list EXTERNAL-ACL-VPN permit ip host 172.16.1.1 192.168.20.0 255.255.255.0
access-list EXTERNAL-ACL-NAT permit ip 192.168.1.0 255.255.255.0 192.168.20.0 255.255.255.0
ip address outside a.b.c.d 255.255.255.0
ip address inside 192.168.10.1 255.255.255.0
global (outside) 2 interface
global (outside) 1 172.16.1.1
nat (inside) 0 access-list NONAT
nat (inside) 1 access-list EXTERNAL-ACL-NAT 0 0
nat (inside) 2 0.0.0.0 0.0.0.0 0 0
access-group outside in interface outside
route outside 0.0.0.0 0.0.0.0 a.b.c.d 1
04-05-2006 01:58 AM
Just a quick question and correct me if I'm mis-understanding your post.
Why can't your VPN client users just connect directly to the c3000 concentrator to access the external company??
04-05-2006 02:07 AM
04-05-2006 03:00 AM
Mainly for cost, maintenance, and speed of deployment, reasons. The staff connecting are using xauth and tokens (authing off an internal radius server) to log in. That functionalty and level of control isn't available through the "external vpn" company.
Staff currently have to RDP into the company's internal network, and then launch a browser (inside their RDP session) to access the external VPN applications. I would prefer a more seamless experience for the end user.
My desired solution would mean the end user only needed one VPN session that would allow access to the internal network and external VPN at the same time. Slighter easier user experience.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: