For a quick documentation on how to build a Site-to-Site IPsec VPN tunnel between a Palo Alto Networks firewall and a Juniper ScreenOS device I am listing the configuration screenshots here.
It is quite easy because both firewalls implement route-based VPNs. That is: The tunnel must not be configured with Proxy IDs or the like. It is simply built upon the correct parameters for IKE and IPsec. The related traffic can then be routed into the tunnel afterwards. And since the tunnel monitor from the Palo Alto firewall triggers the tunnel to be built even though no real traffic flows through it, the admin immediately sees green status bubbles in the GUI and can be sure that the tunnel establishment was successful.
The following figure shows my laboratory IP address scheme. I am using numbered tunnel interfaces:
The SSG 5 runs with firmware version 6.3.0r14.0 while the Palo Alto PA-200 has PAN-OS 5.0.8 installed. In order to use the most secure crypto algorithms, I configured both phases with AES-256, SHA-1, and Diffie-Hellman group 5 (PFS). The zones on both firewalls are already configured – in my lab they are called “vpn-s2s”.
At first, create the IKE and IPsec Crypto Profiles:
Create (add) the IKE Gateway with the outgoing interface and IP address, the pre-shared key (PSK) and the specific IKE Crypto Profile:
Tunnel Interface with its IP address, virtual router and security zone:
Create a Monitor Profile for the tunnel monitor:
And then the IPsec Tunnel. Enable the “Replay Protection” which is enabled by default on the Juniper firewall. Also add the tunnel monitor with the destination IP address of the other side of the tunnel interface:
Finally, add a new static route for the remote network with a Next Hop selection of “None”:
However, the Palo Alto firewall also needs a security policy entry on the untrust interface that permits the IKE and IPsec (ESP) packets to come in from the other tunnel endpoint and to go out from its own interface. That is, the policy rule should look like the following:
(And don’t forget to commit ;))
The steps are almost the same for the Juniper firewall. At first, add the additional P1 and P2 proposals:
Add a new Gateway with the correct IP address of the other side. Under the Advanced tab insert the PSK and the Custom Phase 1 Proposal:
A new tunnel interface with its IP address:
And the new AutoKey IKE entry which references to the gateway and to the tunnel interface (under the Advanced tab):
Finally, add the static route without a next hop IP address but with an interface of the configured tunnel:
If everything is alright, the IPsec tunnels pane on the Palo Alto firewall should show two green status bubbles:
(However, I had some situations in which the first status bubble was green (IPsec) while the second was red (IKE) after a while. Though I thought this would be impossible because IPsec always needs IKE, the VPN still worked.)
Of course, there are no configured policies yet. No traffic from the remote networks will flow through the tunnel unless some vpn-s2s policies are installed. However, the installation of these should be obvious.
15 thoughts on “IPsec Site-to-Site VPN Palo Alto <-> Juniper ScreenOS”
would you be kind tell me how to install vpn-s2s policies on both side to allow any traffic in both direction. It’s not working with me
Hi Joe. The vpn-s2s policies are just like any other policies on the two devices. E.g., on the Juniper you need an “any any” policy from trust to vpn-s2s (and vice versa: from vpn-s2s to trust). The same on the Palo Alto: from zone “trust” (or whatever your name for the trust zone is) to vpn-s2s with any application and any service, and vice versa: from vpn-s2s to trust. Thats is.
However, is this the only problem? I mean, is the VPN tunnel already working? Do you see the “green bubbles” on the PA? Do you have the correct routing on both devices?
Brilliant! Exactly what I’m after, I mean, site to site vpn between Juniper SSG and PA firewall. :)
I feel odd that PA does not support IKE v2, or it’s said there is problem in this part of PANOS.
Thank you for the article!
I have a question about the rule 23. The objects h_fd_wv_fw01_trust and h_fd_wv_fw02_untrust which are used in the rule are not described in the documentation. Which IP addresses are used here? Is any any also possible, that would be one rule for all site 2 site vpns?
Is a tunnel IP necessary for the site 2 site vpn with juniper or is unnumbered also allowed.
I have configured a tunnel between PA and Juniper. On PA all is green, but on the Juniper the tunnel is down. A ping trougth the tunnel from the PA site gets time out.
yes, sorry, the objects are not described. These are the untrust/outside IP addresses from both firewalls, i.e., the 172.16.1.1 and 172.16.1.2 in my example. The Palo Alto needs this rule to talk with IPsec and IKE between those addresses. And yes, “any any” is also possible. ;)
The tunnel must not be numbered. An unnumbered tunnel interface on both sides works, too.
And do not forget the security policies from the vpn-s2s zones…
I read you post I found the below lines. I have a question that can we configure proxy-ID or we must not configure it on the boxes.
“It is quite easy because both firewalls implement route-based VPNs. That is: The tunnel must not be configured with Proxy IDs or the like.”
Actually I’m facing an issue where the rekeying on the SSG is configured as default i.e 1 hour for phase-2 and 8 hours for phase-1, but the phase-1 is also renegotiating with phase-2 renegotiation at the same time.
the proxy-IDs must NOT be configured. Only the routing table is responsable for the routing.
Please verify that you have configured exactly the same proposals for phase 1 and phase 2 on both devices. If your phase 1 is renegotiating after 1 hour, then you have probably configured it with 1 h in one of the firewalls.
I want to thank you for sharing your valuable knowledge with everyone.
I must say that your website is one of the best websites of on multi security vendors, the way you have explained the topics are brilliant.
I was wondering, if there is any way we can emulate Juniper ScreenOS on GNS3 to practice your lab or any other way to practice it on the PC.
Thanks in advance.
thanks for your comment. I am glad to hear that you like the content.
I do not know a way to simulate Juniper ScreenOS on GNS3. I am sorry. However, you could buy a ScreenOS unit, such as the SSG 5 on eBay or the like. Sometimes they are selled for 50,- € or lower.
You mention having to create a rule to allow ike and ipsec but isnt this only required if you have setup an explicit deny rule for intrazone traffic?
The default for intrazone traffic is allow. In your example you have untrust to untrust so that should match the default intrazone rule and allow ike and ipsec unless a deny any any any rule was created?
Yes, you are absolutely correct. The default intrazone policy would allow this kind of traffic. However, I definitely prefer an explicit deny rule at the very end of each policy rules. That is, the mentioned rule for allowing these IKE/IPsec traffic types is mandatory for me.
I have a weird problem that maybe someone can help with.
We have an SSG5 and PAN220 box. If the PAN has no outbound NAT setup the VPN tunnel passes traffic from the SSG to the PAN and vice versa. If I setup outbound NAT, the SSG will pass traffic to the PAN, but the PAN will not pass traffic to the SSG. VPN reports being up on the PAN and SSG in both cases.
please check your NAT policies and your zones. Do you have the same zone configured for both the untrust interface and the tunnel interface? If so, the outbound NAT *may* be applied in a wrong way. Use different zones for your untrust/Internet connection and your tunnel interfaces.
If you want to troubleshoot your packet flows in detail, use the commands shown here: https://weberblog.net/cli-commands-for-troubleshooting-palo-alto-firewalls/ at “Live Viewing of Packet Captures”.
I might be shooting in the dark here. I am recruiter and I am looking for people who are excellent with Juniper SRX and Palo Alto firewalls for an immediate requirement. Are you or someone you know looking for a job?
Nice try, Nivi, but I am not interested. ;)