SRX Hub Profiles

Create configuration for the two Hubs

Warning

It is mandatory (and a good practice anyway) that you create the configuration for all Hubs BEFORE the Spoke Templates.

Create Hub Profile for first Hub

Go to Organization -> Hub Profiles

Note
You can avoid the work creating this Profile if you simply import the shared JSON, which can be found in further documentation

Click on “Create Profile”

Naturally the name would be “hub1” then click on “Create”.

This will open the dialogue window to enter the configuration for the Hub

Configure the DNS Servers to use 8.8.8.8, 9.9.9.9 in our case, although may be the DNS servers your company use as a standard that are reachable from the Hub devices.

Add the first WAN-Interface

• Configure a first WAN-Interface as follows
• Name=INET this indicates which Topology it’s going to use.
• The Overlay Hub Endpoint will be automatically generated and should be “hub1-INET”.
• As Interface=ge-0/0/0
• IP Address={{WAN0_PFX}}.254  <–Please read Site Variables document if you are not familiar with variables
• Prefix Length=24
• Gateway={{WAN0_PFX}}.1
• Source NAT=Enabled  <—We use NAT along with advertising the Public IP address below unless the WAN address is a publicly routable address
• Check Override for Public IP
• Public IP={{WAN0_PUBIP}}

Configure a second WAN-Interface as follows

• Name=MPLS this indicates which Topology it’s going to use. <—This is simply a label and not a technology
• The Overlay Hub Endpoint will be automatically generated and should be “hub1-MPLS”.
• As Interface=ge-0/0/3
• IP Address={{WAN1_PFX}}.254
• Prefix Length=24
• Gateway={{WAN1_PFX}}.1
• Source NAT=Enabled
• Check Override for Public IP
• Public IP={{WAN1_PUBIP}}

The end result overview should look like the below summary picture.

Add a LAN-Interface now

Configure the LAN-Interface as follows:

• As Network select the existing=HUB1-1LAN1
• As Interface=ge-0/0/4
• IP Address={{HUB1_LAN1_PFX}}.1
• Prefix Length=24
• Untagged VLAN=No (for our Lab it’s better to use tags even at the first vlan)
• DHCP=No (we don’t configure a local DHCP server yet even if we could)

The end result overview should look like the below summary picture.

We always need to add Traffic Steering Policies, which describes how traffic is steered out the interfaces that were previously defined. These definitions explain traffic pattern for single interfaces or multiple interfaces and how you want your traffic to utilize these paths.

Overlay, WAN and LAN are defined as well as if you would like a specific order or Equal Cost Multi-Path (ECMP), so the combination of which interfaces and how those interfaces participate in the data flowing from the device, which the Hub Profile is applied to.

Configure the first Traffic Steering Policies as follows:

• Name=HUB-LAN
• Strategy=Ordered
• As Path Type select LAN: HUB1-LAN1

Configure the second Traffic Steering Policies as follows:

• Name=Overlay
• Strategy=ECMP
• As Path Types we need to configure the two automatic Endpoints we’ve created automatically above based on our WAN-Interface configuration. So, select via “Add Paths” the Overlay Endpoints hub1-INET and hub1-MPLS please.

Third we need to define WAN Interfaces to be used for Central Breakout (of internet traffic) on this Hub. Local Breakout is a term where the Spoke device will break out traffic to the Internet and Central Breakout is where the Internet bound traffic goes to the Hub device over the SD-WAN network, then breaks out. Here we are configuring Central Breakout so, configure:

• Name=LBO
• Strategy=Ordered
• As Path Type select WAN: INET and WAN: MPLS

The end result overview should look like the below summary picture.

Note
Every Traffic Policy you have defined MUST be used at least once in an Access Policy!

We now need to configure Access Policies to steer Traffic into Overlay, Local LAN and Central Breakout, which we defined in the Traffic Policies.

Warning
The order of Rules does matter a lot when creating Access Policies. You must keep them in the order as they appear below! One can move them up/down at the right where the “…” sign is.

Implement the following list of Access Rules as a basic setup that allows all Traffic between Hub and Spokes, Spokes to Spokes (hairpin on the Hub) and then also using the Hub for central breakout towards the Internet for all Traffic not inside the VPN. Here is an explanation why we created those rules.

