Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page intend to list bunch of scenarios for our SD-EWAN case, including the decomposed scenarios and the overall integrated scenario.


Table of Contents


Decomposed scenarios

Decomposed Scenario A: Site-to-Site tunnel with static public IP address

In this scenario, both sites have static public ip 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.

Image Modified

...

Scenario Description:

...

languageyml

...

Tunnel between site A and site B
Suppose there are two sites A and B. A comes with the subnet 10.1.0.1/24, B comes with the subnet 10.2.0.1/24
Gateway for A is 192.168.1.10

...


Gateway for B is 192.168.1.11
A and B would like to establish a tunnel
10.1.0.1/24 == 10.2.0.1/24

CRs for the scenario

Code Block
languageyml
titleProposal CR
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecProposal
metadata:
  name: test_proposal_1
  namespace: default
  labels:
    local_nat:
    local_sourceip: 192.168.1.10
    local_firewall: yes
    remote_subnet: 10.2.0.1/24sdewanPurpose: cnf-1
spec:
    remoteencryption_sourceipalgorithm: 192.168.1.11aes128
    remotehash_firewallalgorithm: yessha256
    keyexchange: ikev2dh_group: modp3072
status:
    crypto_proposalappliedVersion: "proposal11"
  proposalappliedTime:
  - encryption_algorithm: aes128"2020-04-12T09:28:38Z"
    hash_algorithminSync: sha256
    dh_group: modp3072

...

True


Code Block
languageyml
titleSample CR for gateway

...

code
A
collapselanguagetrueyml
apiVersion: sdewan sdewan.akraino.org/v1alpha1
kind: IPSecSite IpsecSite
metadata:
  name: siteA
  namenamespace: siteBdefault
spec  labels:
  node  sdewanPurpose: node2cnf-1
spec:
  gatewayremote: 192.168.1.11
  authentication_method: psk
  pre_shared_key: W1xnGqoBZizf2iQN6OwoEGhdFNnQQ81KnqaPNY9fdr3zFV72fFDLlXmWnjXk5EONtest123
  authcrypto_methodproposal: psk
  local_identifier: @moon.strongswan.org   - test_proposal_1
  remote_identifier: @sun.strongswan.orgconnections:
  crypto_proposal: "proposal1"
 - forceconnection_crypto_proposalname: trueconnection_A
  connection:
   - type: tunnel
      mode: start
      local_subnet: 10.21.0.1/24
    local_nat:
    localremote_sourceipsubnet: 19210.1682.0.1.11/24
    local  crypto_firewallproposal: 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"

test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Code Block
languageyml
titleSample CR for gateway B
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: siteB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 

...

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"

...


  authentication_method: psk
  pre_shared_key: test123
  crypto_proposal: 
    - test_proposal_1
  connections:
    - connection_name: connection_B
      type: tunnel
      mode: start
      local_subnet: 10.2.0.1/24

...


      remote_subnet

...

:

...

 10.1.0.1/24

...


      crypto_proposal

...

              }

        }

    ]
}

:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True

Rest calls

Sites settings

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

{
    "sites": [

     {

            "name": “siteA",

            "remote":"192.168.1.11",

            "crypto_proposal": "test_proposal_1",

            "pre_shared_key": "test123",

            "authentication_method": "psk",

            "connections": [

              { "name": "connection_A",

                "type": "tunnel",

                "mode": "start",

                "local_subnet": "10.1.0.1/24",

                "remote_subnet": "10.2.0.1/24",

                "crypto_proposal": "test_proposal_1"

              }

            ]

        },

       {    "name": "siteB",

            "gateway":"192.168.1.10",

            "crypto_proposal": "test_proposal_1",

            "pre_shared_key": "test123",

            "authentication_method": "psk",

            "remote_identifier": "@moon.strongswan.org",

            "local_identifier": "@sun.strongswan.org",

            "connections": [

              { "name": "connection_B",

                "type": "tunnel",

                "mode": "start",

                "local_subnet": "10.2.0.1/24",

                "remote_subnet": "10.1.0.1/24",

                "crypto_proposal": "test_proposal_1"

              }

        ]

      }

   ]
}

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 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.

Image Added

Scenario Description:

Tunnel between site A and host B(Responder and Initiator)
Suppose there is one site A and one host B. A comes with the subnet 10.1.0.1/24.
Gateway for A is 192.168.1.10 which is a public ip address
Host B has no public address and want to request one from the peer(suppose the vip assigned is 10.3.0.12)
A and B would like to establish a tunnel
10.1.0.1/24 == 10.3.0.12/32

CRs for the scenario

