This page intend to list bunch of scenarios for our SD-EWAN case, including the decomposed scenarios and the overall integrated scenario.
Decomposed Scenario A: Site-to-Site tunnel with static public IP address
In this scenario, both sites have static public IP address and setup a tunnel between sites. After the tunnel is established, the clients within the site should be able to ping the clients on the other side through the tunnel. The tunnel is authenticated through pre-shared key.
IPSec CR for gateway A:
IPSec CR for gateway B:
NAT CR:
Rest calls:
Sites settings
GET /cgi-bin/luci/sdewan/ipsec/v1/sites
{ { "name": “siteA", "gateway":"192.168.1.11", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "local_identifier": "@moon.strongswan.org", "remote_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_subnet": "10.1.0.1/24", "remote_subnet": "10.2.0.1/24", "crypto_proposal": "proposal1" } ] }, { "name": "siteB", "gateway":"192.168.1.10", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "remote_identifier": "@moon.strongswan.org", "local_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_subnet": "10.2.0.1/24", "remote_subnet": "10.1.0.1/24", "crypto_proposal": "proposal1" } ] } ] |
|---|
Proposal settings
GET /cgi-bin/luci/sdewan/ipsec/v1/proposals
{ "proposals": [ { "name": "proposal1", "crypto_algorithm": "aes128", "hash_algorithm": "sha256", "dh_group": "modp3072" } ] } |
|---|
Decomposed Scenario B: Host-to-Site tunnel
In this scenario, the initiator sends out a request to the responder(either a site gateway/remote host) which has a static public ip address(or dynamic pubic IP with static domain name) in order to setup a tunnel between. After the tunnel is established, the roadwarrior should be able to ping the clients on the other side through the tunnel. The tunnel is authenticated through pre-shared key.
IPSec CR for Gateway A:
IPSec CR for roadwarrior(initiator):
NAT CR:
Rest calls:
Sites settings
GET /cgi-bin/luci/sdewan/ipsec/v1/sites
{ { "name": "siteA", "gateway":"192.168.1.11", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "local_identifier": "@moon.strongswan.org", "remote_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_subnet": "10.1.0.1/24", "remote_sourceip": "192.168.1.15", "local_sourceip": "192.168.1.10", "crypto_proposal": "proposal1" } ] }, { "name": "roadwarrior", "gateway":"192.168.1.10", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "remote_identifier": "@moon.strongswan.org", "local_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_sourceip": "192.168.1.15", "remote_sourceip": "192.168.1.10", "remote_subnet": "10.1.0.1/24", "crypto_proposal": "proposal1" } ] } ] |
|---|
Proposal settings
GET /cgi-bin/luci/sdewan/ipsec/v1/proposals
{ "proposals": [ { "name": "proposal1", "crypto_algorithm": "aes128", "hash_algorithm": "sha256", "dh_group": "modp3072" } ] } |
|---|
Decomposed Scenario C: Host-to-Site tunnel when the initiator requests an overlay IP
In this scenario, the initiator sends out a request to the responder(either a site gateway/remote host) which has a static public ip address(or dynamic pubic IP with static domain name) in order to setup a tunnel between. However, this time, the roadwarrior is also going to ask for a virtual IP that assigned by the responder. After the tunnel is established, the roadwarrior should be able to get an overlay IP and ping the clients on the other side through the tunnel. The tunnel is authenticated through pre-shared key.
IPSec CR for Gateway A:
IPSec CR for roadwarrior(initiator):
NAT CR:
Rest calls:
Sites settings
GET /cgi-bin/luci/sdewan/ipsec/v1/sites
{ { "name": "siteA", "gateway":"192.168.1.11", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "local_identifier": "@moon.strongswan.org", "remote_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_subnet": "10.1.0.1/24", "remote_sourceip": "10.3.0.1/24", "local_sourceip": "192.168.1.10", "crypto_proposal": "proposal1" } ] }, { "name": "roadwarrior", "gateway":"192.168.1.10", "crypto_proposal": "proposal1", "pre_shared_key": "test123", "authentication_method": "psk", "remote_identifier": "@moon.strongswan.org", "local_identifier": "@sun.strongswan.org", "connections": [ { "name": "connA", "type": "tunnel", "mode": "start", "local_sourceip": "%config", "remote_sourceip": "192.168.1.10", "remote_subnet": "10.1.0.1/24", "crypto_proposal": "proposal1" } ] } ] |
|---|
Proposal settings
GET /cgi-bin/luci/sdewan/ipsec/v1/proposals
{ "proposals": [ { "name": "proposal1", "crypto_algorithm": "aes128", "hash_algorithm": "sha256", "dh_group": "modp3072" } ] } |
|---|
Overall Scenario:
Here shows the overall scenario we want to achieve in the ICN SDEWAN case.
The first step would be the edge initialization. The edges will try to connect to the central Secure WAN hub through the IPsec tunnel. There could be different scenarios containing the decomposed ones listed above:
(a) Initiator to Responder tunnels where there is edge one side with public IP address(or dynamic pubic IP with static domain name). Later, using DNAT to deliver the information to pods inside the cluster.
(b) Initiator to Responder tunnels to get overlay IP address, where the edge initiator don't have public IP address. Later, using DNAT to deliver the information to pods inside the cluster.
Next, the edges would use the virtual IPs/public IPs to setup IPSec tunnels with other clusters. In some cases, they need to go through the SD-EWAN CNF inside the Secure WAN Hub as Spoke and Hub to communicate with each other.
