cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
438
Views
1
Helpful
3
Replies

VPN client passthrough problem

jmatser
Level 1
Level 1

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

3 Replies 3

jmia
Level 7
Level 7

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??

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.

Getting Started

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: