Tech Reference: VMware Cloud on AWS - Managing IPSec VPN using API

Introduction

You can use the IPSec VPN API to automate the build and config process making it ideal for automated testing processes, repeatable consistent builds, and in some cases, providing access to advanced options that are not available using the UI. This document explains the different components and options of the IPSec VPN API and provides sample API requests to help you build your configuration. 

Working on a VPN using the API requires understanding the following different components, as well as their relationships:

-          IKE Profiles

-          Tunnel (IPSec) Profiles

-          DPD Profiles

-          BGP neighbors

-          VPN Sessions

-          And optionally, prefix-lists.

It also requires knowledge of the different options available and, of course, the correct syntax.

We’ll start with the assumption that you are already familiar with using the API in VMware Cloud on AWS. This means you should be able to identify the NSX-T endpoint you want to use (either the reverse proxy or the internal NSX-T endpoint). We’ll use the reverse proxy in this document, since if this is the first VPN you’re creating, you may not yet have access to the internal NSX-T endpoint. You also need to have a refresh token for your account with the appropriate NSX Cloud permissions, and be familiar with how to request an access token with it, which is how we will authenticate to the NSX-T endpoint.

In this guide, the URLs provided must be prefixed by the full Endpoint URL.

For details on how to get an API token, identify the Endpoint URL to use, and how to authenticate API requests, please refer to this page.

Note: String values in the JSON payloads are case sensitive, so ensure to observe the case provided.

Core VPN configuration

System defined objects

An IPSec VPN definition in VMware Cloud on AWS depends upon both system-defined objects and user-defined objects. The system defined objects are the IP Endpoint (either public IP or private IP ), and the default DPD profile. DPD stands for Dead Peer Detection, which is a keepalive mechanism used to determine when an IKE peer has stopped responding, so the session can be restarted or its routes quickly removed to allow failover to another path. The default system profile cannot be modified.

The default DPD profile is:

/infra/ipsec-vpn-dpd-profiles/nsx-default-l3vpn-dpd-profile

 

The Private IP Endpoint is:

/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/local-endpoints/Private-IP1

 

The Public IP Endpoint is:

/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/local-endpoints/Public-IP1

 

These paths are referenced in the IPSec VPN Session for any VPN configuration you define.

Encryption Options

The IKE and Tunnel profiles define the encryption and tunnel configuration parameters. The following are the available values for each of the keys. Note that there are certain combinations that are not compatible, so ensure to check the response for any errors. For example, GCM ciphers do not require a digest algorithm, and require IKE V2. These keys and values are case sensitive.

Key

Value options

encryption_algorithms

 

AES_128

AES_256

AES_GCM_128

AES_GCM_192

AES_GCM_256

digest_algorithms

SHA1

SHA2_256

dh_groups

GROUP2

GROUP5

GROUP14

GROUP15

GROUP16

GROUP19

GROUP20

GROUP21

ike_version

IKE_V1

IKE_V2

IKE_FLEX

df_policy

COPY

CLEAR

IKE Profile

IKE profiles are located at the following path:

/infra/ipsec-vpn-ike-profiles

 

To define a new IKE profile (aka Phase 1), send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/ipsec-vpn-ike-profiles/VPNtoDFWDC1IKE). The request body should contain a JSON object based on the example below, which configures the IKE encryption cipher, digest algorithm (no digest is used in this example), IKE version and Diffie-Hellman (DH) Group 21. It also sets the IKE SA lifetime to 86400 seconds.

The id and display_name values should be set to the same string as is used in the URL to define the profile. This ID will be referenced in the VPN Session configuration later on. Items in bold should be updated to reflect the desired options.

{

            "digest_algorithms": [],

            "encryption_algorithms": [

                "AES_GCM_128"

            ],

            "ike_version": "IKE_V2",

            "dh_groups": [

                "GROUP21"

            ],

            "sa_life_time": 86400,

            "resource_type": "IPSecVpnIkeProfile",

            "id": "VPNtoDFWDC1IKE",

            "display_name": "VPNtoDFWDC1IKE"

}

 

Once you have successfully created a profile, you can view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields.

If you want to modify a profile that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. However, to modify an existing object, you must use the PATCH method. To delete a profile, send a DELETE request to the same URL as the PUT used to create it with an empty body. Note the IKE profile cannot be deleted while it is referenced by a VPN Session. Delete the VPN session before deleting the IKE profile.

Tunnel Profile

Tunnel profiles are located at the following path:

/infra/ipsec-vpn-tunnel-profiles

 

To define a new Tunnel profile (aka Phase 2), send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/ipsec-vpn-tunnel-profiles/VPNtoDFWDC1IPSEC). The request body should contain a JSON object based on the example below, which configures the IPSec encryption cipher, digest algorithm (no digest is used in this example), Diffie Hellman (DH) Group and Perfect Forward Secrecy (PFS) state. The SA lifetime is set to 3600 seconds. It’s generally recommended to use the same settings for the IPSec profile as for the IKE profile, except for the SA lifetime which should be left at the value.

The id and display_name values should be set to the same string as is used in the URL to define the profile. This ID will be referenced in the VPN Session configuration later on. Items in bold should be updated to reflect the desired options.

The options for each key are the same as for IKE, with the addition of df_policy. This key defines whether the value of the DF (Don’t Fragment) bit for a packet should be copied from the inside packet or cleared. The default of COPY is recommended.

{

            "digest_algorithms": [],

            "encryption_algorithms": [

                "AES_GCM_128"

            ],

            "enable_perfect_forward_secrecy": true,

            "dh_groups": [

                "GROUP21"

            ],

            "sa_life_time": 3600,

            "df_policy": "COPY",

            "resource_type": "IPSecVpnTunnelProfile",

            "id": "VPNtoDFWDC1IPSEC",

            "display_name": "VPNtoDFWDC1IPSEC"

 }

 

Once you have successfully created a profile, you can view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields.

If you want to modify a profile that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. However, to modify an existing object, you must use the PATCH method. To delete a profile, send a DELETE request to the same URL as the PUT used to create it with an empty body. Note the tunnel profile cannot be deleted while it is referenced by a VPN Session. Delete the VPN session before deleting the tunnel profile.

DPD Profile

DPD profiles are located at the following path:

/infra/ipsec-vpn-dpd-profiles/

 

The default system DPD profile should be used when possible. Changing the values may result in an unstable VPN connection. To define a new DPD profile, send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/ipsec-vpn-dpd-profiles/nsx-custom-l3vpn-dpd-profile). The request body should contain a JSON object based on the example below, which configures the dpd probe mode and timer values. The dpd_probe_mode of PERIODIC sends a probe every time the specified dpd_probe_interval is reached (between 3-360 seconds, default is 60). The dpd_pobe_mode of ON_DEMAND sends a probe if no IPSec packet is received from the peer after an idle period specified by the dpd_probe_interval value (between 1-10 seconds, default is 3). The retry_count specifies the number of retries before the peer is declared dead. After a peer is declared dead, the SAs for the dead peer’s link are torn down.

 

{

    "enabled": true,

    "dpd_probe_mode": "PERIODIC",

    "dpd_probe_interval": 60,

    "retry_count": 5,

    "resource_type": "IPSecVpnDpdProfile",

    "id": "nsx-custom-l3vpn-dpd-profile",

    "display_name": "nsx-custom-l3vpn-dpd-profile",

 }

 

The following are the available values for the DPD Profile:

Key

Value Options

dpd_probe_mode

PERIODIC

ON_DEMAND

Once you have successfully created a profile, you can view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields.

If you want to modify a profile that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. However, to modify an existing object, you must use the PATCH method. To delete a profile, send a DELETE request to the same URL as the PUT used to create it with an empty body. Note the DPD profile cannot be deleted while it is referenced by a VPN Session. Delete the VPN session before deleting the DPD profile.

Route-based IPSec VPN

For every Route-based IPSec VPN tunnel, you must define an IKE profile, a tunnel profile, and BGP neighbor. These profiles are then referenced by the IPSec VPN Session, which serves as the overall configuration, as shown in the following chart:

VMC IPSec VPN API.001

Prefix-list definition [Optional]

Prefix-lists are defined at the following path:

/infra/tier-0s/vmc/prefix-lists

 

Although not exposed through the UI, the API allows specifying a prefix-list for filtering both inbound (learned) routes, and outbound (advertised) routes. This allows some control over which networks are sent to the peer, and which ones sent from the peer are injected into the SDDC’s route table. Prefix-lists are mapped to the BGP Neighbor. The purpose of the prefix list is to define one or more IP networks that match.

You can define separate prefix-lists for each session or re-use the same ones. To define a new prefix-list, send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/tier-0s/vmc/prefix-lists/VPNPrefixList_inout).

 

The id and display_name values should be set to the same string as is used in the URL to define the profile. This ID will be referenced in the BGP Neighbor configuration later on. Items in bold should be updated to reflect the desired options.

The request body should contain a JSON object based on the example below, specifying a network in CIDR format, an action (either PERMIT or DENY), and optionally the le and/or ge keys. Multiple objects of this format can be included in the prefixes list.

{

  "prefixes": [

    {

        "network": "10.0.0.0/8",

        "action": "PERMIT",

        "le": 26

     }

  ]

}

 

The le key is optional. If not specified, then only the exact network specified will match. If le is specified, then any subnets within the network, that are smaller than or equal to the value of the le key will also match. For example, specifying le: 26 means that any subnet contained within the specified network that is a /26 or smaller (e.g. /32 - /26) will match. The ge key performs a similar function, except it only matches subnets larger than the specified prefix. For example, specifying ge: 24 would only match networks that are /24 or larger (/24 - /8). Multiple objects of this format can be added to the prefixes list, each with the network, action, and if using the le / ge keys.

Once you have successfully created a prefix-list, you can view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields.

If you want to modify a prefix-list that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. However, to modify an existing object, you must use the PATCH method. To delete a profile, send a DELETE request to the same URL as the PUT used to create it with an empty body. Note the prefix-list cannot be deleted while it is referenced by a BGP neighbor. Delete the BGP neighbor before deleting the prefix-list, or remove the prefix-list from the BGP neighbor.

BGP Neighbor

BGP Neighbors are defined at the following path:

/infra/tier-0s/vmc/locale-

services/default/bgp/neighbors

 

The BGP Neighbor configuration is not linked to the IPSec VPN Session itself. There is a single BGP instance that is shared by all route-based VPNs in an SDDC, so the neighbor is defined on the Tier-0 router. This also means that creating a VPN configuration without defining the BGP neighbor will not generate any errors, and will in fact create a working IPSec tunnel. However, without the neighbor definition, BGP will not be able to establish and exchange routes, and traffic will not flow over the VPN. Note that the VPN session does detect the matching BGP neighbor and will create a dependency on it, which prevents the VPN session from being deleted until the matching BGP neighbor is deleted.

To define a new BGP Neighbor, send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/tier-0s/vmc/locale-services/default/bgp/neighbors/VPNtoDFWDC1BGP).

 

The id and display_name values should be set to the same string as is used in the URL to define the profile. Items in bold should be updated to reflect the desired options.

The request body should contain a JSON object based on the example below, specifying an IP address, remote AS number, route filters and BGP session timers.

 

{

            "neighbor_address": "169.254.151.1",

            "remote_as_num": "65006",

            "route_filtering": [

                {

                    "enabled": true,

                    "address_family": "IPV4",

     "in_route_filters": [ "/infra/tier-0s/vmc/prefix-lists/VPNPrefixList_inout" ],

         "out_route_filters": [ "/infra/tier-0s/vmc/prefix-lists/VPNPrefixList_inout" ]

                }

            ],

            "keep_alive_time": 60,

            "hold_down_time": 180,

            "allow_as_in": false,

            "maximum_hop_limit": 1,

            "resource_type": "BgpNeighborConfig",

            "id": "VPNtoDFWDC1BGP",

            "password": "MyBGPPassword",

            "display_name": " VPNtoDFWDC1BGP"

}

 

