This document is your step-by-step guide to configure inbound port-forwarding on Aruba edge connect SDWAN appliance. This document will walk you through single appliance deployment as well as traditional and edge ha deployment scenarios. I am using my lab to elaborately explain the process using screenshots.
My Atlanta sites deployment profile. This is a Traditional HA site with comcast business internet (simulated) connected to ECV2-ATL and MPLS on ECV1-ATL. Just pretend ECV2-ATL is the only appliance for this site.
Our Goal:
On the left we have 3 sub-interfaces on Lan side. Goal here is to comcast router (aka a client on the internet) be able to connect to Atlanta-R1 on port 22 (SSH). Don’t get confused with source being my comcast router which has a direct route to ECV2-ATL. I have configured WAN1 on ECV2-ATL firewal as Stateful+Snat. This mean any traffic generated from outside to inside will be blocked, outbound traffic will be nat’d and return traffic will be allowed. Hence without doing something our desired traffic will not make it to Atlanta-R1
Current Port-forwarding rule on ECV2-ATL, nothing. Inbound port-forwarding is located on
Configuration > Overlay & Security >Security >Inbound Port-Forwarding
Here is to show comcast route has the route for ECV2-ATL wan1 port but it can not ping it. This is the IP where we will be doing port-forwarding. I know I know this is a private IP. This is my Lab and I am just pretending this as public. Does it really matter ?
From Comcast routers prospective.
As you can see that 10.110.109.101 is directly connected but ping fails due to Stateful+snat.
SSH is going to break as there is not inbound port-forwarding rule set yet.
Configure inbound port-forwarding
Now let’s set the inbound port-forwarding rule and test again.
This rule is stating If traffic matching from Source IP/Subnet 0.0.0.0/0 (from anywhere) to Destination IP/subnet 10.110.109.101/32 (to this IP 10.110.109.101/32) on tcp port 22, it will be forwarded to 10.1.2.1
When you apply these settings, that is all. Bingo
No more additional settings needed
Here is the flow for this SSH session in flows table.
This is all fine for single appliance deployments. This is also fine for both traditional and edge-ha scenario. Special consideration needed for the later scenarios. When you need a site to be highly available you use Aruba SDWAN Traditional or Edge HA model deployments.
Traditional HA:
In this deployment model you have 2 Aruba SDWAN edge connect appliances each with all available wan transport. E.g., you have site with MPLS and Comcast business internet. Traditional HA will require you to connect both MPLS and Internet to both your appliances. This is a bit costly deployment where you most probably needed one or a stack of switches and /29 ip space from your Internet service provider. One for each appliance and the 3rd one for ISP gateway device.
Edge HA:
In this deployment model you have 2 Aruba SDWAN appliance have one of the ISP and sharing their own connection using an interconnected link.
Scenarios
Doesn’t matter which deployment method you pick for your site, there will a way to designate one of these appliances to take traffic from lan side network. We use vrrp to make one of them a mater. Lan side router can send the traffic to vrrp IP and SDWAN appliance will do the rest.
I am explaining all of these to make sure you understand the gotcha of inbound port-forwarding with these HA deployments. This works as explained for Traditional and edge ha scenario when your active vrrp appliance has the ISP and IP where you want to configure port-forwarding. ECV2-ATL hosting vrrp master role (for the lan side) and has the INet1 where we have the port-forwarding configured.
But if ECV1-ATL becomes the vrrp master, this inbound port-forwarding will break. Simply because return traffic from lan will chose ECV1-ATL as next hop and will get nat’d on edge-ha as well as wan1.109 INET1 interface. This is so weird because return traffic does come back to ECV2-ATL as that is our only appliance with internet connection.
Internet –> ECV2-ATL WAN1–>10.110.109.101:22–> 10.1.2.1:22
10.1.2.1 –> ECV1-ATL Lan0.20 –> ECV1-ATL wan1 (Nat)–> ECV2-ATL wan0 (Nat)–> ECV2-ATL wan1 (Nat)–This breaks the flow.
FAQ
Why not make ECV2-ATL vrrp primary? (Kudos if you did ask that question)
Answer: True that is one of the resolutions. If you have MPLS on ECV1-ATL (just like my diagram) and DO NOT have any non-sdwan sites, then this will be a good solution. If you have sites that is still on legacy routers with same MPLS provider, connectivity to that site will take a much longer and it will also be asymmetric.
Non SDWAN site 10.1.5.0/24 –> route for 10.1.2.0/24–> ECV1-ATL using MPLS.
ECV2-ATL (vrrp master) –> route for 10.1.5.0/24–> SDWAN HUB –> pass-through MPLS –> SDWAN site 10.1.5.0/24
This will not be optimal traffic flow and we are way off topic. Let’s jump to a solution to the original issue that is “Successful inbound port-forwarding for Traditional and Edge HA solution.”
Solution
We all know now that only inbound port-forward will not work in Edge-ha or Traditional HA scenario. Yes, we are still talking about Aruba SDWAN deployment and this topic is regarding forwarding ports to internal devices. So, your inbound traffic makes it to appropriate appliance and from there its straightforward lan routing to end device. Return traffic follows default path. Only if somehow, we can force it to go to the correct appliance, it will be all ok then.
Below picture will explain what is happening and what we hope to happen. Return traffic takes the default path with red arrow. We need to find a way for it to take the green arrow for only interesting return traffic.
Our solution is SaaS Nat feature. It is so simple and was added in 8.3.5 version of Orchestrator.
SaaS nat along with inbound port-forwarding get this job done exactly how we want it.
- Port-forward brings the traffic flow to end device
- SaaS nat as it sounds source nat that traffic on the ECV2-ATL lan0.x port.
So, Atlanta-R1 (10.1.2.1) sees this traffic from 10.1.2.12 and exactly return the traffic to 10.1.2.12 our ECV2-ITL. We know that ECV2-ATL is keeping up with all these nat entries. So, it simply sends it back to where it came from via Wan1.109 interface. This part of that flow is based on the inbound port-forwarding rule.
Inbound traffic
Internet –> ECV2-ATL WAN1 –>10.110.109.101:22–> 10.1.2.12:22–> 10.1.2.1:22
< —–Inbound Port-Forward rule on ECV2-ATL—- >< –SaaS Nat rule on ECV2-ATL – >
Outbound traffic
10.1.2.1–> 10.1.2.12 (ECV2-ATL Lan0.20) –> 10.110.109.101 (ECV2-ATL wan1)–>Original Source
< ——-SaaS Nat rule on ECV2-ATL —— >< — Port-Forward rule on ECV2-ATL—– >
Here is the SaaS nat configured. Its under Configuration>Templates & Policies > Policies > SaaS NAT Policies
Click on Advance Settings and “Add Rule” and configure it like this
Now for some reason if vrrp master role moves to ECV2-ATL, this SaaS nat rule is no longer needed. It doesn’t cause any issue. But without this your inbound port-forwarding won’t work if the same appliance is not the vrrp master.
So, it is of best interest to have SaaS nat rule in place for each inbound nat rule corresponding on each appliance. I really hope this document made sense and help you in your time in need. If that is the case, please donate for my effort. I appreciate your donations.