05-03-2012 11:41 AM
I've spent several days trying to make the following architecture working, but without success.
We need to create a two-layer VPN system.
In a word, I've my customer accessing to a dedicated VPN, where our solutions are accessible (we'll call it "Public VPN", a nosense, I know)
We would like also to use the same VPN to get an access to a secondary VPN, where our devel team might have access to a set of private resources (the so called "private VPN").
The architecture should be something similar to:
An hub-and-spoke configuration doesn't fit our requirements, because we need a second authentication, once accessed the public VPN, to gain the access to the private one.
Said that, is that possible?
We spent a lot of time trying to access (launching a second VPN client) the private network after having obtained the connection to the public one, but it looks like that IKE is not able to start Ph1 when accessing to the VPN gateway located in the public VPN.
05-03-2012 05:00 PM
05-04-2012 02:14 AM
you're right, I gave you too few details to ask for a suggestion, so, that's the configuration we're using:
VPN gateway for public-VPN : Netscreen 5gt
VPN gateway for private-VPN: Netscreen 5gt
VPN (both) traffic routing: Policy based
Dial-up client: Software client (we're using the client from Shrew soft).
IKE/IPSec (both VPNs): IKE v1, XAuth, Pre.shared keys, aggressive mode, Traversal NAT enabled, G2, SHA, ESP,AES128.
Public-VPN subnetwork: 10.5.0.0/24 (the IPs assigned to "local" hosts)
Public-VPN IP-Pool: 10.9.0.0/24 (the IPs assigned to the "tunneled" hosts)
Public-VPN Policy (untrust-to-trust and vice versa): 10.5.0.0/24 <-> Dial-Up VPN, Tunnel
Client Conf for Public VPN (aka, Public client): Virtual adapter, same Ph1/Ph2 conf of VPN, SA: 10.5.0.0/24, destination address: the public address of the first gateway untrust interface (e.g. 184.108.40.206)
Private-VPN subnetwork (trust-zone): 10.6.0.0/24 (the IPs assigned to "local" hosts)
Private-VPN IP-Pool: 10.8.0.0/24 (the IPs assigned to the "tunneled" hosts)
Private-VPN Policy (untrust-to-trust and vice versa): 10.6.0.0/24 <-> Dial-Up VPN, Tunnel
Private-VPN Untrust Interface Address: 10.5.1.1
Client Conf for Provate VPN (aka, Private client): Virtual adapter, same Ph1/Ph2 conf of VPN, SA: 10.6.0.0/24, destination address. 10.5.1.1 (inside the public-VPN subnetwork trust-zone)
We can successfully connect to Public VPN from a dial-up user, and able to ping on the second gateway (10.5.1.1). (Using public client conf).
We can successfully connect to private VPN from a machine inside the subnet 10.5.0.0/24 (Using private client conf.)
Once connected to the public VPN, when pinging on 10.5.1.1, we see ICMP traffic logged by the public-vpn policy.((10.5.0.0/24 <-> Dial-Up VPN, Tunnel)
When trying to launch the private-client, after the connection to the public VPN, we see that the traffic generated for Ph1 is routed (on the client machine) through the right SA: 10.9.0.2 --> 10.5.1.1
(10.9.0.2 is the client address in the public VPN and 10.5.1.1 is the untrust interface of the private gateway)
Nevertheless, the public-vpn policy doesn't log any traffic, neither Ph1 is accomplished (time-out).
So, in terms of subnetwork addresses, the architecture is the following:
10.6.0.0/24-----[10.6.0.1, gateway, 10.5.1.1]------(10.5.0.0/24)----[10.5.0.1, gateway,220.127.116.11]-----internet-----[PubClient,10.9.
05-04-2012 03:24 AM
Hi I had a similar problem myself back in February and had a case open with JTAC for weeks.
I think this is called back-to-back vpn.
I tried with policy-based vpn's at first without success and had to use route-based vpn's.
Route based dial-up vpn and a route based site-to-site vpn.
Two tunnel interfaces needed to be created.
Two routes using the two tunnels
I also needed an untrust-to-untrust intrazone policy from the IP pool to the customer subnet and a DIP was needed on this policy.
Maybe this kb might help:
05-04-2012 10:43 AM
Hi Stac Polaidh,
thanks for your suggestion, I'll try your solution asap.
But, let me understand better what's your idea.
The two tunnel interfaces are required on the outer gateway, or the first one on the "outer" and the second one on the "internal"?
Where the two routes should start and "aim" ?
The untrust-to-untrust policy was required to allow the two tunnels communicating?(in that case, "untrust" is referred to the internal VPN?)
The dial-up vpn was configured for the "outer" VPN (user-to-external VPN), while site-to-site was to tunnel the external static ip of the user (taken from the outer VPN IP-pool) to the internal VPN?
I know, a lot of question, sorry.
Thanks for your help,
05-08-2012 01:45 AM
I have two tunnels on the same firewall router.
One tunnel used by the route-based site to site vpn like so:
for me this is tunnel.1 between 10.22.226.40/29 (our internal subnet) and 10.42.0.0/14 (client subnet)
I also had to create a DIP on tunnel.1 using 10.22.226.43 which needs to be used in the policy
Another tunnel was created tunnel.2 used by the dial-up route-based vpn like so:
You have to make sure that the proxy ID is where you want it to go to, for me the proxy ID is the client subnet 10.42.0.0/14 for the route-based vpn (and this proxy id has to be used in the shrewsoft vpn client)
The policy is to allow the traffic through, it is between the IP pool and the clients off site network.
As the IP pool (10.77.77.0/27) is in the untrust zone and the clients network as well it is an intrazone untrust to untrust.policy. This is what I needed
set policy id 149 from "Untrust" to "Untrust" "10.77.77.0/27" "10.42.0.0/14" "ANY" nat src dip-id 4 permit log
I do not believe you will be able to do this using policy-based vpn and I read many posts confirming this belief.
You need to make sure your routing works and the traffic is allowed through by the policy.
I hope this helps.
06-13-2012 02:30 PM
thanks for your help, I finally implemented a route-based vpn(don't know it initially looked to me more difficult than the policy version, I was wrong).
I also discovered that the very issue was the VPN client (Shrewsoft).
At the end, I got an equivalent behaviour using the work-home port configuration; the "dmz" vpn in the home zone and my "very private" vpn in the work zone, a bunch of routing policies and that's it...
Thanks for your help!