The key password can be defined to set a BGP Authentication key or can be omitted to not use one.

Both in_route_filters and out_route_filters are optional and can be omitted.

The neighbor_address should be the remote VPN Endpoint’s tunnel interface, and should be in the same subnet that will be defined in the VPN Session. The remote_as_num is the remote VPN Endpoint’s BGP AS number.

Once you have successfully created a BGP neighbor, you can view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields.

If you want to modify a BGP neighbor that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. However, to modify an existing object, you must use the PATCH method. To delete a BGP neighbor, send a DELETE request to the same URL as the PUT used to create it with an empty body. The BGP neighbor will be deleted even if it is in use by a VPN Session, so exercise caution with the DELETE command.

IPSec VPN Session (route-based)

First, create an IKE profile and Tunnel profile following the steps in the Core VPN section, and a BGP Neighbor with optional prefix-lists from earlier in the route-based IPSec VPN section. Once they are done, you can create the IPSec VPN session.

VPN sessions are defined at the following path:

/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions

 

To define a new VPN session, send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/VPNtoDFWDC1).

 

The id and display_name values should be set to the same string as is used in the URL to define the profile. Items in bold should be updated to reflect the desired options.

The ip_addresses under tunnel_interfaces -> ip_subnets should be replaced with the VTI IP for the SDDC side. This IP should be in the 169.254.0.0/16 network, noting the reserved addresses described on this page. A /30 is recommended, with the other device IP in the network being used for the neighbor address in the BGP neighbor. Change the local_endpoint_path to select either the Public or Private IP as described earlier. Set the psk to the desired key, and update the ike_profile_path and tunnel_profile_path to point to the objects created above. The peer_address is the IP address for the remote VPN endpoint. The peer_id should generally be set to the same IP address, unless the peer is using a different IP for its local IPSec address which is used for authentication.

 

The body should contain the following JSON: 

{

            "tunnel_interfaces": [

                {

                    "ip_subnets": [

                        {

                            "ip_addresses": [

                                "169.254.151.2"

                            ],

                            "prefix_length": 30

                        }

                    ],

                    "resource_type": "IPSecVpnTunnelInterface",

                    "id": "default-tunnel-interface",

                    "display_name": "default-tunnel-interface"

                                  }

            ],

            "force_whitelisting": false,

            "resource_type": "RouteBasedIPSecVpnSession",

            "id": "VPNtoDFWDC1",

            "display_name": " VPNtoDFWDC1",

            "enabled": true,

            "local_endpoint_path": "/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/local-endpoints/Private-IP1",

            "authentication_mode": "PSK",

 "psk":"test123456",

            "ike_profile_path": "/infra/ipsec-vpn-ike-profiles/VPNtoDFWDC1IKE",

            "tunnel_profile_path": "/infra/ipsec-vpn-tunnel-profiles/VPNtoDFWDC1IPSEC",

            "dpd_profile_path": "/infra/ipsec-vpn-dpd-profiles/nsx-default-l3vpn-dpd-profile",

            "compliance_suite": "NONE",

            "connection_initiation_mode": "INITIATOR",

            "peer_address": "10.0.0.1",

            "peer_id": "10.0.0.1"

}

 

Optionally, TCP MSS clamping can be enabled by including the following section within the above object:

"tcp_mss_clamping": {

      "direction": "BOTH",

      "max_segment_size": 1325

}

 

The following are the available values for the TCP MSS Clamping section:

Key

Value Options

direction

BOTH

INBOUND_CONNECTION

OUTBOUND_CONNECTION

 

TCP MSS clamping can be used when devices cannot negotiate MTU properly, by inserting the defined max_segment_size into TCP packets in the direction specified. This can help reduce packet fragmentation in certain cases.

