Go to Organization -> WAN Edge Templates.
Note
You can avoid the work creating this Template if you simply import the shared JSON discussed in other reference documentation. Remember you must do the Site assignments after this.
Create your entire Spoke Template via GUI. Click on “Create Template”
We create the Template for our Spokes. Naturally the name would be “Spokes” and the Type=Spoke to be used then click on “Create”.
There may be one Template or several Templates for your end sites (Spokes), with the goal to make them flexible enough to reduce the overall number of Templates required, which make standardization of your network much cleaner.
Configure the DNS Servers to use 8.8.8.8, 9.9.9.9 in our case.
Add the first WAN-Interface
Configure the new WAN-Interface as follows
- Name=INET this indicates which Topology it’s going to use.
- As Interface=ge-0/0/0
- IP configuration=DHCP
- Source NAT=Enabled
- Configure two VPN (on for each Hub) with Endpoint=hub1-INET and hub2-INET as Overlay Hub endpoints and used the BFD-Profile Broadband on both for now.
Configure a second WAN-Interface as follows
- Name=MPLS this indicates which Topology it’s going to use.
- As Interface=ge-0/0/1
- IP configuration=Static
- IP Address={{WAN1_PFX}}.2
- Prefix Length=24
- Gateway={{WAN1_PFX}}.1
- Source NAT=Enabled
- Configure two VPN (on for each Hub) with Endpoint=hub1-MPLS and hub2-MPLS as Overlay Hub endpoints and used the BFD-Profile Broadband on both for now.
The end result overview should look like the below summary picture.
Add a LAN-Interface now
Configure the LAN-Interface as follows
- Select from the preconfigured list the Network=SPOKE-LAN1
- As Interface=ge-0/0/3
- IP Address={{SPOKE_LAN1_PFX}}.1
- 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.
Configure the first Traffic Steering Policies as follows:
- Name=SPOKE-LANS
- Strategy=Ordered
- As Path Type select LAN: SPOKE-LAN1
Configure the second Traffic Steering Policies as follows:
- Name=Overlay
- Strategy=ECMP
- As Path Types select all four Hub destination Hub Interfaces as there are Overlay: hub1-INET and Overlay: hub2-INET and Overlay: hub1-MPLS and finally Overlay: hub2-MPLS
The end result overview should look like the below summary picture.
We now need to configure Access Policies to steer Traffic into Overlay and Local LAN.
Implement the following list of Access Rules as a basic setup that allows all Traffic between Spoke and Spoke, Spokes and Hubs, Hubs to Spokes and if Traffic is not inside the VPN we send it default to the Hub for central breakout. Here is an explanation why we created those rules.
- First Rule allows Traffic that is initiated from IP-Addresses of the direct attached LAN interface when the Destination Prefix one the direct Address groups representing the LAN interface of our two Hubs.
- Second Rule allows Traffic that is initiated from IP-Addresses of the direct attached LAN interface to reach all IP-Addresses of other Spokes to be reached in the VPN using the Overlay. Remember SPOKE-LAN1 is 10.0.0.0/8 so everything. As its technically most of the times not possible (only expensive MPLS Networks with managed IP’s may give you a chance to do that) to send this Traffic directly to the other Spoke we will send it to the Hub and he will relay it for us.
- Third Rule allows Traffic that originally came (usually via Overlay) from a Hub to be forwarded to IP-Addresses of the direct attached LAN interface. So, something attached to the Hub like a Server in its DMZ is allowed to initiate Traffic towards the Branch devices at the Spoke.
- Fourth Rule is a catch-up Rule the allows ALL Traffic from LAN interface to forward to the Overlay (towards one of our Hubs). In our case the Hub applies SNAT to this Traffic and sends it to a WAN interface but this is defined in the Hub-Template. This Rule should typically be the LAST RULE of all your Access Rules and all above Rules should be more specific.
| no. | Rule Name | Network | Action | Destination | Stearing |
| 1 | Spokes-to-Hub | SPOKE-LAN1 | Pass | HUB1-LAN1 + HUB2-LAN1 | N/A |
| 2 | Spoke-to-Spoke-via-Hub | SPOKE-LAN1 | Pass | SPOKE-LAN1 | N/A |
| 3 | Hub-DMZ-to-Spoke | HUB1-LAN1 + HUB2-LAN1 | Pass | SPOKE-LAN1 | N/A |
| 4 | Internet-via-Hub-CBO | SPOKE-LAN1 | Pass | ANY | NA |
Warning
For 128T SSR’s the order of Rules does NOT matter when creating Access Policies! However, it is always good practice to move the more global rules to the bottom.
Note
There is no need to always define a Traffic Steering on each rule as one must do for a Juniper SRX. In the below you will see that some policies are only made with an access network and destination definition. This is because this system acts more like a Router. As in our case we announce all routes on each LAN-Interface independent if that is a Hub or Spoke the steering comes from the iBGP based route distribution the system does automatically when you build the Hub/Spoke VPN.
Note
The general Rule for SSR is to make Traffic flow between a Hub and Spoke the NAME of a Network used on one side has the be identical with the Name of the Network on the other Side. The Network Name for SSR is identical to a security tenant used for Traffic isolation hence they need to match on both sides.
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.
IMPORTANT to save your final changes in this Screen
Assign Spoke Templates to Sites
We go back to the Spoke Template and “Assign to Sites”.
Then select only the three “spokeX-site” and “Apply”.
The result should indicate 3 Sites (the wan edges change when devices get assigned the these)
