Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: siteA
spec:
  node: node1
  gateway: 192.168.1.10
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @moon.strongswan.org
  remote_identifier: @sun.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 10.1.0.1/24
    local_nat:
    local_sourceip: 192.168.1.10
    local_firewall: yes
    remote_subnet: 10.2.0.1/24
    remote_sourceip: 192.168.1.11
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

IPSec CR for gateway B:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: siteB
spec:
  node: node2
  gateway: 192.168.1.11
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @moon.strongswan.org
  remote_identifier: @sun.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 10.2.0.1/24
    local_nat:
    local_sourceip: 192.168.1.11
    local_firewall: yes
    remote_subnet: 10.1.0.1/24
    remote_sourceip: 192.168.1.10
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

NAT CR:

Rest calls:

GET /cgi-bin/luci/sdewan/ipsec/v1/sites

{
    "sites": [

        {

            "name": "siteA"

            "gateway":"192.168.1.10",

            "crypto_proposal": "proposal1",

            "connections": [

              {

                "type": "tunnel"

                "local_subnet": "10.1.0.1/24",

                "remote_subnet": "10.2.0.1/24",

                "crypto_proposal": "proposal1"

              }

        },

       {

            "name": "siteB"

            "gateway":"192.168.1.11",

            "crypto_proposal": "proposal1",

            "connections": [

              {

                "type": "tunnel"

                "local_subnet": "10.2.0.1/24",

                "remote_subnet": "10.1.0.1/24",

                "crypto_proposal": "proposal1"

              }

        }

    ]
}

Decomposed Scenario B: Host-to-Site tunnel 

In this scenario, the initiator sends out a request to the site gateway(responder) 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:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: siteA
spec:
  node: node1
  gateway: 192.168.1.10
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @moon.strongswan.org
  remote_identifier: @roadwarrior.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 10.1.0.1/24
    local_nat:
    local_sourceip: 192.168.1.10
    local_firewall: yes
    remote_subnet: 
    remote_sourceip: 192.168.1.15
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

IPSec CR for roadwarrior(initiator):

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: roadwarrior
spec:
  node: roadwarrior
  gateway: 192.168.1.15
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @roadwarrior.strongswan.org
  remote_identifier: @sun.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 
    local_nat:
    local_sourceip: 192.168.1.10
    local_firewall: yes
    remote_subnet: 10.1.0.1/24
    remote_sourceip: 192.168.1.10
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

NAT CR:


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 site gateway(responder) 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:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: siteA
spec:
  node: node1
  gateway: 192.168.1.10
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @moon.strongswan.org
  remote_identifier: @roadwarrior.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 10.1.0.1/24
    local_nat:
    local_sourceip: 192.168.1.10
    local_firewall: yes
    remote_subnet: 
    remote_sourceip: 10.3.0.1/24
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

IPSec CR for roadwarrior(initiator):

apiVersion: sdewan.akraino.org/v1alpha1
kind: IPSecSite
metadata:
  name: roadwarrior
spec:
  node: roadwarrior
  gateway: 192.168.1.15
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EON
  auth_method: psk
  local_identifier: @roadwarrior.strongswan.org
  remote_identifier: @sun.strongswan.org
  crypto_proposal: "proposal1"
  force_crypto_proposal: true
  connection:
  - type: tunnel
    mode: start
    local_subnet: 
    local_nat:
    local_sourceip: %config
    local_firewall: yes
    remote_subnet: 10.1.0.1/24
    remote_sourceip: 192.168.1.10
    remote_firewall: yes
    keyexchange: ikev2
    crypto_proposal: "proposal1"
  proposal:
  - encryption_algorithm: aes128
    hash_algorithm: sha256
    dh_group: modp3072

NAT CR:


Overall Scenario:

Here show the overall scenario we want to achieve in the ICN SDEWAN case.

  • No labels