At this point, you should be able to see the VPN configuration in the SDDC’s UI, and the connection should start to establish. You can also view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields. Note that the pre-shared key (psk) field is not included in the response to a GET request. To include that value, you will need to append: ?action=show_sensitive_data to the URL (e.g. /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/VPNtoDFWDC1?action=show_sensitive_data)

If you want to modify a VPN session that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. Also ensure to include the psk key and value. However, to modify an existing object, you must use the PATCH method. To delete a session, send a DELETE request to the same URL as the PUT used to create it with an empty body. Note the VPN Session cannot be deleted while there is a matching BGP neighbor for the tunnel interface address. Delete the matching BGP neighbor before deleting the VPN Session.

Policy-based IPSec VPN

The configuration for policy-based VPN is very similar to that of a route-based VPN. The only difference is that instead of specifying the BGP neighbor configuration, L3 VPN rules are defined to determine what traffic should be sent over the VPN tunnel. These rules are defined in the IPSec VPN Session API call.

VMC IPSec VPN API.002

First, create an IKE profile and Tunnel profile following the steps from the route-based VPN above. Once they are done, you can create the IPSec VPN session.

VPN sessions are defined at the following path:

/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions

 

To define a new VPN session, send a PUT request to the URL above, appending a unique label (it can be any text string, or a generated GUID) to the URL (e.g. /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/VPNtoDFWDC1).

 

The id and display_name values should be set to the same string as is used in the URL to define the profile. Note a separate id and display_name also need to be defined for the rules section. Items in bold should be updated to reflect the desired options. Change the local_endpoint_path to select either the Public or Private IP as described earlier. Set the psk to the desired key, and update the ike_profile_path and tunnel_profile_path to point to the objects created above. The peer_address is the IP address for the remote VPN endpoint. The peer_id should generally be set to the same IP address, unless the peer is using a different IP for its local IPSec address which is used for authentication.

Instead of defining a BGP peer and tunnel configuration as we did for the route-based VPN, for a policy-based VPN we create rules that define the source and destination subnets to map to this VPN tunnel. These subnets are sometimes referred to as “interesting traffic” or the “encryption domain.” The subnets for sources should be taken from the networks defined in network segments in the SDDC, or the Appliance or Infrastructure subnets shown on the Overview page. It is possible to specify any network here, including a summarization of multiple networks in the SDDC. However, it may become difficult to manage the VPN through the UI in this case, as the UI will validate for overlapping subnets. It’s also important that the subnets used here match exactly with the corresponding remote & local subnets used on the remote VPN Endpoint.

{

            "rules": [

                {

                    "sources": [

                        {

                            "subnet": "192.168.98.0/24"

                        },

                        {

                            "subnet": "10.2.1.140/32"

                        }

                    ],

                    "destinations": [

                        {

                            "subnet": "192.168.123.0/24"

                        }

                    ],

                    "logged": false,

                    "enabled": true,

                    "action": "PROTECT",

                    "sequence_number": 0,

                    "resource_type": "IPSecVpnRule",

                    "id": "Test-Policy-l3vpn-rule",

                    "display_name": "Test-Policy-l3vpn-rule"

                }

            ],

            "resource_type": "PolicyBasedIPSecVpnSession",

            "id": "VPNtoDFWDC1",

            "display_name": "VPNtoDFWDC1",

            "enabled": true,

            "local_endpoint_path": "/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/local-endpoints/Private-IP1",

            "authentication_mode": "PSK",

            "psk":"VMware12345",

            "ike_profile_path": "/infra/ipsec-vpn-ike-profiles/VPNtoDFWDC1IKE",

            "tunnel_profile_path": "/infra/ipsec-vpn-tunnel-profiles/VPNtoDFWDC1IPSEC",

            "dpd_profile_path": "/infra/ipsec-vpn-dpd-profiles/nsx-default-l3vpn-dpd-profile",

            "compliance_suite": "NONE",

            "connection_initiation_mode": "INITIATOR",

            "peer_address": "10.0.0.1",

            "peer_id": "10.0.0.1"

}

 

 

 

