Allow local spoke LAN to reach the Internet with CSO

In a previous post we configured a local LAN segment.

Now, we want an user belonging to that LAN to be able to reach the Internet.

Unless explicitly configured, by default, internet breakout is available at EHUB.

In order to achieve this, we need to configure so-called security intents.

First, let’s define firewall policies. I define 3 policies:

• one applied to spokes only
• one applied to ehub only
• one applied to all devices (already existing)

We click on SPOKES policy and add a new intent:

Remember, when we created the LAN segment, we associated it to department “Default”, which maps on the SRXs to a security zone called “Default”.

Our intent says “Allow traffic from department Default to any destination (in CSO language, it means Internet)”.

We save the intent and click on deploy.

The intent is translated into a security policy on spoke devices. Unless specified, policy will be configured on all the sites.

Remember, Internet breakout is available on the enterprise hub.

Let’s follow traffic from spoke to the Internet.

We saw before, LAN segment (a reth10 ifl) is associated to a vrf:

set groups spoke-AMS_LAB_DefaultVPN-vpn-routing-config routing-instances LAN-AMS_LAB_DefaultVPN interface reth10.123

That vrf is used to connect spoke to local LANs.

Anyhow, for forwarding purposes, that vrf is not used.

The actual vrf used to forward traffic depends on the configured SDWAN policy.

If there is no SDWAN policy configured, route lookup is performed on the Deafult vrf. There we have a 0/0 towards the hub:

root@AMS_LAB.AMS-345> show route table Default-AMS_LAB_DefaultVPN.inet.0

Default-AMS_LAB_DefaultVPN.inet.0: 7 destinations, 12 routes (5 active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[BGP/170] 1w2d 11:43:42, localpref 300, from 10.10.17.4
                      AS path: I, validation-state: unverified
                    >  via gr-0/0/0.4003, Push 19
                       via gr-0/0/0.4000, Push 19
                    [BGP/170] 1w2d 11:43:42, localpref 300, from 10.10.18.5
                      AS path: I, validation-state: unverified
                    >  via gr-0/0/0.4003, Push 19
                       via gr-0/0/0.4000, Push 19

Let’s move to the hub and check the Default vrf:

root@AMS_LAB.AMS-EHUB> ...t-AMS_LAB_DefaultVPN.inet.0 0/0 exact

Default-AMS_LAB_DefaultVPN.inet.0: 11 destinations, 25 routes (10 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/120] 3d 11:42:03, metric2 0
                    >  to table default-lbo-AMS_LAB_DefaultVPN.inet.0
                    [Static/125] 3d 11:42:03, metric2 0
                    >  to table default-lbo-AMS_LAB_DefaultVPN.inet.0
                    [Static/175] 5w0d 09:00:36, metric2 0
                    >  to table default-lbo-AMS_LAB_DefaultVPN.inet.0

Traffic is sent to vrf default-lbo where lbo is an acronym for “local breakout”.

Let’s check the default lbo routing table:

root@AMS_LAB.AMS-EHUB> ...t-lbo-AMS_LAB_DefaultVPN.inet.0

default-lbo-AMS_LAB_DefaultVPN.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/11] 5w0d 09:56:32, metric2 0
                    >  to 192.168.195.1 via reth0.0
                       to 192.168.198.1 via reth1.0

Traffic is sent out via both reth0 and reth1, our wan interfaces.

We have both interfaces as, during enterprise hub site creation, we enabled local breakout on both wan0 and wan1 links.

Wan interfaces belong to two different zones:

root@AMS_LAB.AMS-EHUB> ...itance | display set | match reth0
set security zones security-zone untrust-WAN_0 interfaces reth0.0

{primary:node0}
root@AMS_LAB.AMS-EHUB> ...isplay inheritance | display set | match reth1
set security zones security-zone untrust-WAN_1 interfaces reth1.0

By default, traffic reaches enterprise hub with a LAN address and leaves the enterprise hub towards the Internet with that same address. Normally, that address is a private address, meaning it cannot travel through the Internet. For this reason, it might be needed to configure a source NAT policy on the enterprise hub. By doing this, traffic coming from spokes/hub LANs will be source natted with reth0/reth1 addresses.

To achieve this, we need to configure a NAT policy on the enterprise hub.

Similarly to what we have for security intent, we go to Configuration -> NAT and create a policy:

Rule says:

• from zone trust (packets from spokes come from a GRE tunnel. GRE interface belongs to trust zone)
• from any address
• towards any address
• towards zones untrust-WAN_0/1 (reth0 and reth1 belong to them)
• perform source NAT

We deploy the rule and verify internet connectivity from EX VC IRB ifl:

{master:0}
umanferdini@ex4300-60-61-vc> ping 8.8.8.8 rapid count 10
PING 192.168.77.1 (192.168.77.1): 56 data bytes
!!!!!!!!!!
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.372/8.550/68.345/19.935 ms

It works! We are on the Internet!

Ciao
IoSonoUmberto