• First Rule (via ALL.SPOKE-LAN1 network as it is defined as 10.0.0.0/8) allows all other VPN Members in the Branch to initiate Traffic towards the local LAN-Interfaces of the Hub where usually an internal Server is attached in a DMZ.
• Second Rule is the opposite of the first allowing the Servers attached to the Lan-Interfaces at the Hub to initiate Traffic towards the Spokes (represented by SPOKE-LAN1 defined as 10.0.0.0/8) via Overlay using the VPN then.
• Third Rule number identifies Traffic from Spoke interfaces (because Network ALL.SPOKE-LAN1 is defined as 10.0.0.0/8) send to the Hub but the destination is an IP-Address (via Application SPOKE-LAN1 defined as 10.0.0.0/8) at another Spoke. So, this Traffic will be hair pinned at the Hub and forwarded back to the next Spoke via the Overlay VPN.
• Forth Rule allows Traffic that is initiated from IP-Addresses of the direct attached LAN interface of a Hub to use the WAN Underlay Interface (SNAT applied) to reach IP-Addresses in the Internet as local breakout. The ANY destination is defined as 0.0.0.0/0 so this will mean the remaining Internet. This Traffic will use the WAN Underlay Interface (SNAT applied) to reach IP-Addresses in the Internet as local breakout .
• The last Rule identifies all Traffic from the Spokes (because Network ALL.SPOKE-LAN1 is defined as 10.0.0.0/8) wanting to reach the remain IP-Address and not the HUB-LAN in the first rule. The ANY destination is defined as 0.0.0.0/0 so this will mean the remaining Internet. This Traffic will use the WAN Underlay Interface (SNAT applied) to reach IP-Addresses in the Internet as local breakout . This implements Central Break out at the Hub for all Spokes.

The end result overview should look like the below summary picture.

Remember the basic Traffic model we are implementing to see where the green counter marks match to which traffic direction. So please compare below and above pictures.

Note
The default security configuration for SRX based devices does NOT allow ICMP-Ping from LAN attached device to the local Interface of the WAN-Edge Router. However, some devices are known to check this before they attempt to connect to the outside. Hence, it is recommended that you allow ICMP-Ping for debugging and device connectivity and override this default.

Add the following additional Junos CLI. It will allow you to Ping the local LAN-Interface for debugging.
set security zones security-zone HUB1-LAN1 host-inbound-traffic system-services ping
This is how it will be seen in the GUI.

IMPORTANT to save your final changes in this Screen

Create second Hub as clone of the first Hub

Go to Organization -> Hub Profiles

Note
You can avoid the work creating this Profile if you simply import the shared JSON from below .

Create your second Profile based on the first one to save time. Click on the existing Hub1 Profile

Name the new Hub “hub2” and press on “clone”-button.

You might see a bug in the GUI where the new name does not match the new profile name like below.

BEST PRACTICE: Always refresh your Browser after you cloned something. This will make sure all objects are REALLY refreshed!

Note
As we already made heavy use of site variables we do not need to edit the configuration of our WAN interfaces which limits the amount of changes on the clone to a minimum.

Click in the clone of the HUB1-LAN1 interface as we need to change that.

Change the Network to HUB2-LAN1 and the IP Address to {{HUB2_LAN1_PFX}}.1

Check that the resulting LAN interface always states HUB2 and not HUB1 anymore.

Please check that the Overlay Endpoints in the Overlay definition have really changed to hub2-INET and hub2-MPLS as they should.

Next click under Traffic Steering on HUB-LAN as it still references the original hub

Edit the entry and change the path to LAN: HUB2-LAN1

Check that all resulting Traffic Steering Paths now point to HUB2 and no longer to HUB1

The only manual change we do need to make on our clone hub is the destination for the rules as indicated below.

So, change the destination of the second rule from HUB1-LAN to HUB2-LAN please.

Note
The default security configuration for SRX based devices does NOT allow ICMP-Ping from LAN attached device to the local Interface of the WAN-Edge Router. However, some devices are known to check this before they attempt to connect to the outside. Hence, it is recommended that you allow ICMP-Ping for debugging and device connectivity and override this default.

Add the following additional Junos CLI. It will allow you to Ping the local LAN-Interface for debugging.

set security zones security-zone HUB2-LAN1 host-inbound-traffic system-services ping

This is how it will be seen in the GUI.

Graphical user interface, text, application Description automatically generated

IMPORTANT to save your final changes!!