As with route-based VPN, Optionally, TCP MSS clamping can be enabled by including the following section within the above object: (See Route-based VPN Session for the possible values)

"tcp_mss_clamping": {

      "direction": "BOTH",

      "max_segment_size": 1325

}

At this point, you should be able to see the VPN configuration in the SDDC’s UI, and the connection should start to establish. You can also view it by issuing a GET to the same URL used for the PUT to create it. You will see that the system has inserted several additional fields. Note that the pre-shared key (psk) field is not included in the response to a GET request. To include that value, you will need to append: ?action=show_sensitive_data to the URL (e.g. /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/VPNtoDFWDC1?action=show_sensitive_data).

If you want to modify a VPN session that already exists, you will need to resend the entire JSON object with any updates and omitting the system-added fields to the same URL as was used to create it. Also ensure to include the psk key and value. However, to modify an existing object, you must use the PATCH method. To delete a session, send a DELETE request to the same URL as the PUT used to create it with an empty body.

Troubleshooting

The UI for an SDDC displays several troubleshooting and status information on VPN tunnels, including the IKE (Phase 1) status, BGP Status, advertised & learned routes, and statistics for traffic over the VPN. In some cases, being able to access these details without going through the UI can be desirable, such as for integrating with other systems.

Much of the information in the UI is also available through the API.

VPN tunnel status & aggregate statistics:

To look up the Session ID of the VPN connection, you can query all IPSec VPN Sessions (both route-based and policy-based sessions will be returned) with the following request:

List all VPN Sessions

GET /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions

 

Look for the id key in each returned JSON object in the collection.

Then, use the desired session’s ID to get the details for a specific VPN Session by replacing “<Session_ID>” with the value from the id key in the above GET request:

VPN Tunnel status & statistics

GET /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/<Session_ID>/detailed-status

 

 

Sample output:

{

    "results": [

        {

            "runtime_status": "UP",

            "ike_status": {

                "ike_session_state": "UP",

                "fail_reason": ""

            },

            "total_tunnels": 1,

            "negotiated_tunnels": 1,

            "failed_tunnels": 0,

            "aggregate_traffic_counters": {

                "packets_in": 21,

                "packets_out": 19,

                "bytes_in": 3567,

                "bytes_out": 9540,

                "dropped_packets_in": 0,

                "dropped_packets_out": 0

            },

            "last_update_timestamp": 1611004041752,

            "display_name": "VPNToDFWDC1",

            "enforcement_point_path": "/infra/sites/default/enforcement-points/vmc-enforcementpoint",

            "resource_type": "IPSecVpnSessionStatusNsxT"

        }

    ],

    "intent_path": "/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/61bcf0c0-5502-11eb-83c9-c3ad43d5f9f8"

}

 

 

 

VPN tunnel status & detailed (per-tunnel) statistics:

Use the procedure in the previous section to find the Session ID value, and replace the <Session_ID> placeholder in the URL below with it:

Detailed VPN Tunnel status & statistics

GET /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/<Session_ID>/statistics

 

Returns the following information. Note that for route-based VPNs, there will be a single tunnel with both peer and local subnets of 0.0.0.0/0. Policy-based VPNs will have multiple tunnels – one for each combination of source & destination subnets.

Sample output:

