https://jira.akraino.org This file is an XML representation of an issue en-us 9.4.5 940005 11-04-2023 https://jira.akraino.org/browse/ICN-655 Integrated Cloud Native NFV <p>Current solution for multiple customers:</p> <p>Say there are X number of customers</p> <p>Say there are Y number of Hub locations</p> <p>To address Multi tenancy,  SDEWAN Hub expects X * Y number of public IP addresses.</p> <p>Each site of a customer (uCPE) would use nearest Hub for making the tunnel.</p> <p>Problem statement:</p> <ul> <li> Public IP addresses are expensive and not available.</li> </ul> <p>Enhancement request:</p> <ul> <li>Ensure that only Y number of public IPs are used.  That is number of IP addresses needed are based on number of PoP locations.</li> <li>All customers' sites that are near one hub will use the same public IP address as Hub Gateway.</li> </ul> <p>In my view, following is needed:</p> <ul> <li>SDEWAN VPN Concentrator POD shall use host network in the K8s (root network namespace) or its own network namespace like any other POD. But there is no tenant specific SDEWAN POD. It is global across all tenants.  Of course, scale-out of VPN Concentrator for load sharing though. </li> <li>Whenever VTI interface is created, based on the ID of the client, it shall assign that VTI interface to packet processing POD of the tenant.  </li> <li>Packet processing POD is the one that does rest of the packet processing such as firewall/NAT/IPSEC to other Hubs. </li> </ul> <p>It means that there shall be a controller which listens on new tunnel establishments   (IPSEC tunnel is established by BO router or or by the VPN client in PCs).  It needs to assign the new VTI interface created to tenant specific packet processing POD's namespace.</p> <p>Do let me know if that can be made possible?</p> ICN-655

Multi tenant capable SDEWAN Hub in K8s clusters with single public IP address

Epic Medium To Do Unresolved Huifeng Le Srinivasa Addepalli Tue, 19 Jul 2022 00:31:36 +0000 Mon, 25 Jul 2022 16:45:30 +0000 0 2 <p>Hi <a href="https://jira.akraino.org/secure/ViewProfile.jspa?name=hle2" class="user-hover" rel="hle2">hle2</a>,</p> <p>As I come to think about this more, I am wondering we could have a challenge if the SDEWAN VPN Concentrator is running in one physical node in the K8s cluster and the packet processing POD running on some other physical node. In that case, it is not possible to shift the VTI tunnel from one network namespace to another.</p> <p>Now, I am wondering whether the following solution would be good.</p> <ul class="alternate" type="square"> <li>VPN Concentrator PODs and packet processing PODs are connected with, say some tunnel such as GRE tunnel.</li> <li>VPN Concentrator for all the traffic for a given tenant sends the traffic GRE tunnels associated with the tenants. That is, if there are say 2 packet processing PODs for a given tenant (due to scale-out), then there would be 2 GRE tunnels. VPN Concentrator will choose a GRE tunnel for a 5 tuple session (kind of load balancing).</li> </ul> <p>This requires setting up IPTables rules and IP route rules with corresponding routing database to pass the packets among the VPN tunnels and GRE tunnels.</p> <p>What do you think?</p> <p>If that seems okay, I would imagine a controller within K8s clusters to do following</p> <ul class="alternate" type="square"> <li>Knows about all packet processing PODs and SDEWAN PODs.</li> <li>For every packet processing POD that comes up or goes down: <ul class="alternate" type="square"> <li>Knows about tenant (from the namespace).</li> <li>Knows about all SDEWAN PODs that are running (Due to scale-out, there could be multiple instances)</li> <li>Create GRE tunnels on both sides.</li> <li>Setup route policies and route tables such as way that anything that is coming out of GRE tunnel go to VPN tunnel and vice versa.</li> <li>Setup IPTables rules such a way that all the traffic for a given 5-tuple session go to the same tunnel.</li> <li>Every time new SDEWAN POD comes up (due to scale-out)</li> <li>Repeat the above process.</li> </ul> </li> </ul> <p>Different tenants will certainly will need to have different tunnels.</p> <p>In case of one tenant, there could be multiple Branch offices and multiple WFH users connecting to the same Hub. In that case, there could be multiple tunnels - At least one from each branch office and at least one from each WFH user.   In summary,  there are multiple tunnels.  You can assume that a given tunnel is not shared by multiple tenants. </p> <p> </p> <p>Identification of tenant :  It shall be based on Initiator ID (<a href="https://datatracker.ietf.org/doc/html/rfc4306#section-3.5" class="external-link" target="_blank" rel="nofollow noopener">https://datatracker.ietf.org/doc/html/rfc4306#section-3.5</a>).  Since, Client IP can't be used as Client IP gateway can be dynamic IP address.  Tenant determination from tunnel establishment, in my mind can be</p> <ul> <li>Based on email address (getting domain name from the email address)</li> <li>Domain name itself</li> </ul> <p><a href="https://jira.akraino.org/secure/ViewProfile.jspa?name=saddepalli" class="user-hover" rel="saddepalli">saddepalli</a> Some opens:<br/> 1. Different tenants will share same tunnel or different tunnels (with different client ip/oip + same hub ip), as VTI interface (also the related iptable rules) is created in strongswan's updown script, maybe not able to create multiple VTI interface in same tunnel.<br/> 2. How to identify client id? based on different client ip? </p> Development Epic Color ghx-label-1 Epic Name Multi-tenant capable SDEWAN Hub in K8s cluster Epic Status Rank 0|i005vg: