DO AmbassadorsCookbook2 PDF
DO AmbassadorsCookbook2 PDF
DO AmbassadorsCookbook2 PDF
The Juniper Ambassador program recognizes and supports its top community members
and the generous contributions they make through sharing their knowledge, passion, and
expertise on J-Net, Facebook, Twitter, and other social networks. The Juniper Ambassa-
dors are a diverse set of network engineers, consultants, and architects who work in the
field with Juniper technologies on a daily basis.
In this Day One cookbook for Enterprise network administrators, the Juniper Ambassa-
dors take on some of the top support issues and provide clear-cut solutions and frank
discussions on how to keep things running. From creating an aggregate link between a
Juniper and Cisco switch, to deploying IPsec VPN using Junos Space, to connecting two
networks using a SRX Series, the sixteen recipes in this cookbook are meant to provide
quick and tested solutions to everyday issues.
ITS DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
Create a Junos image that can be deployed from a USB thumb drive.
Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the
complete library at www.juniper.net/books.
ISBN 978-1936779697
52000
07100171
9 781936 779697
Day One: Juniper Ambassadors
Cookbook for Enterprise
2013 by Juniper Networks, Inc. All rights reserved. Published by Juniper Networks Books
Juniper Networks, the Juniper Networks logo, Junos, Authors: Martin Brown, Ben Dale, Glen Kemp, Petr
NetScreen, and ScreenOS are registered trademarks of Klemaj, Chris Jones, Steve Puluka, Michel Tepper, and
Juniper Networks, Inc. in the United States and other Scott Ware
countries. Junose is a trademark of Juniper Networks, Technical Reviewer: Kevin Barker
Inc. All other trademarks, service marks, registered Editor in Chief: Patrick Ames
trademarks, or registered service marks are the property Copyeditor and Proofer: Nancy Koerbel
of their respective owners. J-Net Community Manager: Julie Wider
Welcome Ambassadors!
Juniper Ambassadors are global technical/brand advocates that actively
participate across Juniper community and social programs. They are a
diverse set of network engineers, consultants, and architects who work
in the field with Juniper technologies on a daily basis. The Juniper
Ambassadors mission is spreading the word about the power of Junos
to the worlds networking and security engineers. Welcome Ambassdors!
vi
Audience
This book is intended for Enterprise network administrators and
provides field-tested recipies for common network deployment
scenarios, as well as brief background information needed to under-
stand and deploy these solutions in your own environment.
This books recipes are numbered, and they are loosely organized into
the following topic areas:
Switching: 1 and 13
IPsec VPN: 2, 4, 6, 14, 15
Routing: 5. 9
Dual ISP: 8, 12
Junos Operations: 3, 11
IVE/SSL VPN: 7, 10, 16
Aggregated Links
Problem
The problem facing network engineers is that different vendors use
different methods. For example, AVAYA uses multi-link trunking
among other methods, and Cisco uses PAGP. Thankfully, in 2000,
the IEEE released 802.3ad, which uses a standard protocol called
LACP. Most manufacturers support this in addition to their own
standards, and 802.3ad greatly assists engineers when creating
aggregated links in multivendor environments.
12 Day One: Juniper Ambassadors Cookbook for Enterprise
The configuration for both of these devices is set as the default, aside
from the host name.
Solution
The first step is to connect the switches at Layer 1 and straight away
youll hit the first problem. The EX has the ports defaulting to a trunk
port, sending out BPDUs, whereas this particular Catalyst has the
ports set as access ports. When the Catalyst receives the BPDUs, an
error is generated and the ports are placed in an inconsistent state:
%SPANTREE-7-RECV_1Q_NON_
TRUNK:Received802.1QBPDUonnontrunkFastEthernet0/1VLAN1.
%SPANTREE-7-BLOCK_PORT_
TYPE:BlockingFastEthernet0/1onVLAN0001.Inconsistentporttype.
Before the aggregated links are created, this issue needs to be resolved.
Therefore on the Catalyst, in global configuration mode, the following
is entered:
interfacerangefa0/13
shut
switchportmodetrunk
noshut
Recipe 1: Aggregated Links 13
SpanningTreeinterfaceparametersforinstance0
InterfacePortIDDesignatedDesignated PortStateRole
portIDbridgeIDCost
ge-0/0/12.0128:525128:132769.001647a7bbc0200000FWDROOT
ge-0/0/13.0128:526128:232769.001647a7bbc0200000BLKALT
ge-0/0/14.0128:527128:332769.001647a7bbc0200000BLKALT
Now that connectivity has been verified, configuration for the aggre-
gated link can begin. The second step is to tell the EX Switch how
many aggregated links will exist on this switch. In this case, it will be
one, therefore the following is entered:
setchassisaggregated-devicesethernetdevice-count1
The third step is to add each physical port to the logical port. At
Juniper, the logical ports begin with the letters AE, and in this case,
port 0 will be used as this is the first aggregated link. Therefore
physical ports ge-0/0/12, ge-0/0/13, and ge-0/0/14 will be added to
logical port ae0. The last entry in this third configuration step tells the
switch to use LACP as the protocol (Note that LACP is configured as
active on the EX switch. When running LACP at least one switch must
be set as active for the protocol to function.)
setinterfacesge-0/0/12ether-options802.3adae0
setinterfacesge-0/0/13ether-options802.3adae0
setinterfacesge-0/0/14ether-options802.3adae0
setinterfacesae0aggregated-ether-optionslacpactive
ge-0/0/12{
ether-options{
802.3adae0;
}
unit0{
familyethernet-switching;
14 Day One: Juniper Ambassadors Cookbook for Enterprise
You can see that under each physical interface configuration is the
setting to make the port a standard enternet port, and that will conflict
with the aggregated link. Therefore lets delete that from the configura-
tion:
deleteinterfacesge-0/0/12unit0
deleteinterfacesge-0/0/13unit0
deleteinterfacesge-0/0/14unit0
root@EXSWITCH#commitcheck
configurationchecksucceeds
Now the aggregated links have been created. After commiting the
changes, using run show lacp interfaces while still in configuration
mode should indicate the status of the aggregated link. In this instance,
running this configuration returns no entries listed, meaning the link is
non existent:
root@EXSWITCH#runshowlacpinterfaces
{master:0}[edit]
root@EXSWITCH#
By using the run show interfaces terse ae0 command, it is clear that
the link is down even though administratively it is up:
root@EXSWITCH#runshowinterfacesterseae0
InterfaceAdminLinkProtoLocalRemote
ae0updown
Looking at the log file messages, the issue becomes clear: the no
link-speed option has been set.:
EXSWITCHdcd[37154]:ae0:Warning:aggregated-ether-optionslink-
speednokernelvalue!defaultto0
The interesting part about this scenario is that the Catalyst has only
fast Ethernet ports, whereas the EX switch has gigabit Ethernet. The
EX switch has to be told that the port speed will be 100 megabit and
this needs to be done on the logical port and the physical ports, too:
Recipe 1: Aggregated Links 15
setinterfacesae0aggregated-ether-optionslink-speed100m
setinterfacesge-0/0/12ether-optionsspeed100m
setinterfacesge-0/0/13ether-optionsspeed100m
setinterfacesge-0/0/14ether-optionsspeed100m
Now issue run show lacp interfaces again, and the results should
show that the links are up, however, the mux state is currently showing
as detached:
root@EXSWITCH#runshowlacpinterfaces
Aggregatedinterface:ae0
LACPstate:RoleExpDefDistColSynAggrTimeoutActivity
ge-0/0/12ActorNoYesNoNoNoYesFastActive
ge-0/0/12PartnerNoYesNoNoNoYesFastPassive
ge-0/0/13ActorNoYesNoNoNoYesFastActive
ge-0/0/13PartnerNoYesNoNoNoYesFastPassive
ge-0/0/14ActorNoYesNoNoNoYesFastActive
ge-0/0/14PartnerNoYesNoNoNoYesFastPassive
LACPprotocol:ReceiveStateTransmitStateMuxState
ge-0/0/12DefaultedFastperiodicDetached
ge-0/0/13DefaultedFastperiodicDetached
ge-0/0/14DefaultedFastperiodicDetached
The simple reason is that although the links have been created, the port
ae0 was created with no configuration and this is the same issue faced
when the two switches were originally connected. The aggregated port
on the EX switch needs to be set as a trunk port:
setinterfacesae0unit0familyethernet-switchingport-modetrunk
If the show lacp interfaces command is run now, it should report that
the mux state is now collecting and distributing, which means full
connectivity.
root@EXSWITCH>showlacpinterfaces
Aggregatedinterface:ae0
LACPstate:RoleExpDefDistColSynAggrTimeoutActivity
ge-0/0/12ActorNoNoYesYesYesYesFastActive
ge-0/0/12PartnerNoNoYesYesYesYesSlowActive
ge-0/0/13ActorNoNoYesYesYesYesFastActive
ge-0/0/13PartnerNoNoYesYesYesYesSlowActive
ge-0/0/14ActorNoNoYesYesYesYesFastActive
ge-0/0/14PartnerNoNoYesYesYesYesSlowActive
LACPprotocol:ReceiveStateTransmitStateMuxState
ge-0/0/12CurrentSlowperiodicCollectingdistributing
ge-0/0/13CurrentSlowperiodicCollectingdistributing
ge-0/0/14CurrentSlowperiodicCollectingdistributing
16 Day One: Juniper Ambassadors Cookbook for Enterprise
Let's issue a ping from the EX switch to confirm whether each switch
can reach the other successfully.
root@EXSWITCH>ping10.10.10.2
PING10.10.10.2(10.10.10.2):56databytes
64bytesfrom10.10.10.2:icmp_seq=0ttl=255time=37.901ms
64bytesfrom10.10.10.2:icmp_seq=1ttl=255time=3.295ms
64bytesfrom10.10.10.2:icmp_seq=2ttl=255time=4.222ms
64bytesfrom10.10.10.2:icmp_seq=3ttl=255time=3.373ms
deleteinterfacesae0unit0familyethernet-switching
setinterfacesae0unit0familyinetaddress10.10.10.1/24
Typeescapesequencetoabort.
Sending5,100-byteICMPEchosto10.10.10.1,timeoutis2seconds:
!!!!!
Successrateis100percent(5/5),round-tripmin/avg/max=4/4/4ms
18 Day One: Juniper Ambassadors Cookbook for Enterprise
Recipe 2
Problem
IPsec VPNs are very widely used today and they have been for
quite a while its typically a cheaper way of establishing secure
communications versus leased lines, especially when you need to
connect globally. In most cases, you have probably configured
your IPsec VPNs via the command line, as with so many other
features. But as your network grows, you might find yourself
relying on scripts and other methods to deploy your IPsec con-
figurations to the masses, which can be tedious to manage. Lets
use Junos Space instead.
Solution
Well use Junos Space to create and manage IPsec VPNs from
Spaces GUI, versus a command line interface.
Junos Space is a platform that provides a single interface to
manage all of your network devices, and specifically at Security
Director, which is used to manage all of your SRX security
policies, IDS, IPsec VPNs, and more.
For this recipes example, lets create an IPsec VPN between two
SRX devices. One will be our headquarters, or HQ, and the other
will be a vendor, lets all it ABC Corp. There will be no need for
NAT, so a policy-based IPsec VPN will be used instead of a
route-based IPsec VPN.
20 Day One: Juniper Ambassadors Cookbook for Enterprise
MORE? See also the recipe in this Ambassadors Cookbook: SRX to ASA
Policy Based IPSec VPN, for another policy-based IPsec VPN.
Step 1: Log In
First, lets start by logging in to Junos Space. Open up a web browser
and enter the URL of your Junos Space server:
NOTE Extranet Devices are firewalls for which Junos Space does not directly
control and manage all the settings. Extranet device objects allow
Junos Space to reference a third-party device in a configuration even
though you do not have a log in or other control of the device.
Recipe 2: Using Junos Space Security Designer Director to Create IPsec VPNs 21
Enter a name for the vendors SRX, as well as their Internet facing
(public) IP address.
22 Day One: Juniper Ambassadors Cookbook for Enterprise
Now lets start filling in the details for our vendor VPN Policy:
Name: Vendor-ABCCorp
Description: Optional, so well just leave it blank for now.
Mode: Main
Proposals: Predefined > Standard
For our Phase 1 information: Youll be using Main mode, and a
pre-defined set of proposal sets. Standard will give you the
following proposals:
Proposal 1: Preshared key, 3DES encryption, and Diffie-Hell-
man Group 2 and SHA-1 authentication.
Proposal 2: Preshared key, Advanced Encryption Standard
(AES) 128-bit encryption, and Diffie-Hellman Group 2 and
SHA-1 authentication.
Recipe 2: Using Junos Space Security Designer Director to Create IPsec VPNs 23
Note that the Enable Anti Replay is not checked and that by default
it is enabled. Once you have everything configured the way you want
it, click on the Create button to create your VPN Profile.
Once finished, your IPsec VPN settings should look like the following:
Next, well be selecting our vendors SRX. Change the radio button at
the bottom to Extranet, and find the entry for your vendor Vendor-
ABCCorp-Endpoint.
One you have both of your endpoints selected, click the Next button at
the bottom to proceed.
On the next Create VPN screen, you need to select the external
interface (public) of your SRX. Click on the box next to your firewall
(vpn-fw1) and select your Internet facing IP, as shown here:
Recipe 2: Using Junos Space Security Designer Director to Create IPsec VPNs 27
Since Junos Space does not manage our vendors SRX, we will be
leaving their External Interface blank.
Once you have selected the appropriate interface, click the Finish
button.
Testing
Now lets test the IPsec VPN tunnel to the vendor, and make sure traffic
is flowing through it. To do this, you need to log in to the HQ SRX via
the command-line, and enter in the show security ike security-asso-
ciations command and you should get output similar to the following:
root@vpn-fw1>showsecurityikesecurity-associations
--------------------------------------------------------------------------
IndexStateInitiatorcookieRespondercookieModeRemoteAddress
3953325UP5324bcab386c9f1efc335ffaa7e0fa2cMain10.1.1.1
As you can see, the Phase 1 state of our VPN tunnel looks good. Lets
make sure that Phase 2 is established as well, by using the show secu-
rity ipsec security-associations command:
28 Day One: Juniper Ambassadors Cookbook for Enterprise
root@vpn-fw1>showsecurityipsecsecurity-associations
--------------------------------------------------------------------------
Totalactivetunnels:26
IDAlgorithmSPILife:sec/kbMonvsysPortGateway
<34ESP:3des/md536d7a50528765/unlimUroot50010.1.1.1
>34ESP:3des/md51548a6e428765/unlimUroot50010.1.1.1
And everything here is looking good for Phase 2 as well. There is
two-way communication between HQ and the vendor.
Summary
As you can see, creating an IPsec VPN tunnel using Junos Space is, in
its simplicity, only about a five-step process. This should get you
familiar with creating and managing IPsec VPNs within Junos Space as
well as all the other options in the program.
Recipe 3
Problem
You have a new project that requires you to install Juniper
firewalls at many locations, and the base configuration is the same
with minor, location-dependent changes. How can you rapidly
deploy a standard configuration to them all without having to
manually configure each one?
Solution
Enter the Junos snapshot feature, allowing you to take a snap-
shot of the device and its entire configuration, and then save that
snapshot to external media. You can then use that image to copy
to subsequent devices so that all of them can be quickly deployed
with a standard configuration of your choice.
30 Day One: Juniper Ambassadors Cookbook for Enterprise
setsystemroot-authenticationplain-text-password
deletevlans
deleteinterfacesvlan
deletesecurityzonessecurity-zonetrustinterfaces
deletesecurityzonessecurity-zoneuntrustinterfaces
deleteinterfaces
deletesystemservicesweb-management
deletesystemservicesdhcp
deletesystemname-server
deletesystemservicestelnet
deletesystemservicesxnm-clear-text
deleteprotocolsstp
deletesecuritynat
deletesystemautoinstallation
setsystemhost-namesrx1
setinterfacesge-0/0/0unit0familyinetdhcp
setsecurityzonesecurity-zonetrusthost-inbound-trafficsystem-servicesall
setsecurityzonesecurity-zonetrusthost-inbound-trafficprotocolsall
setsecurityzonesecurity-zonetrustinterfacesge-0/0/0.0
Once you have configured the device to your liking, go ahead and
commit the configuration and then exit configure mode:
[edit]
root@srx1#commitand-quit
commitcomplete
Exitingconfigurationmode
root@srx1>
Now comes the process of creating our image. First, insert a USB
thumb drive into port 0. Once you do that, enter in the following:
root@srx1>requestsystemsnapshotpartitionmediausb
This will format the USB drive, create the necessary partitions, and
copy everything that is currently on the device hosting the USB drive. It
might take a few minutes to complete, and your output will look
similar to the following:
Clearingcurrentlabel...
Partitioningusbmedia(/dev/da1)...
Partitionsonsnapshot:
PartitionMountpointSizeSnapshotargument
s1a/altroot2.4Gnone
s2a/2.4Gnone
Recipe 3: Using Snapshot Images for Mass Deployment 31
s3e/config185Mnone
s3f/var2.1Gnone
s4a/recovery/software216Mnone
s4e/recovery/state15Mnone
Copying'/dev/da0s1a'to'/dev/da1s1a'..(thismaytakeafewminutes)
Copying'/dev/da0s2a'to'/dev/da1s2a'..(thismaytakeafewminutes)
Copying'/dev/da0s3e'to'/dev/da1s3e'..(thismaytakeafewminutes)
Copying'/dev/da0s3f'to'/dev/da1s3f'..(thismaytakeafewminutes)
Copying'/dev/da0s4e'to'/dev/da1s4e'..(thismaytakeafewminutes)
Copying'/dev/da0s4a'to'/dev/da1s4a'..(thismaytakeafewminutes)
Thefollowingfilesystemswerearchived:/altroot//config/var/recovery/state/
recovery/software
Once this process has completed, and you are returned to your
prompt, you can now remove the USB drive.
Its essentially telling the device to boot off of the image stored on the
USB drive. Once it has booted up, log in using the credentials that you
supplied when you initally configured the image on the first device, and
enter operational mode.
Now that you are running off of the image, you need to copy it from
the USB drive onto the internal hard drive. Do this by entering the
following command at the operational mode prompt:
root@srx1>requestsystemsnapshotmediainternalpartition
This will start the image copy process and might take a few minutes to
complete. When it has finished, you should see output similar to:
Clearingcurrentlabel...
Partitioninginternalmedia(/dev/da0)...
Partitionsonsnapshot:
32 Day One: Juniper Ambassadors Cookbook for Enterprise
PartitionMountpointSizeSnapshotargument
s1a/altroot610Mnone
s2a/617Mnone
s3e/config46Mnone
s3f/var618Mnone
s4a/recovery/software56Mnone
s4e/recovery/state5.7Mnone
Copying'/dev/da1s1a'to'/dev/da0s1a'..(thismaytakeafewminutes)
Copying'/dev/da1s2a'to'/dev/da0s2a'..(thismaytakeafewminutes)
Copying'/dev/da1s3e'to'/dev/da0s3e'..(thismaytakeafewminutes)
Copying'/dev/da1s3f'to'/dev/da0s3f'..(thismaytakeafewminutes)
Copying'/dev/da1s4e'to'/dev/da0s4e'..(thismaytakeafewminutes)
Copying'/dev/da1s4a'to'/dev/da0s4a'..(thismaytakeafewminutes)
Thefollowingfilesystemswerearchived:/altroot//config/var/recovery/state/
recovery/software
Once the image is copied onto the device, you can now boot off of the
internal storage, the normal way the device does. Since you are cur-
rently booted-off of the USB drive, you need to tell the device to boot
off of internal storage:
root@srx1>requestsystemrebootmediainternal
Once the device has booted up, you can now log in and verify that the
configuration is exactly the same as when you initially configured the
image.
You can now safely remove the USB drive from your device.
And as you can see, in just a few steps you were able to quickly set up a
new device with a default configuration that you specified a huge
help in mass deployments, where a lot of the configuration will be
similar across all of your devices.
Problem
Due to its popularity, theres a growing need for redundancy in
IPsec VPN type connections. For instance, a failover should
ideally occur within a second when a VPN is carrying VoIP or
Video and the primary link is lost. Junos has good solutions for
VPN redundancy and some of them will be discussed here, but the
focus of this solution is on redundancy, and details or explana-
tions on how to configure VPNs can be found elsewhere, either
online, at Juniper Techpubs (www.juniper.net/techpubs), or in the
Day One library of books (www.juniper.net/dayone).
Solution
Lets set the stage with an example where two networks are
connected over two separate ISPs. ISP1 is primary, and ISP2 is
used as a backup.
threshold3;
}
proposalesp-aes128-sha2{
protocolesp;
encryption-algorithmaes-256-cbc;
lifetime-seconds3600;
}
policyipsec-srx1-srx2-policy{
perfect-forward-secrecy{
keysgroup5;
}
proposalsesp-aes128-sha2;
}
vpnvpn-srx2-over-ISP1{
bind-interfacest0.0;
vpn-monitor;
ike{
gatewaysrx-2-over-ISP1;
ipsec-policyipsec-srx1-srx2-policy;
}
establish-tunnelsimmediately;
}
vpnvpn-srx2-over-ISP2{
bind-interfacest0.1;
vpn-monitor;
ike{
gatewaysrx-2-over-ISP2;
ipsec-policyipsec-srx1-srx2-policy;
}
establish-tunnelsimmediately;
}
}
}
gatewaysrx-1-over-ISP2{
ike-policysrx1-srx2-policy;
address2.2.2.1;
external-interfacege-0/0/1;
}
}
ipsec{
vpn-monitor-options{
interval2;
threshold3;
}
proposalesp-aes128-sha2{
protocolesp;
encryption-algorithmaes-256-cbc;
lifetime-seconds3600;
}
policyipsec-srx1-srx2-policy{
perfect-forward-secrecy{
keysgroup5;
}
proposalsesp-aes128-sha2;
}
vpnvpn-srx1-over-ISP1{
bind-interfacest0.0;
vpn-monitor;
ike{
gatewaysrx-1-over-ISP1;
ipsec-policyipsec-srx1-srx2-policy;
}
establish-tunnelsimmediately;
}
vpnvpn-srx1-over-ISP2{
bind-interfacest0.1;
vpn-monitor;
ike{
gatewaysrx-1-over-ISP2;
ipsec-policyipsec-srx1-srx2-policy;
}
establish-tunnelsimmediately;
}
}
On both SRX devices the tunnel interfaces (st0.0 and st0.1) are placed
in a zone called vpn, and security policies allow traffic from VPN to
trust and vice-versa. Of course, host-inbound-traffic system-service
IKE is allowed on the untrust zone:
root@SRX-1#showsecurityzonessecurity-zonevpn
host-inbound-traffic{
system-services{
traceroute;
ping;
}
}
Recipe 4: Redundant VPN with Fast Failover 37
interfaces{
st0.0;
st0.1;
}
root@SRX-1#showsecuritypoliciesfrom-zonetrustto-zonevpn
policytrust-vpn{
match{
source-addressany;
destination-addressany;
applicationany;
}
then{
permit;
}
}
root@SRX-1#showsecuritypoliciesfrom-zonevpnto-zonetrust
policyvpn-trust{
match{
source-addressany;
destination-addressany;
applicationany;
}
then{
permit;
}
}
To make sure the IKE traffic follows two different ISPs, a static routing
entry for the outside of the tunnel is added to the config, overwriting
the IKE destination with a /32 route:
root@SRX-1#showrouting-options
static{
route0.0.0.0/0next-hop1.1.1.2;
route4.4.4.1/32next-hop2.2.2.2;
}
Of course on SRX-2, 4.4.42 is used as next-hop to reach 2.2.2.1, the
outgoing IKE address of SRX-1.
Take a good look at the IPsec configuration of both devices. You will
see that ipsec-monitoring is set to a threshold of 3 and an interval of 2
seconds. This results in the interface going to the down state when the
VPN is down in 6 seconds (threshold multiplied by interval). This
behavior is used to set up the following static routing on the devices:
SRX-1
root@SRX-1#showrouting-options
static{
route0.0.0.0/0next-hop1.1.1.2;
route4.4.4.1/32next-hop2.2.2.2;
route192.168.2.0/24{
next-hopst0.0;
38 Day One: Juniper Ambassadors Cookbook for Enterprise
qualified-next-hopst0.1{
metric10;
}
}
}
SRX-2
root@srx-2#showrouting-options
static{
route0.0.0.0/0next-hop3.3.3.2;
route2.2.2.1/32next-hop4.4.4.2;
route192.168.1.0/24{
next-hopst0.0;
qualified-next-hopst0.1{
metric10;
}
}
}
The route over st0.0 is preferred, so the traffic is sent over VPN1 when
this VPN is up. When the VPN monitor notices the VPN is down, the
route becomes inactive, and the next route (using VPN2) becomes
active. Lets take a look at the routing table to see this happening:
root@SRX-1>showroute192.168.2/24
inet.0:13destinations,14routes(13active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.2.0/24*[Static/5]00:00:11
>viast0.0
[Static/5]00:00:11,metric10
>viast0.1
Now, lets start a ping from SRX-1 to SRX-2 and force a problem in
ISP1 after four pings:
root@SRX-1>ping192.168.2.1
PING192.168.2.1(192.168.2.1):56databytes
64bytesfrom192.168.2.1:icmp_seq=0ttl=64time=2.642ms
64bytesfrom192.168.2.1:icmp_seq=1ttl=64time=8.518ms
64bytesfrom192.168.2.1:icmp_seq=2ttl=64time=3.509ms
64bytesfrom192.168.2.1:icmp_seq=3ttl=64time=2.381ms
64bytesfrom192.168.2.1:icmp_seq=11ttl=64time=2.267ms
64bytesfrom192.168.2.1:icmp_seq=12ttl=64time=2.480ms
Now when ISP1 has a major problem (say the patch cable falls out of
the Ethernet port, somehow) it missed eight pings before the fallback
to the second VPN took over. (Check the sequence number to confirm
this fact!) The routing table now shows this (everything is shown from
SRX-1 but the same thing is happening on SRX-2 of course).
Recipe 4: Redundant VPN with Fast Failover 39
root@SRX-1>showroute192.168.2/24
inet.0:10destinations,10routes(10active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.2.0/24*[Static/5]00:05:13,metric10
>viast0.1
The solutions with VPN monitoring work, but not within the desired
time. Lets look for a faster solution.
Introducing BFD
Bidirectional Forwarding Detection (BFD) is an open standard protocol
for link monitoring. It sends a stream of packets from both sides and
allows for a threshold of missed packets. When the threshold is reached,
a upper level routing protocol is notified of the problem and is triggered
to come into action. This upper level protocol can be BGP, OSPF, static
routing, or many others. Lets first take a look at static routes, since a lot
is already in place in the config to do so.
On some hardware platforms the BFD processing is distributed to the
PFE, allowing for an interval of 100ms between the packet. On SRXs,
the BFD sessions are handled by the RE so you should be careful with
intervals that are too fast and with too many BFD sessions. Its recom-
mended not to go below 300ms for RE-based BFD sessions, so lets be
sure not to do that. One thing to change is the static routes. Until now it
was only mentioned that the tunnel interface was next-hop. For BFD you
need a local and a remote IP address. The local address comes from the
interface IP address, and the next-hop is used for the remote address.
The BFD configuration looks like the following:
SRX-1
root@srx-2#showrouting-optionsstatic
route0.0.0.0/0next-hop1.1.1.2;
route4.4.4.1/32next-hop2.2.2.2;
route192.168.2.0/24{
next-hop172.16.128.2;
qualified-next-hop172.16.128.6{
metric10;
}
bfd-liveness-detection{
minimum-interval300;
}
}
40 Day One: Juniper Ambassadors Cookbook for Enterprise
SRX-2
root@srx-2#showrouting-optionsstatic
route0.0.0.0/0next-hop3.3.3.2;
route2.2.2.1/32next-hop4.4.4.2;
route192.168.1.0/24{
next-hop172.16.128.1;
qualified-next-hop172.16.128.5{
metric10;
}
bfd-liveness-detection{
minimum-interval300;
}
}
2sessions,2clients
Cumulativetransmitrate6.7pps,cumulativereceiverate6.7pps
Clearly, BFD is up and running! Lets check the routing table and
failover once again:
root@SRX-1>showroute192.168.2/24
inet.0:13destinations,14routes(13active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.2.0/24*[Static/5]00:15:58
>to172.16.128.2viast0.0
[Static/5]00:21:12,metric10
>to172.16.128.6viast0.1
Recipe 4: Redundant VPN with Fast Failover 41
Routing is okay! Now lets ping and check again to see if theres a
problem after the fourth packet:
root@SRX-1>ping192.168.2.1
PING192.168.2.1(192.168.2.1):56databytes
64bytesfrom192.168.2.1:icmp_seq=0ttl=64time=2.532ms
64bytesfrom192.168.2.1:icmp_seq=1ttl=64time=2.397ms
64bytesfrom192.168.2.1:icmp_seq=2ttl=64time=2.389ms
64bytesfrom192.168.2.1:icmp_seq=3ttl=64time=2.343ms
64bytesfrom192.168.2.1:icmp_seq=5ttl=64time=2.277ms
64bytesfrom192.168.2.1:icmp_seq=6ttl=64time=2.384ms
64bytesfrom192.168.2.1:icmp_seq=7ttl=64time=2.308ms
So we only missed one ping ! Thats more like it! Using BFD really does
the trick.
It might be a good idea to use OSPF instead of static routing OSPF
also supports BFD, so no problem here. You could place the local LAN
interface in passive mode and just make the tunnel interfaces active.
Using OSPF could save you a lot of static routes, especially on larger
VPNs, and BFD assures a fast recovery from broken VPN tunnels. The
configuration for basic OSPF would look like this (note OSPF is added
as host-inbound-traffic protocol):
SRX-1
root@SRX-1#showsecurityzonessecurity-zonevpn
host-inbound-traffic{
system-services{
traceroute;
ping;
}
protocols{
bfd;
ospf;
}
}
interfaces{
st0.0;
st0.1;
}
root@SRX-1#showprotocolsospf
area0.0.0.0{
interfacest0.0{
metric10;
bfd-liveness-detection{
minimum-interval300;
}
}
interfacest0.1{
metric20;
42 Day One: Juniper Ambassadors Cookbook for Enterprise
bfd-liveness-detection{
minimum-interval300;
}
}
interfacevlan.0{
passive;
}
}
SRX-2
root@srx-2#showsecurityzonessecurity-zonevpn
host-inbound-traffic{
system-services{
traceroute;
}
protocols{
bfd;
ospf;
}
}
interfaces{
st0.0;
st0.1;
}
root@srx-2#showprotocolsospf
area0.0.0.0{
interfacest0.0{
metric10;
bfd-liveness-detection{
minimum-interval300;
}
}
interfacest0.1{
metric20;
bfd-liveness-detection{
minimum-interval300;
}
}
interfacevlan.0{
passive;
}
}
NOTE To make sure ISP1 is preferred, make the cost for the link over ISP2
higher.
Recipe 4: Redundant VPN with Fast Failover 43
For the last time, lets take a look at the routing table:
root@SRX-1>showroute192.168.2/24
inet.0:14destinations,16routes(14active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.2.0/24*[OSPF/10]00:07:29,metric11
>viast0.0
root@SRX-1>ping192.168.2.1
PING192.168.2.1(192.168.2.1):56databytes
64bytesfrom192.168.2.1:icmp_seq=0ttl=64time=2.466ms
64bytesfrom192.168.2.1:icmp_seq=1ttl=64time=2.357ms
64bytesfrom192.168.2.1:icmp_seq=2ttl=64time=2.263ms
64bytesfrom192.168.2.1:icmp_seq=3ttl=64time=2.410ms
64bytesfrom192.168.2.1:icmp_seq=5ttl=64time=2.443ms
64bytesfrom192.168.2.1:icmp_seq=6ttl=64time=2.410ms
64bytesfrom192.168.2.1:icmp_seq=7ttl=64time=2.423ms
^C
---192.168.2.1pingstatistics---
8packetstransmitted,7packetsreceived,12%packetloss
round-tripmin/avg/max/stddev=2.263/2.396/2.466/0.063ms
So with OSPF only one packet is lost, and there are a lot of other
advantages. Finally, lets take a look at the route table in the fault
situation:
root@SRX-1>showroute192.168.2.0
inet.0:12destinations,14routes(12active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.2.0/24*[OSPF/10]00:04:55,metric21
>viast0.1
As you can see, the metric is 21 where on the primary link it was 11. So
our cost manipulation worked.
Summary
The SRX offers a nice way to set up redundancy in VPN links with its
support of the open standard BFD protocol.
44 Day One: Juniper Ambassadors Cookbook for Enterprise
Recipe 5
Problem
Branch offices that connect to the corporate network using
Internet VPN have direct internet access and a secured tunnel to
the private corporate network, which can create a split tunnel
situation where the default route for the branch uses the Internet
and only specified routes traverse the private VPN. A split tunnel
can create two difficulties:
Local Internet access can bypass proxy servers and other
security and compliance engines for Internet access on the
corporate network.
The routes used on the VPN tunnel to access various
corporate subnets need to be maintained over time.
Solution
To solve this predicament, the branch office LAN is configured in
a routing instance so that the default route for all traffic on the
LAN becomes the VPN tunnel. Ensuring that any and all traffic
destined outside the branch LAN resources gets forwarded to the
corporate infrastructure and uses the corporate Internet service,
security, and compliance configurations. It also ensures that no
matter how the corporate network changes over time, traffic from
the branch site will be forwarded to the corporate VPN.
46 Day One: Juniper Ambassadors Cookbook for Enterprise
NOTE This recipe was tested on a SRX100 using Junos 11.4r5.5. And note
that all configuration statements are shown as they would be entered
on the branch device.
Recipe 5: Branch VPN Without Local Internet Access 47
setinterfacesfe-0/0/0unit0familyinetaddress1.1.1.2/24
Now set the default route for our local Internet service in the primary
routing instance:
setrouting-optionsstaticroute0.0.0.0/0next-hop1.1.1.1
Place this gateway interface into the untrust zone in the primary
routing instance.
setsecurityzonessecurity-zoneuntrustinterfacesfe-0/0/0.0
Now, allow management services on this interface for the VPN ike
connections. You can also allow other management services as needed
on this interface, but the ike services are required for the VPN connec-
tion to establish (since this is an Internet-facing interface, you want to
limit the other system services you allow for now).
setsecurityzonessecurity-zoneuntrusthost-inbound-trafficsystem-servicesike
Next, configure the remote gateway ike parameters for policy and
preshared key. Naturally, these parameters must match the configura-
tion at the corporate site where the VPN is established.
setsecurityikepolicyike-policy1modemain
setsecurityikepolicyike-policy1proposal-setstandard
setsecurityikepolicyike-policy1pre-shared-keyascii-text"sharedsecret"
Then use this policy to create the IPsec phase 2 connection and tie this
to the tunnel interface created above.
setsecurityipsecvpnike-vpnikegatewayike-gate
setsecurityipsecvpnike-vpnikeipsec-policyvpn-policy1
setsecurityipsecvpnike-vpnbind-interfacest0.10
Finally, set the vpn mtu to the most common value. This prevents
fragmentation of traffic across the tunnel.
setsecurityflowtcp-mssipsec-vpnmss1350
Recipe 5: Branch VPN Without Local Internet Access 49
References
Problem
OSPF is one of the most popular Interior Gateway Protocols in
use today because this IGP is an open standard supported by
many vendors. Configuring OSPF to build a simple network is
relatively straightforward. Unfortunately, however, attackers can
use this ease of configuration to compromise your network or
deny services to your organization. Thankfully, OSPF also
includes security mechanisms to protect your network and
including this option in your OSPF configuration just makes good
sense. This recipe goes through the types of OSPF security, how to
enable them under Junos, and shows you how to establish a
secure neighbor relationship with a device running IOS.
Solution
In this recipes example solution, there are two routers, a J2320 and a
router running IOS, connected via a broadcast network across OSPF
Area 0.0.0.0 via interfaces ge-0/0/0.0 and fa0/0, respectively, as shown
in Figure 6.1. In addition, the J2320 has an interface in Area 0.0.0.2
and the IOS device has an interface in Area 0.0.0.1. No other routers
are located in the non-backbone areas.
The first task is to enable OSPF on the relevant interfaces, and in IOS,
add the appropriate network commands. The configuration would be
as follows, first Junos, then IOS:
[edit protocols]
root@J2320# show
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
}
area 0.0.0.2 {
interface ge-0/0/1.0;
}
}
Once OSPF is enabled, you should see the following entry in the log
file:
rpd[1210]: RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.2 (realm ospf-v2 ge-0/0/0.0 area
0.0.0.0) state changed from Loading to Full due to LoadDone (event reason: OSPF loading
completed)
Recipe 6: Configuring OSPF Security 53
For the purpose of this recipe, lets first use a simple password configu-
ration and then compare it to the authentication option. Begin on the
J2320 and enter the following in the top command:
set protocols ospf area 0 interface ge-0/0/0.0 authentication simple-password i<3junos
Once we commit this configuration, you are going to lose the neighbor
relationship when the dead timer expires. An error similar to the one
shown here will be entered into the messages log file, indicating a lost
neighbor:
J2320 rpd[1210]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.2 (realm ospf-v2 ge-0/0/0.0
area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason:
neighbor was inactive and declared dead)
54 Day One: Juniper Ambassadors Cookbook for Enterprise
NOTE Although the password is encrypted, the actual OSPF Link State
Advertisements and Requests are still sent in an unencrypted format.
Remember, the purpose of the security is to prevent unwanted neigh-
bor relationships, not to hide the advertised subnet information.
Enabling this more secure form of encryption isnt much more compli-
cated than the simple password method, at least, not as far as Junos is
concerned. The first step would be to remove the simple password
configured previously, done thusly:
edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0
delete authentication
At this point you should lose connectivity with the IOS neighbor, so
you need to remove the simple password authentication on the IOS
device:
Int fa0/0
no ip ospf authentication-key
router ospf 1
no area 0 authentication
Recipe 6: Configuring OSPF Security 55
Once entered, you should see the message in the log file stating you
have a relationship, and see the IOS router as a neighbor using the
Junos show ospf neighbor command.
Once you have enabled security on the interfaces in the backbone area,
realize the interfaces in Area 0.0.0.1 and Area 0.0.0.2 are not secure,
and an attacker could place a router on the switch in either of these
areas and flood advertisements for nonexistent subnets.
While you could use the same authentication option, recall from the
topology that there are no routers in these areas. OSPF must be
enabled in those interfaces for those networks to be advertised, but you
can set these interfaces to be what is known as passive. This means that
the interfaces do not send advertisements out of those interfaces, but
do advertise the connected subnets.
Enabling this option within Junos is done like this:
edit protocols ospf area 0.0.0.2 interface ge-0/0/1.0
set passive
commit
Now confirm that these networks are now being advertised to their
neighbors and appear on the routing table, simply by running the show
route command:
root@J2320>showroute
inet.0:6destinations,6routes(6active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
10.10.10.0/24*[Direct/0]02:42:23
>viage-0/0/0.0
10.10.10.1/32*[Local/0]02:42:23
Localviage-0/0/0.0
10.20.20.0/24*[Direct/0]00:02:50
>viage-0/0/1.0
10.20.20.1/32*[Local/0]00:09:18
Localviage-0/0/1.0
10.30.30.0/24*[OSPF/10]00:01:52,metric2
>to10.10.10.2viage-0/0/0.0
56 Day One: Juniper Ambassadors Cookbook for Enterprise
224.0.0.5/32*[OSPF/10]02:37:10,metric1
MultiRecv
You can also confirm that you are able to ping the interface in Area
0.0.0.1 from a device in Area 0.0.0.2 by specifying the source <ip
address> after the ping command:
Problem
How do you ensure that a device logging onto your network has the
proper configuration and level of access? Network administrators
face a constant dilemma between providing comprehensive access
to network resources, while still providing adequate protection.
The Juniper remote access and access control platforms are able to
differentiate between a healthy corporate device, one which is
missing patches, and a totally unknown device. Once the device has
been classified, policies can be applied accordingly.
Solution
The Juniper Secure Access, MAG, and Unified Access Controllers
provide dynamic access control, whereby polices are created which
match users to a set of permissible resources such as Web links,
Terminal Servers, or entire subnets. Resource management differs
between the Secure Access and Unified Access Controllers, but the
host check function works in the same manner on both platforms.
Beyond a simple access control list, technologies based upon the
IVE platform are also able to factor in the status and type of
connections on the connecting endpoint.
58 Day One: Juniper Ambassadors Cookbook for Enterprise
4. Scroll down to the Policies section and click the New button.
5. The screen will update and prompt for a policy name. Set the name
as Corporate_Build and select the Continue button
6. This will create a blank policy. Note the tabs which specify different
policies for the various supported Host Checker platforms. From the
drop-down box in the Rule Settings Section, select Custom:File and
click Add to create a new rule.
Recipe 7: Understanding the Host Checker 61
8. The Policy window should update with the newly created rule. In
the Remediation section tick the box next to Enable Custom
Instructions. This allows the system administrator to provide the
enduser with more detailed information or links to a support web site.
Enter text to describe the error message to the user and click Save at
the bottom of the screen.
62 Day One: Juniper Ambassadors Cookbook for Enterprise
2. Navigate to the Authentication Policy tab and the Host Check tab
underneath that. All the available host check polices will be listed.
There are two options for each policy:
Evaluate Policies: When a user attempts to access this Realm, the
host checker will assess the endpoint Post authentication.
Require and Enforce: When a user attempts to access a Realm
with Enforce enabled, the endpoint assessment will be performed
Pre authentication. If the endpoint fails the assessment, they will
be denied access to the realm entirely.
Select both Evaluate Policies and Require and Enforce on the Corpo-
rate_Build policy and click Save Changes to complete the step.
Recipe 7: Understanding the Host Checker 63
4. If this is the first time the user has attempted to authenticate to the
Secure Access Service, and no provision has been made to deploy the
Juniper Installer service, it is quite likely they will be prompted as to
whether they wish to download and install the host checker package.
The user should select Always to prevent the prompt from reoccurring
on subsequent attempts.
64 Day One: Juniper Ambassadors Cookbook for Enterprise
NOTE The Reason strings is very helpful when debugging a specific error, but
in production it should not enabled as it may provide useful informa-
tion to someone attempting to break into the environment. To disable
the reason strings, return to the Host Checker menu in the Junos Pulse
Secure Access Service administration console and edit the Corporate_
Build Policy. Scroll to the bottom of the Window and remove the tick
from the Send reason strings box and click Save Changes.
Recipe 7: Understanding the Host Checker 65
This will prevent the Secure Access Service from reporting more
information than is necessary.
role only has a single Web bookmark defined, while the Corporate
Users role has numerous enabled resources. Click on the Corporate
Users role.
3. Return to the User Roles page. In the View: drop down box select
the Restrictions option from the list and select the Update button to
change the view. This will show all the roles and any restrictions
placed upon them. In this case, users granted access to the Corporate
Users role must first satisfy the requirements of the Corporate_Build
Host Checker policy.
5. The next stage is grant access to the two roles, one with, and one
without, restrictions. Navigate to the Role Mapping tab of the target
User Authentication Realm. Create a new rule that maps the user or
groups to both roles. Once authentication has been satisfied then the
Secure Access Service will map the user to all roles other than those
with unmet restrictions.
6. Remove the c:\image.txt file from the test workstation and attempt
to authenticate. The user still receives the same Your computers
security is unsatisfactory warning message, but this time is able to
continue to the next stage.
7. Once the user presses the continue button, they are presented with
the resources attached to the Roles they have been granted access to.
In this case the user was only permitted access to resources in the Basic
Users Role.
Recipe 7: Understanding the Host Checker 69
8. Restore the C:\image.txt file and sign-in to the Secure Access service
again. Once the host checks and authentication have been satisfied the
user should have visibility of all the assigned roles and resources.
Problem
As Internet links become less expensive youll see more and more
sites with dual ISP connections. Often this is implemented with a
high quality main link and a (cheaper) backup line. When DSL or
similar connections are used, failure can occur at the WAN side of
a router or DSL modem. A simple backup route in the routing
table doesnt help in this case because the Ethernet side of the
device stays up when the WAN side fails, so our SRX keeps the
main route active. A nice way of solving this problem is track-
ing an upstream device such as the ISPs router.
Solution
On Junos devices you can use the RPM (Realtime Performance
Monitoring: dont get confused RedHat users) implementation to
do the monitoring for you. Now you can set up full RPM with
latency monitoring, or even URL tracking, but you can also set up
a simple tracking with a ping packet. For ISP tracking and
failover this is often enough. Lets build an example.
In the example below RPM and IP-monitoring are shown to react
to a loss over the primary ge-0/0/1 on srxA-1. The failure occurs
not because of a direct connection but because of the loss of
srxA-2 s ge-0/0/3 connection to the Internet.
Things are looking good! The asterisk makes clear 172.19.1.2 is the
active next-hop.While the qualified next-hop to 172.18.1.1 via
ge-0/0/3.0 isnt strictly necessary because the tracking solution installs
a route when the probe fails. Its best practice to see the backup route
during normal operations so you can react more quickly to a local link
(Ethernet) failure.
Lets configure the RPM probe this way using a ICMP (ping) probe in
the services rpm hierarchy:
root@srxA-1#showservicesrpm
probeProbe-Server{
testtestroute{
probe-typeicmp-ping;
targetaddress172.18.2.1;
probe-count3;
probe-interval1;
test-interval1;
thresholds{
successive-loss3;
total-loss3;
}
destination-interfacege-0/0/1.0;
next-hop172.19.1.2;
}
}
So you can see the config is probing three times (probe-count 3) every
second (probe-interval 1) with a ping (probe-type icmp-ping) to
up-stream device 172.18.2.1 . The probe starts again after a second
(test-interval 1). The configuration gives a probe failure after three
missed pings in a row.
Before configuring a reaction to the probe, it might be a good idea to
check on how the probe is doing. With a normally functioning link you
should see this in our recipes topology:
root@srxA-1>showservicesrpmprobe-results
Owner:Probe-Server,Test:testroute
Targetaddress:172.18.2.1,Probetype:icmp-ping
Destinationinterfacename:ge-0/0/1.0
Testsize:3probes
Proberesults:
Responsereceived,MonOct2211:39:452012,Nohardwaretimestamps
Rtt:1984usec
Resultsovercurrenttest:
Probessent:1,Probesreceived:1,Losspercentage:0
Measurement:Roundtriptime
Samples:1,Minimum:1984usec,Maximum:1984usec,Average:1984usec,
Peaktopeak:0usec,Stddev:0usec,Sum:1984usec
Resultsoverlasttest:
Probessent:3,Probesreceived:3,Losspercentage:0
TestcompletedonMonOct2211:39:442012
Measurement:Roundtriptime
74 Day One: Juniper Ambassadors Cookbook for Enterprise
Samples:3,Minimum:1959usec,Maximum:1985usec,Average:1971usec,
Peaktopeak:26usec,Stddev:11usec,Sum:5913usec
Resultsoveralltests:
Probessent:346,Probesreceived:49,Losspercentage:85
Measurement:Roundtriptime
Samples:49,Minimum:1695usec,Maximum:4085usec,Average:2025usec,
Peaktopeak:2390usec,Stddev:336usec,Sum:99228usec
root@srxA-1>showservicesrpmhistory-results
Owner,TestProbereceivedRoundtriptime
Probe-Server,testrouteMonOct2211:39:4420121985usec
Probe-Server,testrouteMonOct2211:39:4520121984usec
Probe-Server,testrouteMonOct2211:39:4620122588usec
Probe-Server,testrouteMonOct2211:39:4720122074usec
..
Now lets create a failure by removing the cable from interface ge-0/0/3
from srxA-2. Now check the results:
root@srxA-1>showservicesrpmprobe-results
Owner:Probe-Server,Test:testroute
Targetaddress:172.18.2.1,Probetype:icmp-ping
Destinationinterfacename:ge-0/0/1.0
Testsize:3probes
Proberesults:
Requesttimedout,MonOct2211:41:112012
Resultsovercurrenttest:
Probessent:1,Probesreceived:0,Losspercentage:100
Resultsoverlasttest:
Probessent:3,Probesreceived:0,Losspercentage:100
Resultsoveralltests:
Probessent:430,Probesreceived:125,Losspercentage:70
Measurement:Roundtriptime
Samples:125,Minimum:1621usec,Maximum:10267usec,
Average:2101usec,Peaktopeak:8646usec,Stddev:934usec,
Sum:262634usec
root@srxA-1>showservicesrpmhistory-results
Owner,TestProbereceivedRoundtriptime
Probe-Server,testrouteMonOct2211:40:3220121946usec
Probe-Server,testrouteMonOct2211:41:032012Requesttimedout
Probe-Server,testrouteMonOct2211:41:052012Requesttimedout
..
Okay, the probe works, so now lets configure how to react to this
failure using services ip-monitoring:
root@srxA-1#showservicesip-monitoring
policyServer-Tracking{
match{
rpm-probeProbe-Server;
}
then{
preferred-route{
Recipe 8: IP Tracking for Dual ISPs on a SRX 75
route0.0.0.0/0{
next-hop172.18.1.1;
}
}
}
}
A failure in the Internet link (pulled cable from srxA-2s ge-0/0/3
interface) issues this after about five seconds:
root@srxA-1>showroute
.
0.0.0.0/0*[Static/1]00:00:15,metric20
>to172.18.1.1viage-0/0/3.0
[Static/5]01:25:36
>to172.19.1.2viage-0/0/1.0
[Static/5]00:23:33,metric100
>to172.18.1.1viage-0/0/3.0
Now, when the probe detects a failure, the ip-monitor installs a route
with a preference of 1. This high preference makes sure our backup is
chosen over every static route (static routes have a default preference
of 5).
The output makes clear our goal of changing a route because of
indirect failure is reached by the config we created.
MORE? For more information about the technology used here please refer to
the links below: http://kb.juniper.net/InfoCenter/index?page=content
&id=KB22052&actp=search&viewlocale=en_
US&searchid=1350650857447. For manual page rpm: http://www.
juniper.net/techpubs/en_US/junos12.1/topics/task/configuration/
rpm-probes-configuring.html.
And for those who dont know how to use load merge relative
terminal, here is the used configuration:
setservicesrpmprobeProbe-Servertesttestrouteprobe-typeicmp-ping
setservicesrpmprobeProbe-Servertesttestroutetargetaddress172.18.2.1
setservicesrpmprobeProbe-Servertesttestrouteprobe-count3
setservicesrpmprobeProbe-Servertesttestrouteprobe-interval1
setservicesrpmprobeProbe-Servertesttestroutetest-interval1
setservicesrpmprobeProbe-Servertesttestroutethresholdssuccessive-loss3
setservicesrpmprobeProbe-Servertesttestroutethresholdstotal-loss3
setservicesrpmprobeProbe-Servertesttestroutedestination-interfacege-0/0/1.0
setservicesrpmprobeProbe-Servertesttestroutenext-hop172.19.1.2
setservicesip-monitoringpolicyServer-Trackingmatchrpm-probeProbe-Server
setservicesip-monitoringpolicyServer-Trackingthenpreferred-
routeroute0.0.0.0/0next-hop172.18.1.1
76 Day One: Juniper Ambassadors Cookbook for Enterprise
Recipe 9
Problem
PIM sparse mode is desired in a multicast network, which
requires a rendezvous-point (RP). The RP can be created statically
or by using a dynamic protocol such as Auto-RP or BSR. Since
Auto-RP requires sparse-dense mode, BSR has been chosen as the
protocol to carry RP information to the routers in the network
The topology for this section consists of four routers connected in
a ring. OSPF area 0 is running between the routers, with the
fe-0/0/2 interfaces included in OSPF (passive). There is a single
multicast sender and a single multicast receiver sending a multi-
cast stream for IPv4 group 239.1.1.1 and IPv6 group FF1E::1.
80 Day One: Juniper Ambassadors Cookbook for Enterprise
Solution
Configuration of BSR in a network is a fairly simple process. A router
acting as the RP should be chosen, as well as a router performing the
BSR duties. The same router can perform both roles (as in this exam-
ple), or separate routers can perform them.
[edit]
root@R1#editprotocolspim
[editprotocolspim]
root@R1#setinterfaceallmodesparse
[editprotocolspim]
root@R2#setrplocalfamilyinet6address2001:db8:2::2222
[editprotocolspim]
root@R2#setrpbootstrapfamilyinetpriority100
[editprotocolspim]
root@R2#setrpbootstrapfamilyinet6priority100
familyinet{
priority100;
}
familyinet6{
priority100;
}
}
local{
familyinet{
address2.2.2.2;
}
familyinet6{
address2001:db8:2::2222;
}
}
}
interfaceall{
modesparse;
}
7. Jump to the top of the hierarchy and commit the configuration. This
step obviously needs to be done on all four routers, but only R1 is
shown here.
[editprotocolspim]
root@R1#top
[edit]
root@R1#commitand-quit
commitcomplete
Exitingconfigurationmode
root@R1>
MORE? Downloading and installing VLC is beyond the scope of this book, but
more information can be found at http://www.videolan.org/vlc/index.
html.
BSRPriLocaladdressPriStateTimeout
2.2.2.21004.4.4.40InEligible126
2001:db8::22221002001:db8::44440InEligible95
root@R2>showpimbootstrap
Instance:PIM.master
BSRPriLocaladdressPriStateTimeout
2.2.2.21002.2.2.2100Elected6
2001:db8::22221002001:db8::2222100Elected34
2. Next, verify that the RPs are discovered by all other routers in the
network. On R1, R3, and R4 the RPs will be learned via bootstrap.
On R2, the RPs will be learned both via bootstrap and via static.
root@R1>showpimrps
Instance:PIM.master
AddressfamilyINET
RPaddressTypeHoldtimeTimeoutGroupsGroupprefixes
2.2.2.2bootstrap1501360224.0.0.0/4
AddressfamilyINET6
RPaddressTypeHoldtimeTimeoutGroupsGroupprefixes
2001:db8:2::2222bootstrap1501040ff00::/8
84 Day One: Juniper Ambassadors Cookbook for Enterprise
root@R2>showpimrps
Instance:PIM.master
AddressfamilyINET
RPaddressTypeHoldtimeTimeoutGroupsGroupprefixes
2.2.2.2bootstrap150None1224.0.0.0/4
2.2.2.2static0None1224.0.0.0/4
AddressfamilyINET6
RPaddressTypeHoldtimeTimeoutGroupsGroupprefixes
2001:db8:2::2222bootstrap150None1ff00::/8
2001:db8:2::2222static0None1ff00::/8
3. Verify on R4 that both the (*,G) RPT and the (S,G) SPT are joined.
The upstream interface should match the IGP next-hop. In this case, it
is ge-0/0/1 towards R2.
root@R4>showpimjoin
Instance:PIM.masterFamily:INET
R=RendezvousPointTree,S=Sparse,W=Wildcard
Group:239.1.1.1
Source:*
RP:2.2.2.2
Flags:sparse,rptree,wildcard
Upstreaminterface:ge-0/0/1.0
Group:239.1.1.1
Source:192.168.10.254
Flags:sparse,spt
Upstreaminterface:ge-0/0/1.0
Instance:PIM.masterFamily:INET6
R=RendezvousPointTree,S=Sparse,W=Wildcard
Group:ff1e::1
Source:*
RP:2001:db8:2::2222
Flags:sparse,rptree,wildcard
Upstreaminterface:ge-0/0/1.0
Group:ff1e::1
Source:2001:db8:10::254
Flags:sparse,spt
Upstreaminterface:ge-0/0/1.0
4. Verify the PIM joins on R2. Again, there should be both an RPT and
an SPT join. Since this router is the RP, the upstream interface for the
(*,G) RPT is Local. Also, the upstream interface for the (S,G) RPT
once again follows the IGP next-hop, towards R1.
root@R2>showpimjoin
Instance:PIM.masterFamily:INET
R=RendezvousPointTree,S=Sparse,W=Wildcard
Recipe 9: Configuring Multicast With BSR 85
Group:239.1.1.1
Source:*
RP:2.2.2.2
Flags:sparse,rptree,wildcard
Upstreaminterface:Local
Group:239.1.1.1
Source:192.168.10.254
Flags:sparse,spt
Upstreaminterface:ge-0/0/0.0
Instance:PIM.masterFamily:INET6
R=RendezvousPointTree,S=Sparse,W=Wildcard
Group:ff1e::1
Source:*
RP:2001:db8:2::2222
Flags:sparse,rptree,wildcard
Upstreaminterface:Local
Group:ff1e::1
Source:2001:db8:10::254
Flags:sparse,spt
Upstreaminterface:ge-0/0/0.0
5. Now verify the PIM joins on R1. Notice that on this router there are
no (*,G) RPT joins. That is because this router is directly connected to
the source (SNDR) and therefore has no reason to join the RPT.
root@R1>showpimjoin
Instance:PIM.masterFamily:INET
R=RendezvousPointTree,S=Sparse,W=Wildcard
Group:239.1.1.1
Source:192.168.10.254
Flags:sparse,spt
Upstreaminterface:fe-0/0/2.0
Instance:PIM.masterFamily:INET6
R=RendezvousPointTree,S=Sparse,W=Wildcard
Group:ff1e::1
Source:2001:db8:10::254
Flags:sparse,spt
Upstreaminterface:fe-0/0/2.0
Discussion
When deciding which protocol to run in order to distribute informa-
tion about the RP in a PIM Sparse-Mode network, a number of factors
should be considered.
Static RP configurations are simple, but require significant
management overhead. If a change in RP address is required, an
administrator must change the RP address on every router.
It must be decided whether there should be any dense-mode
groups configured on the network. Auto-RP runs in a sparse-
mode environment, but requires a pair of multicast groups to
operate in dense mode in order to distribute information about
the location of the RP. This may not be desirable.
BSR provides a standards-based protocol (RFC 5059) that is easy
to configure, has low maintenance, and scales well.
More Information
Problem
How do you provide on-network access for remote users while
ensuring that they get the best user experience? Can Network
Connect and Junos Pulse provide fine-grain control over resourc-
es access, how traffic is handled, and how connection parameters
are negotiated?
Discussion
The Juniper Secure Access and MAG (the IVE platform) have two
distinct Layer 3 VPN clients: Network Connect and the Junos
Pulse Client. Network Connect is typically used in portal-inte-
grated deployments while Pulse is used as a standalone desktop-
integrated application.
This recipe walks you through the fundamental principles behind
the resource policies used by Network Connect and the Junos
Pulse Client, explaining how the policies interact to control the
connectivity a user receives. There are several factors to consider
when setting up VPN Tunneling policies, so lets create a simple
policy to allow a user access to specific subnets. There are four
different policies used by Network Connect and Pulse, two of
which are mandatory.
88 Day One: Juniper Ambassadors Cookbook for Enterprise
4. Give the policy a descriptive name such as Pulse Access Only and
provide some detail in the Description field.
5. In the resources field, itemize the protocols (TCP, UDP, ICMP) the
resources (either as host IP or subnets) and the ports that they are able
to access. For example, the following policy will permit access to all
TCP ports on the 172.16.10.0 network, the UDP ports 53 and 1812
on the host 172.16.11.10, and ICMP (Ping) to any other host:
tcp://172.16.10.0/24:*
udp://172.16.11.10:53,1812
icmp://*:*
7. You should be returned to the Access Control menu with the newly
created policy listed first. Remember to delete or otherwise disable
Initial Network Connect Policy a more restrictive policy may be
ineffective.
NOTE Make sure that the IP address range allocated is not used by any other
network device or DHCP server, or else users will experience intermit-
tent connectivity issues.
Recipe 10: Optimizing VPN Tunneling Resource Policies 91
3. Leave the IPv6 addresses assignment window blank unless you are
actively rolling out IPv6 in your network.
4. Scroll down to the Connection Settings section. In most cases, the
connection should be set to use ESP as the default, but its worth
reading the sidebar for a full discussion on this configuration setting.
5. Scroll down to the DNS settings section. By default, Network
Connect and Junos Pulse clients will be issued the same DNS servers
configured under the Network and Overview page on the IVE. You
can optionally choose to override these settings on a per-connection
profile basis, or force the clients to use DHCP server-provided DNS
settings.
6. Scroll to the bottom of the window. In the Proxy Server settings the
browser behavior can be changed to force web requests to use a
specific Web Proxy, use a PAC file for automatic configuration, or
disable proxy connections entirely.
7. In the Roles section, select the Policies applies to SELECTED roles
radio button and specify which roles this connection profile should
apply to, otherwise leave as Policy applies to ALL roles. Click Save
Change to commit the configuration.
92 Day One: Juniper Ambassadors Cookbook for Enterprise
Both Network Connect and the Junos Pulse Client support ESP
failback mode. At the start of the session, user authentication and
authorization are conducted over an encrypted SSL connection. Once
the user starts Network Connect or Pulse via the portal or stand-alone
launcher, a separate point-to-point link is created.
In order to provide the best compromise between performance and
compatibility, two distinct tunnel modes are employed: SSL and ESP. In
SSL mode the connection is tunneled over a Secure Sockets Layer
connection to TCP port 443 on the IVE platform. In ESP mode a
tunnel is established using the Encapsulated Security Protocol (bulk
encryption algorithm used by IKE) to UDP 4500. Each mode operates
more effectively in specific scenarios. For example:
Recipe 10: Optimizing VPN Tunneling Resource Policies 93
NOTE This policy should not be used to provide fine-grain control over
connecting clients as this is the job of the Access policy discussed
earlier in this recipe.
Recipe 10: Optimizing VPN Tunneling Resource Policies 95
3. Unless you wish to apply this policy to a specific role, leave the
selection as Policy applies to ALL roles and click Save Changes to
commit the configuration.
4. This should return the browser to the Split-Tunneling menu.
Further configuration is required before split tunneling can be enabled,
and this is covered in a later section.
2. Navigate to the VPN Tunneling tab and then to the Options tab.
Enable Split Tunneling to allow the connecting client to simultane-
ously enable access to the corporate network and the Internet.
2. Open the connecting client and view Advanced Details for the
connection. This should be the same information as above.
100 Day One: Juniper Ambassadors Cookbook for Enterprise
Recipe 11
MORE? This recipe guides you through creating your first script. It is
beyond the scope of the recipe to provide details on the numerous
options and possible alternative solutions available, so for further
study, see the Resources section at the end of this recipe.
Discussion
In this recipe, you will create a script that issues several operation-
al-mode commands and writes output to the display. The idea is
to create a customizable version of a Junos request support
information command that you will be able to easily expand. To
start, you will create a script that issues three commands:
show chassis hardware detail
show version
show system storage
In Figure 11.1, you are logged in to a Junos device (an EX4200 switch,
in this case) with WinSCP using SCP protocol (it allows secure file
transfer via SSH channel, usually using standard SSH port number
Recipe 11: Creating a Simple Junos Op Script 103
22). In the left panel is your local PC or laptop, in the right panel is the
Junos filesystem. Navigate to /var/db/scripts/op and create a new file
my-op-script.slax (to do this, right-click and select New -> File).
Double-click the newly created file to edit it directly on the box.
NOTE Do not forget to save the file every time you want to run the edited
script. Use the Save button or press Ctrl-S on your keyboard.
Here is how your script my-op-script.slax may look to perform the tasks
outlined in the Problem section. The lines are numbered for further
referencing.
(01)version1.0;
(02)nsjunos="http://xml.juniper.net/junos/*/junos";
(03)nsxnm="http://xml.juniper.net/xnm/1.1/xnm";
(04)nsjcs="http://xml.juniper.net/junos/commit-scripts/1.0";
(05)
(06)import"../import/junos.xsl";
(07)
(08)match/{
(09)<op-script-results>{
(10)
(11)<output>"*****Chassishardware:*****";
(12)var$cmd1=<command>'showchassishardwaredetail';
(13)copy-of(jcs:invoke($cmd1));
(14)
(15)<output>;
(16)<output>"*****Version:*****";
(17)var$cmd2=<command>'showversion';
(18)copy-of(jcs:invoke($cmd2));
(19)
(20)<output>;
(21)<output>"*****Systemstorage:*****";
(22)var$cmd3=<command>'showsystemstorage';
(23)copy-of(jcs:invoke($cmd3));
(24)}
(25)}
Lines (01-04) of the script are a recommended header that are likely
the same for most of Junos scripts, as they define the SLAX version and
commonly used namespaces.
Line (06) imports a file with several very useful templates (subroutines)
that you can use while writing your script. Although you may skip this
line in our example script, this is part of a recommended header, so it is
wise to leave it as is.
Line (08) is a start of the main template of the script, defining its entry
point. Junos scripts are based on XML, and every script is actually
working with two XML documents: input document and output one.
The match / just means that it starts our script once the root node ( / )
of the input XML document is found.
104 Day One: Juniper Ambassadors Cookbook for Enterprise
NOTE An alternative way to get the required XML RPC for the command
would be to issue the following Junos command:
showchassishardwaredetail|displayxmlrpc
... and assign the corresponding XML output to $cmd1 variable. See the
resources referenced at the end of this recipe for more details.
Line (13) uses the function jcs:invoke() to actually run the command
corresponding to $cmd1 variable (i.e., show chassis hardware detail).
Its output is redirected to the user (output XML document) with
copy-of statement.
Line (15) creates an empty line.
Further code basically repeats lines (11-13) for the other two com-
mands that this recipe is using the script to issue.
After you enter this script and save it (or copy the file from a remote
location to /var/db/scripts/op), you need to allow Junos to run the
script by using configuration-mode commands:
{master:0}[edit]
lab@exC-1#setsystemscriptsopfilemy-op-script.slax
{master:0}[edit]
lab@exC-1#commit
Now run the script with op <filename> command and see the output
(some of it is skipped to save space):
lab@exC-1>opmy-op-script
*****Chassishardware:*****
Hardwareinventory:
ItemVersionPartnumberSerialnumberDescription
ChassisBM0291313274EX4200-24T
RoutingEngine0REV13750-033065BM0291313274EX4200-24T,8POE
...
Recipe 11: Creating a Simple Junos Op Script 105
*****Version:*****
fpc0:
--------------------------------------------------------------------------
Hostname:exC-1
Model:ex4200-24t
JUNOSBaseOSboot[11.4R7.5]
...
*****Systemstorage:*****
fpc0:
--------------------------------------------------------------------------
FilesystemSizeUsedAvailCapacityMountedon
/dev/da0s2a183M100M68M60%/
devfs1.0K1.0K0B100%/dev
...
As you can see, the output of all three commands is displayed, with
only one operators command so automation is indeed happening as
promised.
NOTE If you would like to see the scripts XML output (i.e., the output XML
document that is created by the script and sent to Junos CLI for
processing), issue the command:
opmy-op-script|displayxml
Summary
You may have noticed that Junos configuration looks more like a
programming language than just a list of settings. Junos scripts are a
method to go even further with Junos, creating your own commands
and adding more intelligence in the way that you want.
106 Day One: Juniper Ambassadors Cookbook for Enterprise
Resources
http://www.juniper.net/techpubs/en_US/junos12.1/information-
products/topic-collections/config-guide-automation/config-guide-
automation.pdf
http://www.juniper.net/us/en/community/junos/script-automation/
library/
Recipe 12
Problem
As shown in Figure 12.1, the SRX has two Internet connections:
ISP1 on interface ge-0/0/1; and, ISP2 on interface ge-0/0/2. The
remote host needs to be able to initiate telnet connections to the
Internal host server protected by the SRX firewall (in this setup,
well test with IP address 7.7.7.7 for the remote host, but the same
should work with any remote IP).
NOTE The labs setup uses telnet (TCP port 23) as a service that is
provided by an internal host, however, the configuration will be
very similar for any other service such as HTTP, HTTPS, or SSH.
NOTE Interface addresses 1.1.1.1 and 2.2.2.2 are used for providing access to
the internal server, because it is a common situation that ISPs provide
only one public IP address to their customers.
The task is completed once you are able to telnet to 1.1.1.1 and 2.2.2.2
from 7.7.7.7 and get access to the internal host.
CAUTION You should be careful when opening access to your internal resources
in such a manner and make sure non-legitimate users dont get access
to your data. One possible way to achieve this is to make sure that
external users are properly authenticated on the internal server before
they get access to any sensitive resources. In addition, you can decide
to allow only a limited number of source addresses to enter your
network by means of security policy.
Recipe 12: Destination NAT in a Dual ISP Environment 109
Solution
Here is the configuration of interfaces, security zones, and routing:
lab@SRX#showinterfaces
ge-0/0/1{
unit0{
familyinet{
address1.1.1.1/24;
}
}
}
ge-0/0/2{
unit0{
familyinet{
address2.2.2.2/24;
}
}
}
ge-0/0/12{
unit0{
familyinet{
address192.168.50.1/24;
}
}
}
[edit]
lab@SRX#showsecurityzones
security-zoneISP1{
host-inbound-traffic{
system-services{
ping;
}
}
interfaces{
ge-0/0/1.0;
}
}
security-zoneISP2{
host-inbound-traffic{
system-services{
ping;
}
}
interfaces{
ge-0/0/2.0;
}
}
security-zoneTRUST{
address-book{
addressInternal-host192.168.50.50/32;
}
interfaces{
110 Day One: Juniper Ambassadors Cookbook for Enterprise
ge-0/0/12.0;
}
}
static{
route0.0.0.0/0{
next-hop1.1.1.254;
qualified-next-hop2.2.2.254{
preference7;
}
}
}
NOTE The TRUST zone has an entry for internal host in the address book
configured. This will be used for security policy configuration.
NOTE There are two ISPs, so the default static route has two next hops
primary 1.1.1.254 for ISP1 (this route has a default preference value
of 5) and secondary 2.2.2.254 for ISP2 (for this route, preference value
of 7 is configured using the qualified-next-hop knob, so it only
becomes active when link to ISP1 is down).
[edit]
lab@SRX#showsecuritypolicies
from-zoneISP1to-zoneTRUST{
policyDNAT1{
match{
source-addressany;
destination-addressInternal-host;
applicationjunos-telnet;
}
then{
permit;
}
}
}
from-zoneISP2to-zoneTRUST{
policyDNAT2{
match{
source-addressany;
destination-addressInternal-host;
applicationjunos-telnet;
}
then{
permit;
}
}
}
Note the DNAT pool with the address of the internal host in it.
Also configured were two DNAT rules that match on traffic for
destination port 23 (telnet) coming to 1.1.1.1 and 2.2.2.2, respectively,
and do DNAT to that pool. Finally, security policies are configured
remember that policies must match on already translated destination
addresses. Lets commit to apply the configuration changes, and check
the result by doing telnet from the remote host:
lab@REMOTE-HOST>telnet1.1.1.1
Trying1.1.1.1...
Connectedto1.1.1.1.
Escapecharacteris'^]'.
INT-HOST(ttyp2)
login:^CClientabortedlogin
Connectionclosedbyforeignhost.
lab@REMOTE-HOST>telnet2.2.2.2
Trying2.2.2.2...
telnet:connecttoaddress2.2.2.2:Operationtimedout
telnet:Unabletoconnecttoremotehost
You can see that that first DNAT rule works fine (telnet session opens
and its closed with Control-C), but there is a problem with telnetting
112 Day One: Juniper Ambassadors Cookbook for Enterprise
to the second ISPs IP address (session on remote host times out). Lets
investigate the issue by viewing the session table on the SRX right after
trying to initiate the session to 2.2.2.2:
lab@SRX>showsecurityflowsessiondestination-prefix2.2.2.2
SessionID:39564,Policyname:DNAT2/5,Timeout:12,Valid
In:7.7.7.7/52514-->2.2.2.2/23;tcp,If:ge-0/0/2.0,Pkts:3,Bytes:192
Out:192.168.50.50/23-->7.7.7.7/52514;tcp,If:ge-0/0/12.0,Pkts:0,Bytes:0
Totalsessions:1
As you can see, packets are coming in (bold), but not going out. Our
task now is to understand the problem and fix it.
TRY THIS The answer is coming shortly, but can you guess what the problem is at
this point?
First of all, DNAT and security policy seem to work because there is an
entry in the session table. Although it may not seem obvious at first
glance, the problem is in routing. Every time SRX sets up a session, it
checks a route to the destination, as well as the reverse route to the
source of traffic. This reverse route lookup is needed so that SRX
knows where to send packets back for a return flow of a session. For
our REMOTE-HOST initiating a telnet session to 2.2.2.2, the reverse
route lookup (which is made for sessions source address, 7.7.7.7)
points to the interface of ISP1, because the active default route points
to 1.1.1.254.
So, for a session initiated by the remote host to the address 2.2.2.2 of
ISP2, the return traffic will be sent by the SRX via ISP1. In our case,
traffic is dropped because ISP1 and ISP2 are in different zones. To
confirm this, lets check the flow traceoptions:
lab@SRX#showsecurityflow
traceoptions{
fileflow-log;
flagpacket-drops;
flagbasic-datapath;
packet-filterfilter-dnat{
destination-prefix2.2.2.2/32;
destination-port23;
}
packet-filterfilter-dnat-reverse{
destination-prefix7.7.7.7/32;
source-port23;
}
}
And if you tried to initiate traffic (telnet 2.2.2.2 from 7.7.7.7) once
again, youd see something like the following in the file flow-log:
Recipe 12: Destination NAT in a Dual ISP Environment 113
Apr1314:12:0514:12:05.698794:CID-0:RT:routelookupfailed:dest-
ip7.7.7.7origifpge-0/0/2.0output_ifpge-0/0/1.0fto0x459f7cb0orig-
zone8out-zone7vsd0
Apr1314:12:0514:12:05.698794:CID-0:RT:packetdropped,pakdroppedsincere-
routefailed
Indeed, the return flow of the session tries to come back via ge-0/0/1.0
and traffic is dropped because the interfaces belong to different security
zones. If you move both ISP uplinks to one zone and modify the NAT
configuration accordingly, the traffic will (at least in lab setup) start
flowing, but such asymmetric routing (i.e., traffic coming in via ISP2
and leaving via ISP1) is not what is desired (it will likely be dropped on
its way by ISP1 and anyway it does not provide the redundancy in our
setup).
The solution to the problem is to put ISP2s interface in a separate rout-
ing instance, of a virtual router type (vrouter, for short), on the SRX.
In this case, for traffic coming in via ISP2, the reverse route lookup will
be done using this virtual routers routing table (and the default route
pointing to 2.2.2.254 will be put there), so the reverse traffic will go
through the same ISP2.
Creating a vrouter and putting a second uplink in it is easy:
ISP2{
instance-typevirtual-router;
interfacege-0/0/2.0;
routing-options{
static{
route0.0.0.0/0next-hop2.2.2.254;
}
}
}
After doing it, however, DNAT for telnet sessions coming to 2.2.2.2 is
still not working. Look at the routing table of the vrouter and youll
see that it does not have a route to internal subnet (192.168.50.0/24),
which is clearly the reason for a failure:
lab@SRX>showroutetableISP2
ISP2.inet.0:3destinations,3routes(3active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
0.0.0.0/0*[Static/5]00:04:55
>to2.2.2.254viage-0/0/2.0
2.2.2.0/24*[Direct/0]00:05:39
>viage-0/0/2.0
2.2.2.2/32*[Local/0]00:05:39
Localviage-0/0/2.0
NOTE Starting from this point, you need to follow just one of the ways to
send traffic to the internal host. The flexibility of Junos enables several
methods of doing this, so if you are following the examples in your lab,
save your configuration at this time, and start from this saved config in
every sub-section that follows.
inet.0:7destinations,7routes(7active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.50.0/24*[Direct/0]2d06:20:18
>viage-0/0/12.0
[edit]
lab@SRX#setrouting-optionsinterface-routesrib-groupinetCopyRoutes
[edit]
lab@SRX#setrouting-instancesISP2routing-optionsinterface-routesrib-
groupinetCopyRoutes
lab@SRX#commit
commitcomplete
You just created a RIB group (a set of two routing tables, in our case)
and applied it to the interface routes of both main RIB (inet.0) and
vrouters RIB (ISP2.inet.0). Thus, you copied interface routes between
tables (in both directions), which allows the traffic to flow easily
between master instance and vrouter. In particular, the direct route to
the internal network is now in both routing tables:
[edit]
lab@SRX#runshowroute192.168.50/24exact
inet.0:9destinations,10routes(9active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
192.168.50.0/24*[Direct/0]2d09:02:10
>viage-0/0/12.0
ISP2.inet.0:9destinations,9routes(9active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
Recipe 12: Destination NAT in a Dual ISP Environment 115
192.168.50.0/24*[Direct/0]00:00:07
>viage-0/0/12.0
inet.0:9destinations,10routes(9active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
0.0.0.0/0*[Static/5]2d06:29:16
>to1.1.1.254viage-0/0/1.0
[Static/7]00:01:11
>to2.2.2.254viage-0/0/2.0
ISP2.inet.0:9destinations,9routes(9active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
0.0.0.0/0*[Static/5]02:53:43
>to2.2.2.254viage-0/0/2.0
INT-HOST(ttyp1)
login:^CClientabortedlogin
Connectionclosedbyforeignhost.
lab@REMOTE-HOST>telnet2.2.2.2
Trying2.2.2.2...
Connectedto2.2.2.2.
Escapecharacteris'^]'.
INT-HOST(ttyp1)
login:^CClientabortedlogin
Connectionclosedbyforeignhost.
[edit]
lab@SRX#setpolicy-optionspolicy-statementcopy-int-
nettermcopyfrominstancemaster
[edit]
lab@SRX#setpolicy-optionspolicy-statementcopy-int-nettermcopyfromroute-
filter192.168.50/24exactaccept
[edit]
lab@SRX#setpolicy-optionspolicy-statementcopy-int-nettermelsethenreject
ISP2.inet.0:4destinations,4routes(4active,0holddown,0hidden)
+=ActiveRoute,-=LastActive,*=Both
0.0.0.0/0*[Static/5]03:04:09
>to2.2.2.254viage-0/0/2.0
2.2.2.0/24*[Direct/0]03:04:53
>viage-0/0/2.0
2.2.2.2/32*[Local/0]03:04:53
Localviage-0/0/2.0
192.168.50.0/24*[Direct/0]00:02:17
>viage-0/0/12.0
Telnetting to both 1.1.1.1 and 2.2.2.2 from the remote host works as
well (to save space, the corresponding command outputs are not
shown here).
And DNAT starts working. Lets check with telnet, as usual, and the
session table confirms:
lab@SRX#runshowsecurityflowsessiondestination-prefix2.2.2.2
SessionID:41563,Policyname:DNAT2/5,Timeout:1780,Valid
In:7.7.7.7/51162-->2.2.2.2/23;tcp,If:ge-0/0/2.0,Pkts:10,Bytes:671
Out:192.168.50.50/23-->7.7.7.7/51162;tcp,If:ge-0/0/12.0,Pkts:9,Bytes:643
Totalsessions:1
Recipe 12: Destination NAT in a Dual ISP Environment 117
You can see from the output that DNAT is working because the
destination address in the initiating flow of the session (2.2.2.2) is
different from the source address for the return flow (192.168.50.50).
Also you can see packets going in both directions, so everything is
working just fine.
[edit]
lab@SRX#showinterfacesge-0/0/2
unit0{
familyinet{
filter{
inputto-main;
}
address2.2.2.2/24;
}
}
As in previous cases, you will now see telnet from 7.7.7.7 to 2.2.2.2 as
well as to 1.1.1.1 working fine.
NOTE You can ignore the warning in the filter saying that default routing
instance is not defined. Such a filter is actually directing the traffic to
the master instance (tested with Junos 12.1X44-D10.4). If you are not
comfortable with this warning, create another routing instance and
copy routes from the master instance to it, then use the newly created
instance in a firewall filter.
118 Day One: Juniper Ambassadors Cookbook for Enterprise
This setting also directs traffic entering via ISP2 to the master instance:
lab@REMOTE-HOST>telnet1.1.1.1
Trying1.1.1.1...
Connectedto1.1.1.1.
Escapecharacteris'^]'.
INT-HOST(ttyp1)
login:^CClientabortedlogin
Connectionclosedbyforeignhost.
lab@REMOTE-HOST>telnet2.2.2.2
Trying2.2.2.2...
Connectedto2.2.2.2.
Escapecharacteris'^]'.
INT-HOST(ttyp1)
login:^CClientabortedlogin
Connectionclosedbyforeignhost.
This last option turns out to be another short way to achieve the task.
MORE? There is at least one more way to achieve the task of connecting ISP2
vrouter with the main instance: by using logical tunnel (LT) interfaces
that Junos provides. Search the Junos documentation if you want more
details.
Summary
Setting up destination NAT in a dual ISP environment can be accom-
plished via a number of different options. The particular option you
choose depends on your preferences, as well as other setup require-
ments; you will, however, need to implement routing instances to solve
the problem with reverse route lookup.
It is important to remember that the SRX Series, being a stateful
device, cares about each traffic session. Routing lookup is performed
only when a first packet of the session arrives, and both the route for
the traffic destination as well as the reverse route for the traffic source
are needed to create a session. Once the session is created, the packets
for all subsequent sessions are forwarded accordingly.
Recipe 13
Problem
Configuring multiple ports on a device such as the EX Series can
be tedious and changes are vulnerable to human error.
Solution
One of the nice features of Junos is the ability to build template
configurations very easily and then deploy them rapidly across the
device.
A great example of this is the interface-range statement provided
on the EX platform. By grouping ports with identical roles as
members of an interface range, you can change a piece of configu-
ration within the interface range and have it instantly applied to
all member interfaces. For instance:
interfaces{
interface-rangeMY-RANGE{
memberge-0/0/13;
memberge-0/0/14;
memberge-0/0/15;
memberge-0/0/16;
memberge-0/0/17;
memberge-0/0/18;
unit0{
familyethernet-switching{
vlan{
membersv100-Workstations;
}
120 Day One: Juniper Ambassadors Cookbook for Enterprise
}
}
}
}
{master:0}[edit]
bdale@ex42-lab01#runshowvlansv100-Workstations
NameTagInterfaces
v100-Workstations100
ge-0/0/13.0,ge-0/0/14.0,ge-0/0/15.0,
ge-0/0/16.0,ge-0/0/17.0,ge-0/0/18.0
This may seem trivial at first, but imagine you have four fully-populat-
ed EX8216 chassis configured as a single virtual chassis you could
have over 3,000 physical interfaces in a single box!
Now, when configuring your interface-range statements, it may be
tempting to use the member-range statement to limit the amount of
configuration you need to enter:
interface-rangeSERVER-PORTS{
member-rangege-0/0/8toge-0/0/20;
member-rangege-1/0/8toge-1/0/20;
member-rangege-2/0/8toge-2/0/20;
member-rangege-3/0/8toge-3/0/20;
member-rangege-4/0/8toge-4/0/20;
member-rangege-5/0/8toge-5/0/20;
unit0{
familyethernet-switching{
vlan{
membersv200-Infrastructure;
}
}
}
}
Recipe 13: Rapid Port Templating 121
However, if you need to make a change later, things get messy pretty
quickly. For instance, lets say that port ge-3/0/13 is no longer a server
port:
{master:0}[edit]
bdale@ex42-lab01#deleteinterfacesinterface-rangeSERVER-PORTSmember-rangege-
3/0/8toge-3/0/20
{master:0}[edit]
bdale@ex42-lab01#setinterfacesinterface-rangeSERVER-PORTSmember-rangege-
3/0/8toge-3/0/12
{master:0}[edit]
bdale@ex42-lab01#setinterfacesinterface-rangeSERVER-PORTSmember-rangege-
3/0/14toge-3/0/20
{master:0}[edit]
bdale@ex42-lab01#showinterfaces|findSERVER-PORTS
interface-rangeSERVER-PORTS{
member-rangege-0/0/8toge-0/0/20;
member-rangege-1/0/8toge-1/0/20;
member-rangege-2/0/8toge-2/0/20;
member-rangege-4/0/8toge-4/0/20;
member-rangege-5/0/8toge-5/0/20;
member-rangege-3/0/8toge-3/0/12;
member-rangege-3/0/14toge-3/0/20;
unit0{
familyethernet-switching{
vlan{
membersv200-Infrastructure;
}
}
}
}
Now, lets say you need to remove ge-3/0/15 as well, as it is no longer a
server port either:
{master:0}[edit]
bdale@ex42-lab01#deleteinterfacesinterface-rangeSERVER-PORTSmember-rangege-
3/0/14toge-3/0/20
{master:0}[edit]
bdale@ex42-lab01#setinterfacesinterface-rangeSERVER-PORTSmemberge-3/0/14
{master:0}[edit]
bdale@ex42-lab01#setinterfacesinterface-rangeSERVER-PORTSmember-rangege-
3/0/16toge-3/0/20
{master:0}[edit]
bdale@ex42-lab01#showinterfaces|findSERVER-PORTS
interface-rangeSERVER-PORTS{
memberge-3/0/14;
member-rangege-0/0/8toge-0/0/20;
member-rangege-1/0/8toge-1/0/20;
member-rangege-2/0/8toge-2/0/20;
member-rangege-4/0/8toge-4/0/20;
member-rangege-5/0/8toge-5/0/20;
member-rangege-3/0/8toge-3/0/12;
member-rangege-3/0/16toge-3/0/20;
unit0{
122 Day One: Juniper Ambassadors Cookbook for Enterprise
familyethernet-switching{
vlan{
membersv200-Infrastructure;
}
}
}
}
As you can see, this gets messy very quickly and is just prime for an
operator error! Fortunately, there is an easier way, by creating your
interface ranges using only the member option, but saving all the typing
by using the wildcard range set command (available from Junos
12.1):
{master:0}[edit]
bdale@ex42-lab01#wildcardrangesetinterfacesinterface-rangeSERVER-
PORTSmemberge-[0-5]/0/[8-20]
|
{master:0}[edit]
bdale@ex42-lab01#showinterfaces|findSERVER-PORTS
interface-rangeSERVER-PORTS{
memberge-0/0/8;
memberge-0/0/9;
memberge-0/0/10;
memberge-0/0/11;
memberge-0/0/12;
memberge-0/0/13;
memberge-0/0/14;
...
memberge-5/0/14;
memberge-5/0/15;
memberge-5/0/16;
memberge-5/0/17;
memberge-5/0/18;
memberge-5/0/19;
memberge-5/0/20;
unit0{
familyethernet-switching{
vlan{
membersv200-Infrastructure;
}
}
}
}
Now you can simply add and delete individual members from your
interface range with a single command.
TIP You can also use wildcard range delete if you have a large number of
consecutive ports to remove via a regular expression.
Recipe 13: Rapid Port Templating 123
{master:0}[edit]
bdale@ex42-lab01#showprotocolsrstp
bridge-priority8k;
interfacege-0/0/14.0{
disable;
}
interfaceSERVER-PORTS{
edge;
}
bpdu-block-on-edge;
{master:0}[edit]
bdale@ex42-lab01#runshowspanning-treeinterface
SpanningTreeinterfaceparametersforinstance0
InterfacePortIDDesignatedDesignatedPortStateRole
portIDbridgeIDCost
...
ge-0/0/13.0128:526128:5268192.80711fe2170120000FWDDESG
ge-0/0/14.0128:527128:52732768.80711fe2170120000DISDIS
124 Day One: Juniper Ambassadors Cookbook for Enterprise
Recipe 14
Problem
Keeping an organizations network and data safe is paramount,
and firewalls can help, but they also introduce a new issue: How
does legitimate traffic get in? The simple answer is to use a
site-to-site VPN, but the configuration requires a number of
considerations that are by no means simplistic. Lets investigate.
Firewalls are designed to keep unwanted traffic out of your
network, but also to allow users inside the network to dynami-
cally access resources outside the network. What happens
however, if a user inside your network needs to access several
resources inside another network?
Solution
This is where site-to-site VPNs are used. These allow secure
encrypted tunnels across the Internet, but it was recognized early
on that there are many manufacturers of firewalls, and connecting
them requires a common set of encryption protocols. Thankfully
the IETF has already thought of this, and today the most common
VPN in use utilizes the IPSec protocol suite.
MORE? This recipe details how to connect devices via IPSec VPN. It is not
a study guide on IPSec itself, nor does it cover IPSec in any great
detail. Should you need to learn more about IPSec, search on
IPSec VPN Junos at www.juniper.net/techpubs.
126 Day One: Juniper Ambassadors Cookbook for Enterprise
Here is this recipes topology. One site is using a Juniper SRX100 with
a public facing IP address of 150.34.18.34, and behind the firewall is a
private subnet using the network address of 10.100.100.0/24. The
second site will be using a Cisco ASA5505 with an IP address of
3.18.215.10 and behind the firewall will be a private subnet using the
network address of 172.23.7.0/24.
SRX
fe-0/0/0 {
unit 0 {
family inet {
address 150.34.18.34/24;
}
}
}
fe-0/0/2 {
unit 0 {
family inet {
address 10.100.100.1/24;
}
}
}
ASA
interface Ethernet0/0
switchport access vlan 300
!
interface Ethernet0/2
switchport access vlan 200
!
interface Vlan200
nameif inside
security-level 100
ip address 172.23.7.1 255.255.255.0
!
interface Vlan300
nameif outside
security-level 0
ip address 3.18.215.10 255.255.255.0
Recipe 14: SRX to ASA Policy Based IPSec VPN 127
NOTE In this scenario, both firewalls have a default route pointing to their
respective ISPs as their next hop.
Discussion
The goal of this recipe is to allow users in 10.100.100.0/24 to access
resources in 172.23.7.0/24 and vice versa, securely, with a guarantee
that the data has not been tampered with. So, the first step would be to
ensure the devices can reach each other.
Lets ping the ASA from the SRX:
root@SRX100> ping 3.18.215.10
PING 3.18.215.10 (3.18.215.10): 56 data bytes
64 bytes from 3.18.215.10: icmp_seq=0 ttl=254 time=2.438 ms
64 bytes from 3.18.215.10: icmp_seq=1 ttl=254 time=2.245 ms
64 bytes from 3.18.215.10: icmp_seq=2 ttl=254 time=2.395 ms
Commit
CAUTION By default the SRX will not respond to pings so that an attacker cannot
easily find its IP address and attack it. Allowing a ping could compro-
mise this security feature, therefore, please do it with caution or as
with most of the recipes in this book, they should be tried on nonpro-
duction environments.
Now ping the SRX from the ASA and youll get:
ASA# ping 150.34.18.34
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.34.18.34, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Encryption DES
3DES
AES 128bit
AES 192bit
AES 256bit
Data Integrity MD5
SHA
And IPSec has three values you need to supply: protocol, encryption,
and Data Integrity, as listed here:
NOTE Not all these values are supported on every device. It is up to the
individual engineer to decide which options should be used and which
cannot be used before beginning the configuration.
For the IPSec proposal, lets use ESP, SHA1, and 3DES, entered into the
SRX:
set security ipsec proposal SITE2SITEPROP protocol esp
set security ipsec proposal SITE2SITEPROP authentication-algorithm hmac-sha1-96
set security ipsec proposal SITE2SITEPROP encryption-algorithm 3des-cbc
Once these policies and proposals have been created, and the interest-
ing traffic has been classified, this information can then be joined in a
policy or map to tell the firewall to use these policies and proposals. In
addition, the firewall needs to be told the IP address of the peer and
what the pre-shared key is.
The SRX and ASA do this slightly differently. In the SRX, a security
policy would be created to tell the SRX to send the traffic destined for
the remote site through the tunnel and which tunnel to use. The issue
here is that by default, the SRX has a security policy in place to permit
all outgoing traffic. As this policy is first in the list, our new policy will
be ignored. This can be corrected by using the command insert
policy as shown at the end of this configuration:
set security policies from-zone trust to-zone untrust policy VPNPOLICY match source-
address SRXNETWORK
set security policies from-zone trust to-zone untrust policy VPNPOLICY match
destination-address ASANETWORK
set security policies from-zone trust to-zone untrust policy VPNPOLICY match
application any
set security policies from-zone trust to-zone untrust policy VPNPOLICY then permit
Recipe 14: SRX to ASA Policy Based IPSec VPN 131
In addition, it is necessary to tell the SRX how to treat the return traffic
coming from the ASA, as follows:
set security policies from-zone untrust to-zone trust policy POLICYVPNIN match source-
address ASANETWORK
set security policies from-zone untrust to-zone trust policy POLICYVPNIN match
destination-address SRXNETWORK
set security policies from-zone untrust to-zone trust policy POLICYVPNIN match
application any
set security policies from-zone untrust to-zone trust policy POLICYVPNIN then permit
tunnel ipsec-vpn SITE2SITEVPN
set security policies from-zone untrust to-zone trust policy POLICYVPNIN then permit
tunnel pair-policy VPNPOLICY
The ASA uses a group policy as opposed to an IKE policy. Under this
policy, the VPN protocol that the firewall should use is entered. In this
case, ikev1 is used as opposed to IKE version 2, which is more related
to AnyConnect VPNs, whereas IPSec uses IKE version 1.
group-policy SITE2SITEPOLICY internal
group-policy SITE2SITEPOLICY attributes
vpn-tunnel-protocol ikev1
NOTE An IPSec policy has been included under the Gateway configuration.
Its included here as the ASA adds its IPSec policy under the crypto
map.
set security ike gateway SITE2SITEGW ike-policy SITE2SITEPOL
set security ike gateway SITE2SITEGW address 3.18.215.10
set security ike gateway SITE2SITEGW external-interface fe-0/0/0
set security ipsec policy SITE2SITEIPSECPOL proposals SITE2SITEPROP
The next step is to create a VPN telling the SRX which Gateway
should be used and which IPSec policy to use. Lets also tell the SRX to
create the tunnel now by adding the establish-tunnels immediately
option. The alternative is to use the establish-tunnels on-traffic
option whereby the tunnel is not created until the SRX receives traffic
that needs to traverse the VPN:
set security ipsec vpn SITE2SITEVPN ike gateway SITE2SITEGW
set security ipsec vpn SITE2SITEVPN ike ipsec-policy SITE2SITEIPSECPOL
set security ipsec vpn SITE2SITEVPN establish-tunnels immediately
A tunnel group is created on the ASA for the same purpose. Note that
the pre-shared key is placed under the tunnel group as opposed to
under the IKE policy as it is on the SRX:
tunnel-group 150.34.18.34 type ipsec-l2l
tunnel-group 150.34.18.34 general-attributes
default-group-policy SITE2SITEPOLICY
tunnel-group 150.34.18.34 ipsec-attributes
ikev1 pre-shared-key SUPERSECRET
One final thing that needs to be done is that the firewall needs to be
told to allow VPN connections in on its outside interface. The system
service ike is added to the untrusted interface in the security zone on
the SRX:
set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic
system-services ike
ASA 5505s use nameif interfaces, and in this case, the nameif is called
outside. The ASA should be instructed to enable IKE version 1 on this
interface:
crypto ikev1 enable outside
Recipe 14: SRX to ASA Policy Based IPSec VPN 133
root@SRX100>showsecurityipsecsecurity-associations
Totalactivetunnels:1
IDAlgorithmSPILife:sec/kbMonlsysPortGateway
<4ESP:3des/sha132795eb22672/unlim-root5003.18.215.10
>4ESP:3des/sha12787d2142672/unlim-root5003.18.215.10
Negotiationtype:Quickmode,Role:Initiator,MessageID:0
Local:150.34.18.34:500,Remote:3.18.215.10:500
Localidentity:150.34.18.34
Remoteidentity:3.18.215.10
Flags:IKESAiscreated
134 Day One: Juniper Ambassadors Cookbook for Enterprise
root@SRX100>showsecurityipsecsecurity-associationsdetail
ID:4Virtual-system:root,VPNName:SITE2SITEVPN
LocalGateway:150.34.18.34,RemoteGateway:3.18.215.10
LocalIdentity:ipv4_subnet(any:0,[0..7]=10.100.100.0/24)
RemoteIdentity:ipv4_subnet(any:0,[0..7]=172.23.7.0/24)
Version:IKEv1
DF-bit:clear
Policy-name:VPNPOLICY
Port:500,Nego#:7,Fail#:0,Def-Del#:0Flag:600829
TunnelDownReason:ClearedviaCLI
Direction:inbound,SPI:6f91abf3,AUX-SPI:0
,VPNMonitoring:-
Hardlifetime:Expiresin3583seconds
LifesizeRemaining:Unlimited
Softlifetime:Expiresin2945seconds
Mode:Tunnel(00),Type:dynamic,State:installed
Protocol:ESP,Authentication:hmac-sha1-96,Encryption:3des-cbc
Anti-replayservice:counter-basedenabled,Replaywindowsize:64
Direction:outbound,SPI:3d7dd89c,AUX-SPI:0
,VPNMonitoring:-
Hardlifetime:Expiresin3583seconds
LifesizeRemaining:Unlimited
Softlifetime:Expiresin2945seconds
Mode:Tunnel(00),Type:dynamic,State:installed
Protocol:ESP,Authentication:hmac-sha1-96,Encryption:3des-cbc
Anti-replayservice:counter-basedenabled,Replaywindowsize:64
Although the security associations are up, there is one small issue:
hosts in the remote site cannot access resources local to the opposing
site. The reason for this is simple. Since these firewalls are connected to
the Internet and the subnet behind the firewall is using an RFC1918
address, the firewalls are configured to use NAT. Unfortunately, this
means that the firewalls will also attempt to use NAT when sending
traffic across the VPN. The firewalls need to be notified that when
sending traffic from 10.100.100.0/24 to 172.23.7.0/24, or from
172.23.7.0/24 to 10.100.100.0/24, not to use NAT.
By default the SRX already has NAT configured. A new rule needs to
be created to specify the source and destination, then the insert com-
mand should be used to place the new rule ahead of the default rule;
set security nat source rule-set trust-to-untrust rule VPN match source-address
10.100.100.0/24 destination-address 172.23.7.0/24
set security nat source rule-set trust-to-untrust rule VPN then source-nat off
insert security nat source rule-set trust-to-untrust rule VPN before rule source-nat-
rule
Recipe 14: SRX to ASA Policy Based IPSec VPN 135
NOTE The ASA used in this recipe was using version 8.4. NAT in 8.4 is
completely different from ASA version 8.2, therefore if you are unsure
as to the reason why a double NAT is performed, it is strongly recom-
mended you consult the relevant Cisco documentation.
Problem
Hub and spoke VPNs provide an effective way to provide central
office or data center resources to remote offices over the Internet.
Each site connects to the central service location using IPSEC
VPN and can then access these published services.
But standard policy-based VPNs, or those using static routing,
present additional management overhead, and full mesh routing
requires that new routes be created at each site for any new spoke
added to the network.
Solution
To solve this predicament, route-based VPNs are used along with
OSPF to automatically create and distribute routes for each site.
The configurations basic steps are:
Configure the hub for needed services
Configure multi-point tunnel interface
Configure hub LAN interface
Enable OSPF settings
138 Day One: Juniper Ambassadors Cookbook for Enterprise
NOTE This recipe was tested on a SRX100 using Junos 11.4r5.5 and that all
configuration statements are shown as they would be entered on the
branch device.
Now set the default route for the local Internet service:
set routing-options static route 0.0.0.0/0 next-hop 1.1.1.254
Now allow management services on this interface for the VPN IKE
connections. You can also allow management services as needed on
this interface, but the IKE services are required to establish the VPN
connection. Since this is an Internet-facing interface, you will not
enable any other system services for now:
set security zones security-zone untrust host-inbound-traffic system-services ike
140 Day One: Juniper Ambassadors Cookbook for Enterprise
Next, configure the remote gateway IKE parameters for policy and a
preshared key. These can be used by all the spoke VPN connections
and are created on the hub just once:
set security ike policy ike-policy1 mode main
set security ike policy ike-policy1 proposal-set standard
set security ike policy ike-policy1 pre-shared-key ascii-text "sharedsecret"
Now create the IPSEC parameters for the VPN connection. Again,
these are used by all the spoke connections and are created just once:
set security ipsec policy vpn-policy1 proposal-set standard
Follow these steps to create the route-based VPN using the tunnel
interface you just created. The steps need to be repeated for each
spoke site added to the system, but for each spoke site the IP address of
the remote gateway will need to be adjusted.
set security ike gateway ike-gate ike-policy ike-policy1
For this remote IKE gateway address, the IP address will change for
each new spoke added.
set security ike gateway ike-gate address 2.2.2.2
set security ike gateway ike-gate external-interface fe-0/0/0.0
Then use the existing policy to create the IPSEC Phase 2 connection
and tie this to the tunnel interface:
set security ipsec vpn ike-vpn ike gateway ike-gate
set security ipsec vpn ike-vpn ike ipsec-policy vpn-policy1
set security ipsec vpn ike-vpn bind-interface st0.0
Finally, set the VPN MTU to the most common value to prevent
fragmentation issues of traffic across the tunnel:
set security flow tcp-mss ipsec-vpn mss 1350
Adjust the IP address to match the particular spoke you are configuring
per the diagram:
set interfaces st0 unit 0 family inet address 10.0.0.X/24
Follow these steps to create the route-based VPN using the tunnel
interface created above. Start by configuring the local gateway
interface for the VPN. This will be the public IP address and interface
from the local Internet service and place these into the untrust zone.
Configure the Internet static IP address on the gateway interface, and
this address changes per the spoke being configured:
set interfaces ge-0/0/0 unit 0 family inet address 2.2.2.2/24
Now, set the default route for our local Internet service:
set routing-options static route 0.0.0.0/0 next-hop 2.2.2.254
Now lets allow management services on this interface for the VPN IKE
connections. You can also allow management services as needed on
this interface, but the IKE services are required to establish the VPN
connection. But since this is an Internet-facing interface, lets not
enable any other system services for now.
set security zones security-zone untrust host-inbound-traffic system-services ike
Next, configure the remote gateway IKE parameters for policy and the
preshared key. Naturally, these parameters must match the configura-
tion at the corporate site where the VPN is established.
set security ike policy ike-policy1 mode main
set security ike policy ike-policy1 proposal-set standard
set security ike policy ike-policy1 pre-shared-key ascii-text "sharedsecret"
This is the gateway of the hub so this will remain the same on all the
spoke devices:
set security ike gateway ike-gate address 1.1.1.1
set security ike gateway ike-gate external-interface fe-0/0/0.0
Now create the IPSEC parameters for the VPN connection:
set security ipsec policy vpn-policy1 proposal-set standard
Now use this policy to create the IPSEC Phase 2 connection and tie this
142 Day One: Juniper Ambassadors Cookbook for Enterprise
Finally, set the VPN MTU to the most common value, preventing
fragmentation of traffic across the tunnel:
set security flow tcp-mss ipsec-vpn mss 1350
References
The Juniper installer service and white list file can improve your user
experience when performing routine upgrades.