As a result, it might happen that between customer devices and cloud-based OAM we have a device performing NAT. Juniper SDWAN architecture requires tunnels to be created between each device (spokes and hubs) and the OAM hubs. This means CSO server, vRR and OAM hubs are deployed outside the customer network. In that case, CSO is deployed at Juniper premises, not at customer premises. If we think about the Juniper SDWAN solution, this is what we might face when using CSO as a cloud service. This is also the use-case where an endpoint has a dynamic ip so we cannot rely on that to establish tunnels. In order to overcome this, IKE will rely on something else to distinguish the two spokes. As a consequence the IKE gateways configured on the hub cannot use the IP address to distinguish between the two tunnels. This means that traffic originated at the spokes will have the same source IP when reaching the hub. Between spokes and hub we have a device performing source NAT. We have two spoke devices that need to create a tunnel with a hub device. Things might be a little more complex sometimes. In those scenarios, both endpoints addresses were known and fixed. In previous posts I talked about creating route-based site-to-site ipsec tunnels.
0 Comments
Leave a Reply. |