{

    "results": [

        {

            "ike_status": {

                "ike_session_state": "UP",

                "fail_reason": ""

            },

            "policy_statistics": [

                {

                    "tunnel_interface_path": "/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/61bcf0c0-5502-11eb-83c9-c3ad43d5f9f8/interfaces/default-tunnel-interface",

                    "tunnel_statistics": [

                        {

                            "tunnel_status": "UP",

                            "tunnel_down_reason": "",

                            "packets_in": 0,

                            "packets_out": 0,

                            "bytes_in": 0,

                            "bytes_out": 0,

                            "packets_received_other_error": 0,

                            "replay_errors": 0,

                            "integrity_failures": 0,

                            "decryption_failures": 0,

                            "packets_sent_other_error": 0,

                            "seq_number_overflow_error": 0,

                            "encryption_failures": 0,

                            "sa_mismatch_errors_in": 0,

                            "nomatching_policy_errors": 0,

                            "sa_mismatch_errors_out": 0,

                            "peer_subnet": "0.0.0.0/0",

                            "local_subnet": "0.0.0.0/0",

                            "dropped_packets_in": 0,

                            "dropped_packets_out": 0

                        }

                    ],

                    "aggregate_traffic_counters": {

                        "packets_in": 0,

                        "packets_out": 0,

                        "bytes_in": 0,

                        "bytes_out": 0,

                        "dropped_packets_in": 0,

                        "dropped_packets_out": 0

                    }

                }

            ],

            "aggregate_traffic_counters": {

                "packets_in": 0,

                "packets_out": 0,

                "bytes_in": 0,

                "bytes_out": 0,

                "dropped_packets_in": 0,

                "dropped_packets_out": 0

            },

            "last_update_timestamp": 1611003925231,

            "display_name": " VPNToDFWDC1",

            "enforcement_point_path": "/infra/sites/default/enforcement-points/vmc-enforcementpoint",

            "resource_type": "IPSecVpnSessionStatisticsNsxT"

        }

    ],

    "intent_path": "/infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/61bcf0c0-5502-11eb-83c9-c3ad43d5f9f8"

}

 

 

Reset statistics counters

Reset all counters for the above API call to 0.

POST /infra/tier-0s/vmc/locale-services/default/ipsec-vpn-services/default/sessions/<Session_ID>/statistics?action=reset

 

 

 

BGP Status for Route-based VPNs

Get all BGP sessions status and details:

GET /infra/tier-0s/vmc/locale-services/default/bgp/neighbors/status

 

Returns the following data set for each BGP neighbor:

{

            "source_address": "169.254.150.2",

            "local_port": 0,

            "neighbor_address": "169.254.150.1",

            "remote_port": 0,

            "remote_as_number": "65000",

            "connection_state": "IDLE",

            "messages_received": 0,

            "messages_sent": 0,

            "time_since_established": 0,

            "total_in_prefix_count": 0,

            "total_out_prefix_count": 0,

            "address_families": [

                {

                    "type": "IPV4_UNICAST",

                    "in_prefix_count": 0,

                    "out_prefix_count": 0

                }

            ],

            "connection_drop_count": 0,

            "established_connection_count": 0,

            "hold_time": 180,

            "keep_alive_interval": 60,

            "graceful_restart_mode": "HELPER_ONLY",

            "announced_capabilities": [],

            "negotiated_capability": [],

            "neighbor_router_id": "0.0.0.0",

            "tier0_path": "/infra/tier-0s/vmc",

            "last_update_timestamp": 1611005095965

 }

 

Routes learned and advertised on a Route-based VPN

To look up the BGP neighbor ID, you can query all BGP neighbors with the following request:

List all BGP Neighbors

GET /infra/tier-0s/vmc/locale-services/default/bgp/neighbors

 

Look for the id key in each returned JSON object in the collection.

Then, use the neighbor ID to get the routes for a specific neighbor by replacing “<Neighbor_ID>” with the value from the id key in the above GET request:

Routes learned from a specific BGP neighbor

GET /infra/tier-0s/vmc/locale-services/default/bgp/neighbors/<Neighbor_ID>/routes

Routes advertised to a specific BGP neighbor

GET /infra/tier-0s/vmc/locale-services/default/bgp/neighbors/<Neighbor_ID>/advertised-routes

Optionally append ?format=csv to the above URLs and change the method to POST to change the format of the returned data from JSON to CSV.

 

Filter Tags

Automation Networking SDDC VMware Cloud VMware Cloud on AWS Document Technical Guide Technical Walkthrough Advanced Deploy Manage