❓

Why are tunnels not coming up?

1. Several reasons – while UPD tunnels use “hole punching” there are limitations.
2. Supported tunnel Formation
3. Configuration issues
4. Firewall Rules
5. Rules in Cloud services such as “Cloudflare”

✔️

Troubleshooting (brief) Check list:

• Layer 1
• Layer 2
• Labels
• Overlays (Verified applied to EC's)
• Overlays (verified added Labels to SDWAN Overlays)
• Overlays (verified Labels have correct cross connect groups)
• Region(s)
• Orchestration (maintenance mode)
• Orchestration - two EC are trying to build tunnels on the same public IP (see alarms)
• Deployment > NAT setting
• ALARMS
• Inbound NAT discovery
• Firewall Rules/log (external to EC)
• TCP DUMP from CLI (verify packets reaching both sides, and ports, see below)
• Tunnel exceptions
• Edge connects have same site name

↩️

Click the “DOWN” for information – in this case NAT discovery is failing.

• My LAB SRX firewall Is dropping the tunnel traffic because ports do not match up (discovery is failing)

1. Let’s investigate- notice one side has two private IP addresses above.
   1. This points to NAT issue.
   2. Right Click on appliance from left tree > deployment
   3. LAB-DC is set for NAT.
   4. This is Correct – Behind Starlink NAT/CGNAT

In
14:40:04.873699:LSYS-ID-00 98.97.12.231/21170-->x.x.222.41/12000;udp,  
Out  
In: 192.168.99.58/12000 --> 98.97.12.231/12000;udp,  
Out: 98.97.12.231/12000 --> x.x.222.41/1454;udp,<<<< NOTE: incorrect port

BRANCH-RT - is set for “NOT BEHIND NAT”
This is wrong – Connection is non static LTE has a private IP address via DHCP to EC WAN interface.

Let’s change this and see what happens

Tunnels remain Down.

Firewall CGNAT examples

This connection is CG-NAT to CG-NAT  
•	IN (sending traffic to port 12,000 expecting on 21,170)  
		98.97.12.231/21170-->x.x.222.41**/12000**;udp  
•	OUT (expecting traffic on port 1454 sending 12,000)  
		In: 192.168.99.58/12000 --> 98.97.12.231/12000;udp, ,  
		Out: 98.97.12.231/12000 --> x.x.222.41/**1454;**udp, Conn  
•	Notice port mismatches – Currently tunnels cannot establish with CG-NAT on both sides of the Tunnel.

HUB sites – (Applies to Full Mesh appliances as well)

1. Direct Public IP Best practice
2. Will work with 1:1 NAT (2nd preferred method)
3. Will work with Port Forwarding (3rd method -better at branch and not HUB location)
   1. Turn off outbound port translation (PAT)
   2. Not 100% needed but helps.
   3. 
      
4. Security considerations
   1. Will NOT work behind CG-NAT
   2. 
      

5. 🚧

   Got-yah! – sometimes CG-NAT tunnels will come up on pure luck, however they usually do not stay up and will drop randomly!

Now you have tunnels. If you have the LAN side plugged in and routing, and devices on each side, you should be able to pass traffic.

Able to ping from branch to branch.

This ping is flowing path: Branch-RT (LTE WAN) > HUB (Fiber-in) (hairpin) > Hub (Fiber-out) > Branch-L2 (Starlink) | See trace below.
The Echo is the same path in reverse. Hub and spoke – hairpins in hub.