06-09-2023 12:22 AM
Hello colleagues! I would like to clarify one simple thing before deploying the next one project. Does anyone have a real experience in prod with the case of SD-Wan in IoT scope? The scenario is like in retail, but it will be a network of machines on the public places with planed Cisco IR series IoT sd-wan routers like IR 1101 with LTE module. The question is - which restrictions\problems will I have with public LTE or any wireless broadband channels with private IPs only? I am sure that tunnels to controllers will be established, it's ok, but what about IPsec between IR1101 and regional hubs or DC, will it work? From docs I got that yes, but wanted to clarify with anyone with real experience in prod. So the exact case is - Controllers are cisco hosted, Hubs and DCs with public IPs and like C8300 cEdges, and there will be many machines with IR1101 with wireless broadband and private IP, will they be able to establish IPsec tinnels with Hub\DC or with each other ?
Sorry for silly Q and Thanks for help in advance!
Solved! Go to Solution.
06-10-2023 01:19 AM
IoT to IoT can be established, if you have underlay network that provides connection for private network. Of course, you may not in reality need this type of connection, if you don't have such business requirement.
There is no rule that color must not be the same, it is label for interface and color type has significance. If local color private (IoT site), remote color public (HQ/DC), then public (mapped or NAT-ed IP) is used for connection. In your case, since you should do PAT for lots of private IoT sites, HQ/DC can not initiate IPSec towards IoT site (they will try, but PAT does not allow out-in initiated traffic so it fails), but IoT site can initiate and path NAT and connect to HQ/DC - so it works with PAT, unless your DC/HQ has public (not NAT-ed) or 1:1 NAT schema.
I've deployed similar type where branches had L2MPLS private connectivity. We also used PAT for MPLS site -> controller and MPLS site > HQ/DC connectivity.
So, in your case this design should work:
Private color on IoT site and site has private IP.
Public color with pure public IP on controller side.
Public color with pure public IP or 1:1 NAT on HQ/DC side.
You also need to do PAT for IoT private IP to another public IP.
In this way, IoT site will connect controllers through PAT device. IoT will connect to HQ/DC again through PAT. Although, HQ/DC can not initiate IPSec, IoT site can initiate and create tunnel.
Don't forget to allow respective traffic in firewalls (if any), and it is recommended to do NAT/PAT hair-pinning on firewalls (it works great with zoning). Also, use SD-WAN policies to block some connection (like IoT to IoT), wherever there is no business&technical requirements.
06-09-2023 11:31 AM
Hi,
in SD-WAN the main requirement for IPSec between edge devices and control traffic between edge and controller is to have IP based reachability.
If you have private IP on IoT routers, you can't do private to public IP IPSec/ GRE overlay connectivity directly . You will need the same type private interface (TLOC) on Hub/DC locations as well. Of course, to have such service in any non-IoT location may not be feasible, then you can choose and route to main locations (like HQ). Then you will have IPSec/ GRE overlay tunnel between IoT and Hub (HQ) locations. You will not have direct tunnel between IoT and other sites, however you can use route traffic from IoT site to Hub (HQ) and to another sites over there.
I also wonder, how you will do controller connectivity in case of private broadband access. Are controllers on-prem or cloud based? If on-prem where will they be located?
06-10-2023 12:49 AM
I base on 2 popular docs
1)https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-casestudy-smallbranch.html and there are many examples regarding the wireless-broadband case (5G\Lte etc)
2)the table which we can get in many sources in the internet , like here
vEdge-1 vEdge-2 IPsec tunnel can form GRE tunnel can form
No-NAT (Public IP) | No-NAT (Public IP) | YES | YES |
No-NAT (Public IP) | Symmetric | YES | NO |
Full Cone (One-to-one) | Full Cone (One-to-one) | YES | YES |
Full Cone (One-to-one) | Restricted-Cone | YES | NO |
Full Cone (One-to-one) | Symmetric | YES | NO |
Restricted-Cone | Restricted-Cone | YES | NO |
Symmetric | Restricted-Cone | NO | NO |
Symmetric | Symmetric | NO | NO |
and my planned case is - all controllers are Cisco hosted - means have public IP (non nat) , DCs and regional Hubs will have public IPs too and IoT IR1101 will have private (NAT-PAT) IPs, it's obvious - you can't get thouthands public IPs for LTE devices.
And I am just looking for any real proves from anyone that it will work 100%. IoT routers will be able to establish tunnels with DCs and Hubs. I understand that apparently they won't be able to establish IPsec tinnels to each other (IoT to IoT) due to private-to-private won't work, but anyway maybe somebody has real experience.
Again- DCs and Hubs will have public or biz-internet colours and we can do the same or choose LTE colour for IoT devices. Will it work?
to be hounest , my costomer is going to deploy a network of ATM and I am trying to convince them to use the Cisco's SD-wan instead of other legacy style solutions like robustel\teltonica\vendor X. But I need to find a reason and show advanteges of the IR1101 for around 2500$ per unit instead of around 500$, but it's another question.
06-10-2023 01:19 AM
IoT to IoT can be established, if you have underlay network that provides connection for private network. Of course, you may not in reality need this type of connection, if you don't have such business requirement.
There is no rule that color must not be the same, it is label for interface and color type has significance. If local color private (IoT site), remote color public (HQ/DC), then public (mapped or NAT-ed IP) is used for connection. In your case, since you should do PAT for lots of private IoT sites, HQ/DC can not initiate IPSec towards IoT site (they will try, but PAT does not allow out-in initiated traffic so it fails), but IoT site can initiate and path NAT and connect to HQ/DC - so it works with PAT, unless your DC/HQ has public (not NAT-ed) or 1:1 NAT schema.
I've deployed similar type where branches had L2MPLS private connectivity. We also used PAT for MPLS site -> controller and MPLS site > HQ/DC connectivity.
So, in your case this design should work:
Private color on IoT site and site has private IP.
Public color with pure public IP on controller side.
Public color with pure public IP or 1:1 NAT on HQ/DC side.
You also need to do PAT for IoT private IP to another public IP.
In this way, IoT site will connect controllers through PAT device. IoT will connect to HQ/DC again through PAT. Although, HQ/DC can not initiate IPSec, IoT site can initiate and create tunnel.
Don't forget to allow respective traffic in firewalls (if any), and it is recommended to do NAT/PAT hair-pinning on firewalls (it works great with zoning). Also, use SD-WAN policies to block some connection (like IoT to IoT), wherever there is no business&technical requirements.
06-11-2023 09:46 AM
thanks mate! seems it's acceptable
06-11-2023 01:58 PM
Hi,
please, rate comment if you have already got the answer.
06-11-2023 10:54 AM
There are two NAT'
DAI nat and service NAT
I Think what you need here is service NAT.
06-11-2023 10:56 PM
sorry mate, I meant the case where your cEdge (IR1101) is behind the NAT , lile with LTe sim card.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide