Product: ScreenOS SSG Series
Version: 6.0 and up
Network Topology:
Network diagram:
Two sites that have internet connections and a firewall that supports IPSEC VPN. This procedure creates the Virtual Private Network across the internet between the sites.
Description:
The screenOS platform offers two basic types of VPN for site-to-site tunnels, route based and policy based. The policy based option is what all standard VPN capable firewalls offer for connectivity. These create a simple point-to-point connection over the internet between the two sites and permit the traffic. Route based options add a layer of flexibility to the connection. These permit the use of standard routing features like BGP or OSPF across the tunnel and allow deny policies and more ganular traffic control on the connection.
Proxy-id
Proxy-id is the method of identification of which ip ranges are connecting on a VPN on both sides. When tunnels are created each ip address on site A needs a matching proxy-id pair on Site B. When the tunnels are created each pair of connections creates a Security Association (SA) for that tunnel. Vendors all have slightly different ways to wrap the creation of these SA into their interface. But all of the pairs must be present on both sites A & B. for all of the traffic to pass. Some vendors will not create any of the SA unless ALL of the SA are present. Other vendors will create all the SA that they can match and just log errors for the pairs they cannot match.
When there is more than one SA pair on a policy VPN you must have all proxy-id pairs created. In ScreenOS these are automatically created by the creation of the tunnel action policy for policy VPN. Here you leave the proxy-id section blank.
With route based VPN we also leave the proxy-id blank on both sides as this by default allows any ip traffic we send down the tunnel interface only subject to the polices created.
When connecting route based VPN to a policy VPN on the remote side we must submit matching proxy-id pairs to the policy based engine. If there is more than one proxy-id pair you will need to use ScreenOS version 6.3 or higher.
Policy VPN
http://kb.juniper.net/InfoCenter/index?page=content&id=KB8534
These are a good choice for simple connections with a wide variety of 3rd party solutions. They connect the two sites and automatically create the necessary static routing along with the permit traffic policies in a few steps. These also operate exactly as a policy VPN standard that allows easy interoperability.
Route VPN
http://kb.juniper.net/InfoCenter/index?page=content&id=KB8533
Here the VPN is bound to an virtual interface on the firewall. This interface allows the creation of routing policies using any routing protocol supported on the firewall. This also then allows the use of routing preferences to automatically send traffic to alternate paths when this particular VPN interface goes down. The VPN tunnel interface can be unnumbered and associated with any physical interface on the firewall. Or the tunnel interface can be assigned an ip address and zone independent of other interfaces and zones on the firewall.
Policy is also more flexible. The policies that allow either the sending or receiving of traffic on the VPN tunnel interface can be narrow in ip scope and/or ports permitted. In addition, the deny policy can be applied to the tunnel interface for the specific ports and addresses desired.
You can create route based VPN on the ScreenOS side and connect to a standard policy VPN on the remote side of the connection.
Zones and Policies
Another feature of route based VPN is great flexibility in controlling traffic on VPN tunnels. ScreenOS provides the option to place VPN tunnel interfaces into any existing zone including custom zones created for this purpose. Thus you can bind VPN tunnels to trust zones which would automatically allow trust to trust traffic between sites and not require the creation of any permit traffic policies on the one side or place them into the untrust fully restricted zone or create and control a custom zone for these connections.
Verification:
SA status
Once the VPN is created the SA should be seen in the firewall.
CLI
get sa
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000026< 1.1.1.1 500 esp:3des/sha1 08af61f7 2524 unlim A/U -1 0
The column “Sta” is status and the first letter is an A for active and up and I for inactive, tunnels should be active when working and passing traffic.
Web
VPNs – Monitor Status
The SA should show as “Active”
If the SA does not come up or the SA is up but traffic cannot pass, then follow the troubleshooting steps listed in these kb articles.
Flow Chart Troubleshooting Guide
http://kb.juniper.net/kb/documents/public/resolution_path/J_visio_kb9221.htm
Question and Answer troubleshooting guide
http://kb.juniper.net/InfoCenter/index?page=content&id=KB9221
References:
ScreenOS Concepts & Examples Guides
http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/index.html
Volume 5 Virtual Private Networks
Chapter 3 VPN Guidelines
Chapter 4 VPN: Sit-to-site VPN Configurations
Knowledge Base Articles on VPN
Top level solution guide to creating and troubleshooting VPN for both Site-to-Site and Dialup
http://kb.juniper.net/kb/documents/public/resolution_path/J_FW_VPN_Config_or_Trblsh.htm
Solutions for Site-to-Site Route Based VPN
http://kb.juniper.net/InfoCenter/index?page=content&id=KB8533
Solutions for Site-to-Site Policy Based VPN
http://kb.juniper.net/InfoCenter/index?page=content&id=KB8534
Solutions for 3rd Party Compatibility VPN
http://kb.juniper.net/InfoCenter/index?page=content&id=KB8554
Troubleshooting VPN Issues
Flow Chart Troubleshooting Guide
http://kb.juniper.net/kb/documents/public/resolution_path/J_visio_kb9221.htm
Question and Answer troubleshooting guide
http://kb.juniper.net/InfoCenter/index?page=content&id=KB9221
Originally Posted May 14, 2011
Last Revised on May 14, 2011
Thu February 09, 2012, 22:24:01
Dear Sir,
I have two Juniper SSG20 firewalls installed at Head Office and Factory, we have created VPN to communicate both networks with each other and its been working fine with any hassel regardless of one issue i.e.
My question is this, H/O ethernet 0/0 can ping factory ethernet 0/0
H/O ehternet 0/1 can ping factory ethernet 0/1.
Unfortunately if H/O user want to access any device or even though ScreenOS page of the factory with the primary connection i.e. (H/O ethernet 0/0 and Factory ethernet 0/0) can’t get the ScreenOS or any other device page on the browser which is connected with that network.
In the other hand Factory user can easily access H/O ScreenOS or any other device page for configuration with the same primary connection i.e. (Factory ethernet 0/0 and H/O ethernet 0/0)
If we go on secondary connection both ends are working properly without any problem. we have been accessing each other remote devices on the browser.
You prompt response is highly appreciated.
Thanks in advance.
Muhammad Saleh Khan
Sat March 03, 2012, 11:38:58
From the description the main area to check is differences in interface configuration between the primary and secondary circuits. The management connections can be allowed or denied at the interface level.
Hi Steve,
I’m looking for some help and guidance regarding an issue with Route based IPSEC VPN Config between SSG-550M and Cisco FWSM.
From the get sa output, its A/D, however traffic is passing through it. The Remote end verified and they are able to reach my Trust NW.
Posting the config below for reference:
(Software Version: 6.3.0r17b.0, Type: Firewall+VPN)
X.X.X.X & Y.Y.Y.Y are Public IPs.
Proxy-id – Unchecked
set vpn “VPN_NAME” gateway “VPN_NAME_GW” no-replay tunnel idletime 0 sec-level standard
set vpn “VPN_NAME” monitor
set vpn “VPN_NAME” id 0x22 bind interface tunnel.5
set vpn “VPN_NAME” proxy-id local-ip 10.0.7.0/24 remote-ip 10.0.4.0/24 “ANY”
set ike gateway “VPN_NAME_GW” address Y.Y.Y.Y1 Main outgoing-interface “loopback.10” preshare “PRESHARE-KEY” sec-level compatible
set route 10.0.4.0/24 interface tunnel.5
set address “Untrust” “Y.Y.Y.Y/29” Y.Y.Y.Y 255.255.255.248
set address “Untrust” “10.0.4.0/24” 10.0.4.0 255.255.255.0
set policy id 98 from “Untrust” to “Untrust” “Y.Y.Y.Y/29” “X.X.X.X1/32” “ANY” permit log
set policy id 98a from “Untrust” to “Untrust” “10.0.4.0/24” “X.X.X.X1/32” “ANY” permit log
set policy id 01 from “Untrust” to “Trust” “Y.Y.Y.Y/29” “10.0.7.0/24” “ANY” permit log
set policy id 01a from “Untrust” to “Trust” “10.0.4.0/24” “10.0.7.0/24” “ANY” permit log
set policy id 03 from “Trust” to “Untrust” “10.0.7.0/24” “Y.Y.Y.Y/29” “ANY” permit log
set policy id 03a from “Trust” to “Untrust” “10.0.7.0/24” “10.0.4.0/24” “ANY” permit log
Also how do we enable PFS in Screen OS and is it global option or can I enable it specific to this VPN without affecting other VPNs that are in production.
Thanks in advance for Your help.
Best Regards,
Dawn
PFS is part of the specific tunnel configuration with the crypto package you choose so will only affect those VPN that are using that bundle.
You can see the crypto options by going to the menu:
VPN > Autokey Adv
Here a table will list that includes a column for PFS showing which collections have it on and off.
Naturally all the parameters must match on both sides.
And you can create a custom one here to if a preconfigured one does not have the exact combination you need.
Steve