Code Block
languageyml
titleProposal CR
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecProposal
metadata:
  name: test_proposal_1
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  encryption_algorithm: aes128
  hash_algorithm: sha256
  dh_group: modp3072
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Code Block
languageyml
titleSample CR for gateway A
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: siteA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: %any
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal: 
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_subnet: 10.1.0.1/24
      remote_sourceip: 10.3.0.1/24
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Code Block
languageyml
titleSample CR for host B
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: hostB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 192.168.1.10
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal: 
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: %config
      remote_subnet: 0.0.0.0/0
      crypto_proposal:
        - test_proposal_1 
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Rest calls

Sites settings

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

{
    "sites": [

       {    "name": "siteA",

            "remote":"%any",

            "crypto_proposal": "test_proposal_1",

            "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",

                "crypto_proposal": "test_proposal_1"

              }

            ]

        },

       {    "name": "hostB",

            "remote":"192.168.1.10",

            "crypto_proposal": "test_proposal_1",

            "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_subnet": "10.1.0.1/24",

                "crypto_proposal": "test_proposal_1"

              }

        ]

      }

   ]
}

Proposal settings

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

{ "proposals": [

        {

              "crypto_algorithm": "aes128",

              "hash_algorithm": "sha256",

              "dh_group": "modp3072"

         }

     ]

}

Decomposed Scenario C: Host to host tunnel

Setup a tunnel between the host who got assigned the virtual IP and another host with PIP.

Image Added

Scenario Description:

Tunnel between host A and host B
Suppose there are two hosts A and B.
A has a public ip which is 192.168.3.1
B is a host which already get a vip 10.3.0.12
A and B would like to establish a tunnel
192.168.3.1/32 == 10.3.0.12/32

CRs for the scenario

Code Block
languageyml
titleProposal CR
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecProposal
metadata:
  name: test_proposal_1
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  encryption_algorithm: aes128
  hash_algorithm: sha256
  dh_group: modp3072
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Code Block
languageyml
titleSample CR for host A
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: hostA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: %any
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal: 
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      remote_sourceip: 10.3.0.12
      crypto_proposal:
        - test_proposal_1 
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Code Block
languageyml
titleSample CR for host B
collapsetrue
apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: hostB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 192.168.3.1
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal: 
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: 10.3.0.13
      crypto_proposal:
        - test_proposal_1 
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True


Rest calls

Sites settings

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

{
    "sites": [

       {    "name": "hostA",

            "remote":"%any",

            "crypto_proposal": "test_proposal_1",

            "pre_shared_key": "test123",

            "authentication_method": "psk",

            "local_identifier": "@moon.strongswan.org",

            "remote_identifier": "@sun.strongswan.org",

            "connections": [

              { "name": "connA",

                "type": "tunnel",

                "mode": "start",

                "remote_sourceip": "10.3.0.12",

                "crypto_proposal": "test_proposal_1"

              }

            ]

        },

       {    "name": "hostB",

            "remote":"192.168.3.1",

            "crypto_proposal": "test_proposal_1",

            "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": "10.3.0.12",

                "crypto_proposal": "test_proposal_1"

              }

        ]

      }

   ]
}

Proposal settings

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

{ "proposals": [

        {

              "crypto_algorithm": "aes128",

              "hash_algorithm": "sha256",

              "dh_group": "modp3072"

         }

     ]

}

Targeted Scenarios

Scenario A: Edge to traffic hub tunnel where inter micro-service communication across edges that attached to same traffic hub.

Image Added

Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for edgeA
collapsetrue
CR for sdewan cnf on edgeA:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.160.22
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: %config
      remote_subnet: 0.0.0.0/0, 10.239.160.22/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeA
collapsetrue
Strongswan configs for sdewan cnf on edgeA:

conn siteA-connA
  left=%any
  right=10.239.160.22
  leftsourceip=%config
  rightsubnet=0.0.0.0/0,10.239.160.22/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  esp=aes192-sha1-modp3072
  ike=aes192-sha1-modp3072
  type=tunnel




Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for edgeB
collapsetrue
CR on sdewan cnf on edgeB:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.160.22
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: %config
      remote_subnet: 0.0.0.0/0, 10.239.160.22/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeB
collapsetrue
Strongswan configs for sdewan cnf on edgeB:

conn edgeB-connA
  left=%any
  right=10.239.160.22
  leftsourceip=%config
  rightsubnet=0.0.0.0/0,10.239.160.22/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  esp=aes192-sha1-modp3072
  ike=aes192-sha1-modp3072
  type=tunnel




Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for Hub
collapsetrue
CR on sdewan on hub:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: Hub
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: %any
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_subnet: 172.12.0.1/24,10.239.160.22/32
      remote_sourceip: 172.12.0.1/24
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for hub
collapsetrue
Strongswan configs for sdewan cnf on hub:

conn tunnel
  left=10.239.160.22
  leftsubnet=172.12.0.1/24,10.239.160.22/32
  rightsourceip=172.12.0.30-172.12.0.45
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel






Scenario B: Edge to Edge tunnels when micro-service communication happens across edges without involving hubs

