We recently started replacing our aging Avaya VPN Routers (formerly Nortel Contivity) with Juniper SRX series gateways. We chose a Juniper SRX 650 to replace our Avaya VPN Router 1750 and we chose the Juniper SRX 210H to replace the Avaya VPN Router 1010 and 1050 models. While it was fairly easy to get both route based tunnels and policy based tunnels setup we had an interesting time trying to route all traffic at the branch back to the main office (as opposed to routing it directly to the Internet on the branch Juniper SRX 210H) so it could be policed by our corporate firewalls and content filtering solutions. We were able to accomplish this configuration through the use of VRFs and I’m going to outline how we did it (just in case anyone else is trying to follow in our footsteps – or better yet can improve the configuration).
Configure the Juniper SRX 210 Branch Office
Login to the serial console of the Juniper SRX gateway with the username of “root” (password should be blank). We’ll start the configuration by loading the factory defaults and then setting up some basic system information. We’ll add a user called “admin” for future use.
root@% cli root> configure Entering configuration mode [edit] load factory-default set system host-name vpn-srx210h-gw set system domain-name vpn.acme.org set system time-zone America/New_York set system root-authentication plain-text-password set system login user admin full-name Administrator set system login user admin uid 100 set system login user admin class super-user set system login user admin authentication plain-text-password
Lets set the SNMP information including a reference to the routing-instance “centralized-internet”. This will allow us to perform SNMP polls against this VRF from the specific IP management workstations we’ve listed below.
set snmp description "Juniper SRX 210H" set snmp location "Local Branch Office (Somewhere, USA)" set snmp contact "Technology Team" set snmp community readonlystring authorization read-only set snmp community readonlystring routing-instance centralized-internet clients 10.1.20.50/32 set snmp community readonlystring routing-instance centralized-internet clients 10.2.20.50/32 set snmp community readwritestring authorization read-write set snmp routing-instance-access commit
Let’s start by configuring the WAN (public) and LAN (private) IP addresses. The interface ge-0/0 is the public interface which will connect to the Internet Service Provider. The interface vlan.0 is the private interface which is made up of physical interfaces ge-0/1 – ge0/7. We’ll also delete the factory default address of 192.168.1.1.
set interface ge0/0/0 unit 0 family inet address 1.51.88.10/30 set routing-options static route 0.0.0.0/0 next-hop 1.51.88.9 set interface vlan unit 0 family inet address 10.1.200.1/24 delete interfaces vlan unit 0 family inet address 192.168.1.1/24
Let’s enable the web management GUI on the public interface and set the TCP port to 10443 as opposed to the default of 443.
set system services web-management https interface ge-0/0/0.0 set system services web-management https port 10443
Let’s enable the system services we want to allow in the untrust zone.
set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone untrust host-inbound-traffic system-services ping set security zones security-zone untrust host-inbound-traffic system-services https
Let’s repeat those commands for the specific public interface.
set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services ike set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services ping set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services https
Let’s build the VPN tunnel interfaces to Juniper SRX 650. We’ll need to assign IP addresses to these interfaces since we’re setting up a Point to MultiPoint network with route based VPN tunnels.
set interfaces st0 unit 0 family inet address 10.1.255.120/24 set interfaces st0 unit 0 family inet mtu 1500
Let’s finish up setting up the security zones and adding the VPN interfaces.
set security zones security-zone vpn interfaces st0.0 set security zones security-zone untrust interfaces ge-0/0/0.0 set security zones security-zone trust interfaces vlan.0 set security zones security-zone trust host-inbound-traffic system-services all
Let’s not forget to allow the remote management via the web interface. (added 10/18/2011)
set security zones security-zone vpn host-inbound-traffic system-services all set security zones security-zone vpn host-inbound-traffic protocols all set system services web-management http interface st0.0
Let’s setup the IKE policies and pre-shared-key for both VPN tunnels, please make sure to replace the preshared-key and IP addressing below with the values that’s specific to your installation (not the example one). I use the acronym PDC to stand for Primary Data Center since we have both a primary and alternate/standby.
set security ike policy PDC-IKE mode main set security ike policy PDC-IKE proposal-set standard set security ike policy PDC-IKE pre-shared-key ascii-text "c3DrmFiRei37NpW65GnygdOorykE0ZjnpyX" set security ike gateway PDC-GW ike-policy PDC-IKE set security ike gateway PDC-GW address 2.1.1.25 set security ike gateway PDC-GW external-interface ge-0/0/0.0 set security ipsec policy ACME-VPN proposal-set standard set security ipsec policy ACME-VPN perfect-forward-secrecy keys group2 set security ipsec vpn PDC-VPN ike gateway PDC-GW set security ipsec vpn PDC-VPN ike ipsec-policy ACME-VPN set security ipsec vpn PDC-VPN bind-interface st0.0 set security ipsec vpn PDC-VPN establish-tunnels immediately
The Juniper SRX still acts as a firewall so we need to create policies to allow the traffic to flow. I’ll set everything wide open for this example.
edit security policies from-zone trust to-zone vpn set policy local-to-spokes match source-address any set policy local-to-spokes match destination-address any set policy local-to-spokes match application any set policy local-to-spokes then permit exit edit security policies from-zone vpn to-zone trust set policy local-to-spokes match source-address any set policy local-to-spokes match destination-address any set policy local-to-spokes match application any set policy local-to-spokes then permit exit edit security policies from-zone vpn to-zone vpn set policy local-to-spokes match source-address any set policy local-to-spokes match destination-address any set policy local-to-spokes match application any set policy local-to-spokes then permit exit
We’ll create a virtual routing instance setting the next-hop to interface st0.0
set routing-options interface-routes rib-group inet centralized set routing-options rib-groups centralized import-rib inet.0 set routing-options rib-groups centralized import-rib centralized-internet.inet.0
We’ll create a virtual routing instance setting the next-hop to interface st0.0
set routing-instances centralized-internet instance-type virtual-router set routing-instances centralized-internet interface st0.0 set routing-instances centralized-internet routing-options static route 0.0.0.0/0 next-hop st0.0
This filter will direct all traffic to the centralized-internet routing table. The first term allows us to add an exception although it’s not used today but can be for testing and troubleshooting by changing the IP address to a valid LAN client IP address. This filter allows traffic from 10.1.200.254 to be routed based on the default routing-instance which would send it directly out to the Internet as opposed to routing it over the VPN tunnel back to the main office.
set firewall filter centralized-internet-filter term 1 from destination-address 10.1.200.254/32 set firewall filter centralized-internet-filter term 1 then accept set firewall filter centralized-internet-filter term 2 then routing-instance centralized-internet
We’ll apply the filter we created above to traffic ingressing the interface vlan.0.
set interface vlan unit 0 family inet filter input centralized-internet-filter
Let’s configure a DHCP relay instance to forward DHCP requests to a centralized server (10.1.1.40).
set forwarding-options helpers bootp relay-agent-option set forwarding-options helpers bootp description "Branch DHCP Relay" set forwarding-options helpers bootp server 10.1.1.40 routing-instance centralized-internet set forwarding-options helpers bootp vpn set forwarding-options helpers bootp interface vlan.0
Let’s configure the TCP-MSS value so we don’t have any MTU issues tunneling over IPSec
set security flow tcp-mss ipsec-vpn mss 1350
Let’s configure the debug options so we can troubleshoot any IKE/IPSEC issues.
set security ike traceoptions file size 1m set security ike traceoptions flag policy-manager set security ike traceoptions flag ike set security ike traceoptions flag routing-socket
We need to disable IDP to prevent unwanted error messages from filling the log.
set system processes idp-policy disable
Now we need to commit and save all the changes we’ve made above.
commit
If you have issues committing the changes with errors such as :
root# commit [edit system] 'autoinstallation' incompatible with 'forwarding-options helpers bootp' [edit forwarding-options helpers] 'bootp' incompatible with 'system autoinstallation' error: commit failed: (statements constraint check failed)
Just issue the following command and re-issue the commit
root# delete system autoinstallation
If you are connected to the public Internet you can sync the date/time via NTP over the public interface.
root# set date ntp 173.9.142.98
Configure the Juniper SRX 650 Main Office
Now we need to configure the Juniper SRX 650 which is the main office side of the tunnel.
Let’s create an IKE policy for this specific connection. Please remember to substitute the preshared-key and IP addresses I use in the example below.
set security ike policy TESTLAB-IKE mode main set security ike policy TESTLAB-IKE proposal-set standard set security ike policy TESTLAB-IKE pre-shared-key ascii-text "c3DrmFiRei37NpW65GnygdOorykE0ZjnpyX"
Let’s create a gateway and tie it together with our IKE policy. Let’s set the public IP address of the branch office VPN site.
set security ike gateway TESTLAB-GW ike-policy TESTLAB-IKE set security ike gateway TESTLAB-GW address 1.51.88.10 set security ike gateway TESTLAB-GW external-interface ge-0/0/0.0
Let’s create a VPN policy and tie all the policies together binding it to st0.10 which is a multipoint interface on the main office side.
set security ipsec vpn TESTLAB-VPN ike gateway TESTLAB-GW set security ipsec vpn TESTLAB-VPN ike ipsec-policy ACME-VPN set security ipsec vpn TESTLAB-VPN bind-interface st0.10 set security ipsec vpn TESTLAB-VPN establish-tunnels immediately
Since we’re not yet doing OSPF we need to create a static route in the appropriate routing instance.
set routing-instances routing-table-lan routing-options static route 10.1.200.1/24 next-hop 10.1.220.10
I’m omitting a few steps on the Juniper SRX 650 to implement the Multipoint VPN feature but it’s well documented (as most of this is) in the Juniper documentation.
References;
Cheers!
If you don’t mind sharing, what were the motivators behind changing VPN vendors? Were you unhappy with a demo of the current-generation Avaya VPN gateway? Did Juniper simply undercut pricing, or did SRX features perform better at meeting your needs? Please provide as much detail as you are comfortable posting.
thanks.
Hi Mike,
We looked briefly at the Cisco ASA and the Juniper SRX products. Avaya has done away with the VPN Router so there’s no longer a branch to branch product similar to the VPN Router line so Avaya really didn’t have a solution for us. We talked briefly about using a Secure Router but when I inquired I was told it couldn’t do Ethernet to Ethernet routing. So we set out to find a suitable replacement product that would provide us everything we needed. We landed on the Juniper SRX 650 in the main office and 210H in the branches. The Juniper SRX has a lot of performance behind the hardware, more so than the Cisco ASA and the Juniper solution was more cost effective. We’re a best of breed organization and not afraid to have different manufacturers working in the network. If you are a Cisco shop then the ASA should work fine for you. We utilize Cisco in our Data Center and Avaya in our hospitals and now we utilize Juniper in our VPN network which is pretty sizable right now with 30+ offices connected via Verizon FiOS and Comcast Business Cable. We have about 15 offices up and running right now and working flawlessly (expect for a few Comcast outages!)… we just ordered an additional 15 SRX210Hs to replace the last few VPN Routers 1010s and 1050s.
Cheers!
Clever solution! If I understand this correctly you’re using the default routing table for internet connectivity only (VPN setup) and are doing everything else in the second VRF through the VPN interface. I actually had to make a small drawing to get the total picture :-) as I’m also not familiar with the SRX’s.
One small question: if I recall correctly you once said that you’re also using ERS 4548GT’s in your remote sites/branch offices? Is this the same situation or is there also a difference between the remote sites and branch offices as in the former has a dedicated ethernet circuit and only a ERS 4548GT (in layer 3 maybe) and the latter is an even smaller location which only has a commercial ISP link and thus needs an IPsec tunnel?
I ask this because we’re actually ripping out our local firewalls (old Juniper NS 25’s) at our remote sites and moving to a more central routing based network. The reason for this is that in the last years we’ve gotten dedicated gigabit MAN connectivity to our remote sites, which essentially means ethernet on both ends and with some active equipment in between on the dual fiberring. We found it not worth the extra cost of a new gigabit capable firewall on each site when all the servers were already being centralized at the main site. It’s always interesting to get different perspectives on things like this though!
Hi Bylie,
That’s essentially correct.
Yes, we have an Avaya ERS 4548GT (Layer 2) at every office and we tunnel all the traffic back to our main office. We give the office a Class C from our internal RFC1918 address space and essentially route it over the VPN tunnels. We also use the DHCP relay functionality to integrate with our Infoblox appliances. All these offices are connected via broadband Internet (usually from Verizon or Comcast) so they have the ability to communicate directly with the Internet but we want all traffic to come back to the main office so we can apply our security policies, content filtering (Websense) and IDS/IPS (Cisco) at a single centralized point (ok two points really since we have 2 1Gbps Internet connections at two different facilities which are connected via our 10Gbps WAN).
There are a large number of organizations using IPSec or even just GRE tunnels across their internal network. In our case the tunnels are over the public Internet but you could certainly do the same over your internal network, and you could probably just use GRE and save yourself the overhead of IPSec.
Cheers!
I had to sent my first DMCA take down request to WordPress.com this evening. I usually ignore the trolls but since WordPress.com has such a high SEO page ranking they are showing up in the search results well before the location of the content’s original link.
Hi Michael,
This is a nice design. I have worked on large WAN networks using Juniper SRX routers and I have seen /32 static routes for the public IP’s of the remote IPSec gateways used as an alternative to multiple routing instances. I don’t think this method is as clean as your design but it did seem to work fine.
Out of curiosity have you enable any dynamic routing protocols over your ‘centralized-internet’ routing instance?
Stefan
@exactnetworks
Hi Stefan,
Since this post I’ve deployed OSPF over the routing instance and we’re multi-homing our remote branch offices for increased redundancy between 2 Juniper SRX 650s which are geographically disperse and connect to separate Internet Service Providers.
Cheers!