Juniper SSG-20 LAN to LAN VPN with Cisco ASA 5500

I have been given a rather fun task.  I should mention that, while I can deal with basic routing, switch config and so on, when it comes to VPNs, I am close to clueless.

Unfortunately, I've been trying for 3 weeks now, and I really need to find a solution.  I'm trying to set up a Juniper SSG-20 with a VPN to a Cisco ASA 5500 at a remote site.

The situation is this:

I have a local network ( - don't ask).

I need to set up a LAN to LAN VPN to another site.  The other site's LAN address is

The VPN peer (if that's the right terminology), changed the protect the innocent, is

I've been given a pre-shared key and options to use for phase 1 and phase 2 (whatever they are).

Now, obviously the subnets of the VPN clash.  I've been told I need to perform network address translation at our end so that IPs on our network appear as part of the range

I've been playing around for a while now, and so far I've got as far as being rejected in the phase 1 section of negotiations, with an "invalid cookie" error (which makes no sense to me).

I would very much appreciate some assistance on this.  Because I don't really know what I'm doing with regard to VPNs and NAT, configuration examples would be most welcome.  The Juniper box at this end isn't doing anything else, so I can do whatever I want with it.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The VPN peer IP is their public IP address of the ASA.  Have you configured the Juniper's VPN with the Phase 1 and Phase 2 settings?  The invalid cookie error is indicating that when the two VPN appliances are negotiating the VPN tunnel during Phase 1, they realize that someone has the LAN networks allowed is configured incorectly.  My guess is it's your end since you are trying to NAT and they've given you the NAT IP network.

When you configure the VPN on your end, you'll want to configure it such that the LAN IP network that will access their network is  Subsequently, you'll want to configure a NAT rule that will translate any host on to an IP of BEFORE it attempts to traverse the VPN.  I'm not familiar with the Juniper, but I've done this several times on the Sonicwall appliances.  During the VPN creation wizard, the Sonicwall will automatically create the firewall and route rules.  I have to disable these and just get the VPN created.  Then, I go back and manually create the NAT, Route, and Firewall rules.
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
With Juniper, you can create route based VPN or policy based VPN tunnels. I assume you have done policy based, that is you created a policy, bound to a VPN setting.

If Phase 1 cannot be established, there is something very basic wrong. In WebUI, it is called "AutoKey Advanced". The following data has to match on each end:
  • Mode. It can be Main or Aggressive. In Main Mode, both gateways ("VPN peers") have to know each other, at  least by DNS name (regarding Juniper; Cisco needs a static IP, AFAIK).
  • Pre-Shared Secret (or Key, that is the same).
  • Proposals. That is the set of encryption, authentication and Diffie-Hellman encoding. You can put up to 4 proposals into a VPN definition with ScreenOS, each containing a different setting of two of those three above (you cannot use different DH groups). One of those proposals has to fit to the expected proposal on the other side.
  • Local ID (optional). Some devices need a local ID, that can be an email address, ASN.1 certificate string, a name, an IP address. If used, it has to be the same again on both sites.
Most devices will not give you the reason for denying access if Phase 1 is not correct. Hence you only get an "invalid cookie". That is by purpose, so you can't just try out, and try to hack. The side being called (the "responder") will have more details in its logs why the connection is rejected.

After you have set up Phase 1 correctly, Phase 2 needs to be set up similar. In ScreenOS, "AutoKey IKE" in WebUI, you have the following:
  • Proposals, as in Phase 1. They don't need to be the same as in Phase 1, usually that Phase has stronger encryption, as that determines how secure your payload traffic is.
  • Proxy-ID. That is (usually) which networks are on both sides. If you haven't set that up in the advanced options of Phase 2, the network setup of the policy is used - and that will be false, as you need to do NAT on your network addresses. You will have to set up the NAT network as Local, and the remote network without NAT.
That should be all to get Phase 2 established, and the tunnel running. But you still will not have NAT.
  1. You need to create the NAT network first on your Untrust (!) interface. Go into Interfaces, choose your Untrust interface used, and go into DIP. Create a new DIP pool with IP Address Range ~ That will dynamically assign IP addresses and ports to all requests coming from your network.
  2. Choose "In the same subnet as the extended IP ...", and assign an address of the NAT DIP range, e.g. The address is not really important, but needs to be set to something valid.
  3. In your VPN policy, Advanced, check "Source Translation" in NAT section, and choose your DIP.
Now you should be set.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
neil-bAuthor Commented:
Excellent.  Thank you for your help.  I've now got much further than I had previously - I think I just need to sort routing out now.
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
About routing: You need to set up a specific route on each client for the other network. That's all. On SSG, there is no need for a route, as the policy manages that already.
However, the SSG will not act as proxy, that is it will not forward request just blown into the local network, as it would be the case if you do not create that specific route on clients.

The difference is that if you set a route on a client, it sends the packet destined for that network to the SSG directly, while without route the packet is thought of going into the local network, and will not pass the VPN tunnel.

Setting specific route:
route -p add mask SSG_address_here
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.