Image Added


Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for EdgeA
collapsetrue
CR on sdewan cnf on edgeA:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.40.42
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeA
collapsetrue
Strongswan configs for sdewan cnf on edgeA:

conn edgeA-connection_A
  left=%any
  right=10.239.40.42
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel




Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for EdgeB
collapsetrue
CR on sdewan cnf on edgeB:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.160.22
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeB
collapsetrue
Strongswan configs for sdewan cnf on edgeB:

conn edgeB-connection_A
  left=%any
  right=10.239.160.22
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel




Scenario C: Hub to hub tunnel when inter micro-service communication across edges that attached to different traffic hubs

Image Added

Section
bordertrue


Column
width40%



Code Block
languageyml
titleSample CR for edgeA
collapsetrue
CR for sdewan cnf on edgeA:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.160.22
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: %config
      remote_subnet: 0.0.0.0/0, 10.239.160.22/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeA
collapsetrue
Strongswan configs for sdewan cnf on edgeA:

conn edgeB-connection_A
  left=%any
  right=10.239.160.22
  localsourceip=%config
  rightsubnet=0.0.0.0/0,10.239.160.22/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel




Section
bordertrue


Column
width40%



Code Block
languageyml
titleSample CR for edgeB
collapsetrue
CR for sdewan cnf on edgeB:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecHost
metadata:
  name: edgeB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.40.42
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_sourceip: %config
      remote_subnet: 0.0.0.0/0, 10.239.40.42/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for edgeB
collapsetrue
Strongswan configs for sdewan cnf on edgeB:

conn edgeB-connection_A
  left=%any
  right=10.239.40.42
  localsourceip=%config
  rightsubnet=0.0.0.0/0,10.239.40.42/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel




Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for HubA
collapsetrue
CR on sdewan on hubA:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: HubA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: %any
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_subnet: 172.12.0.1/24,10.239.160.22/32
      remote_sourceip: 172.12.0.30-172.12.0.45
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True

---

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: HubA
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.40.42
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_B
      type: tunnel
      mode: start
      local_subnet: 172.12.0.1/24,10.239.160.22/32
      remote_subnet: 172.12.1.1/24,10.239.40.42/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for HubA
collapsetrue
Strongswan configs for sdewan cnf on hub:

conn HubA-connection_A
  left=%any
  leftsubnet=172.12.0.1/24,10.239.160.22/32
  rightsourceip=172.12.0.30-172.12.0.45
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel
conn HubA-connection_B
  left=%any
  leftsubnet=172.12.0.1/24,10.239.160.22/32
  rightsubnet=172.12.1.1/24,10.239.40.42/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel






Section
bordertrue


Column
width40%


Code Block
languageyml
titleSample CR for HubB
collapsetrue
CR on sdewan on hubB:

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: HubB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: %any
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_A
      type: tunnel
      mode: start
      local_subnet: 172.12.1.1/24,10.239.40.42/32
      remote_sourceip: 172.12.1.31-172.12.1.35
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True

---

apiVersion: sdewan.akraino.org/v1alpha1
kind: IpsecSite
metadata:
  name: HubB
  namespace: default
  labels:
    sdewanPurpose: cnf-1
spec:
  remote: 10.239.160.22
  authentication_method: psk
  pre_shared_key: test
  crypto_proposal:
    - test_proposal_1
  connections:
    - connection_name: connection_B
      type: tunnel
      mode: start
      remote_subnet: 172.12.0.1/24,10.239.160.22/32
      local_subnet: 172.12.1.1/24,10.239.40.42/32
      crypto_proposal:
        - test_proposal_1
status:
  appliedVersion: "1"
  appliedTime: "2020-04-12T09:28:38Z"
  inSync: True



Column
width20%

The CRs defined will then be interpreted into some IPSec configuration that could be recognized by Openwrt and then translate to Strongswan configs


Column
width40%


Code Block
languageyml
titleStrongswan configs for HubB
collapsetrue
Strongswan configs for sdewan cnf on hub:

conn HubB-connection_A
  left=%any
  leftsubnet=172.12.1.1/24,10.239.40.42/32
  rightsourceip=172.12.1.31-172.12.1.35
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel
conn HubA-connection_B
  left=%any
  leftsubnet=172.12.1.1/24,10.239.40.42/32
  rightsubnet=172.12.0.1/24,10.239.160.42/32
  leftauth=psk
  rightauth=psk
  auto=start
  keyexchange=ikev2
  ike=aes192-sha1-modp3072
  esp=aes192-sha1-modp3072
  type=tunnel





Overall scenarios

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.

Image Added

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. 

Image Added

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.

Image Removed

IPSec CR for Gateway A:

Code Block
languageyml
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):

Code Block
languageyml
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.

Image Removed

IPSec CR for Gateway A:

Code Block
languageyml
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):

Code Block
languageyml
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.

Image Removed