• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1114
  • Last Modified:

How to create a VPN connection to 2 zones in Juniper SSG20?

We've finally setup a VPN connection from a remote location to the HQ. At the HQ, we're using Juniper SSG20, and it has several zones in it. But the ones we need help with is as follows:
1. Local Zone in Trust-vr (50.0.0.0)
2. DMZ in Untrust-VR (51.0.0.0)
3. Internet zone in Untrust-VR (static public IP)

So from the remote location, we've set a VPN to the Local Zone. It's working like a charm. But we needed users to access the DMZ zones too, if possible using the vpn and not directly from the internet.

So far we've learned that this can be done only using policy based routing. But we're using Routing based routing (???) since it was supposed to be safer. Is this true? Is there anything we can do about this?

The vpn we've setup is a site-to-site route based vpn.

0
SW111
Asked:
SW111
  • 2
  • 2
1 Solution
 
SW111Author Commented:
Adding points per Expert Exchange email instruction.
0
 
deimarkCommented:
In short, yes you can do this.

If you are using route based VPNs on each side, as long as the routes for the mreote nets go via the tunnel inteface, it will be all good.

The only caveat to this is if you have any proxy ID info configured (normally not needed between 2 junipers in route based VPNs).

If you do have a proxy ID enabledon eaither side, then you can create another autokey ike (phase2) set up and bind to either the same tunnel or a new one.

Juniper tends to lock down the proxy IDs of each side quite well, so if you need a VPN to go to more than 1 net, then use policy based VPNs or multiple autokey ikes
0
 
SW111Author Commented:
Sorry Deimark, I'm not 100% clear on what I'm supposed to do.

We're actually using an SSG and a Linksys RV042, so we did use the proxy enabled (on SSG side. Didnt have proxy on RV042 side, but it works).

We got the route based vpn working, and I prefer not to use policy based because I've heard that its not as secure as route based. If worse comes to worse, then I'll access the DMZ via the internet side instead of the vpn. But for now, we're exploring the possibility of having the remote location accessing, via vpn, both the local zone and DMZ.

VPN from remote to local zone already work, but the remote computer cannot access dmz though (cannot even ping). Computers on local zone can access DMZ so the route/policy from local to DMZ seems to work.

Is this do-able?
0
 
deimarkCommented:
As above, yes, its possible. :P

OK, your info does make more sens enow.

So from what you have said, you will have the following set up

1.  tunnel interface created with route to linksys router remote lan to go via tunnel interface
2.  Phase 1 GW set up for the linksys
3.  Phase 2 autokey ike vpn set up to use the GW in 2 and also to use the tunnel interface.  This also has config for the proxy ID

To allow us to keep the route based VPN and allow the linksys lan to also talk to the dmz over VPN we can do it as follows:

4.  Create new phase 2 autokey ike vpn, using same details as above, BUT change the proxy ID to be that of the local DMZ
5.  Try to bring up the VPN by pinging the linksys lan from the DMZ (or alternatively) use the "ping from <inteface>" in the FW CLI to replicate it.

For info though, there is not a major security difference in using route based VPN as opposed to policy based.  Both use the same functionality.

The main difference is that route based VPNs separate the delivery from the encryption.  ie a policy based VPN uses the policy to decide what to encrypt etc,whereas the route based leave the policy and encryption separate.

Its down to preference and network requirements really.

I prefer to use route based myself, cos I can clearly see whats going on, but policy based VPNs can allow you to create custom policies to only encrypt certain traffic as opposed to all.

HTH
0
 
QlemoC++ DeveloperCommented:
Bad idea to use such public IP addresses - reserved by US / UK. I hope those addresses are examples only.

The VPN is defined in one VR (either trust-vr or untrust-vr).To pass to the other VR, you need a route with the VR as target. Since it works with the internal network yet, I suppose you assigned the VPN to trust-vr, and have to set a backward route from untrust-vr to VPN passing trust-vr.

Linksys VPN has to be expanded to 48.0.0.0/6 (very broad ...), and so does the proxy ID on Juniper.

BTW, it would be easier if you would perform NAT on the VPN tunnel, with a local address (more kind of a Dialup-VPN).

0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now