Skip to main content
Versa Networks

Troubleshoot the SASE Gateway

Versa-logo-release-icon.pngFor supported software information, click here.

This article describes some of the issues that you may face with the SASE gateway and the steps to troubleshoot them.

Troubleshoot Registration Issues

SASE gateway registration may fail due to various issues with the local user, LDAP, SAML, and two-factor or multi-factor authentication. This section describes some of these scenarios and the verification methods to fix the issues.

Verify the FQDN for the Portal

To verify that the FQDN for the portal resolves to the correct SASE WAN IP address:

  1. Issue the nslookup CLI command, or ping the registration FQDN from your device.
  2. Ensure that the FQDN resolves to the WAN IP address of the SASE portal. For example:
     
    C:\Users\user1\nslookup sj-sandbox.versa-test.net
    Server: dns-hq-versa-networks.com
    Address: 10.10.11.11
    
     
  3. If the FQDN does not resolve the SASE portal WAN IP address, add the valid DNS record in the DNS servers to resolve the FQDN that you use for registration.

Verify HTTP and HTTPS Packets

To verify that HTTP and HTTPS packets sent to the SASE portal are allowed:

  • Check to make sure that your computer allows HTTP and HTTPS packets to the SASE portal. Also, make sure that the firewall on your computer is not blocking HTTPS and HTTPS packets in both directions to the SASE portal. To troubleshoot firewall issues, refer to the operating system documentation for your device.
  • Run the tcpdump on the WAN interface of the SASE portal and check if packets sent by the SASE client are reaching the SASE portal. To run tcpdump:
    1. In Director view:
      1. Select the Administration tab in the top menu bar.
      2. Select Appliances in the left menu bar.
      3. Select an appliance in the main panel. The view changes to Appliance view.
    2. Select the Monitor tab in the top menu bar.
    3. Select an organization in the submenu bar. 
    4. Click Run TCP Dump, and then enter information for the following fields.
      • Interface—Select the required WAN interface.
      • Filter—Enter "host <IP-address>" using the public IP address that your device uses to reach the internet, for example, "host 8.8.8.8".
        To find the public IP address that your device uses, you can use a website such as ipchickent.com from your browser.
      • For information on configuring other parameters, see Use Network Monitoring Tools.

        run-tcp-dump.png
    5. Click Start to display the results in Latest Results.
  • Enable secure access and NGFW on the device owner organization (provider org).
    1. In Director view:
      1. Select the Administration tab in the top menu bar.
      2. Select Appliances in the left menu bar.
      3. Select a device name in the main panel. The view changes to Appliance view.
      4. Select an organization.
    2. Select the Configuration tab in the top menu bar.
    3. Select Others > Organization > Limits in the left menu bar. 
    4. Select the provider organization name in the main pane. The Edit Organization Limit window displays. For more information, see Configure Organization Limits.

      edit-organization-limit-services-tab.png
    5. Select the Services tab.
    6. In the Services section, click the + Add icon, and then select the nextgen-firewall and secure-access services.
    7. Click OK.    
  • Configure a security access rule to allow access to the portal using the required match conditions. For more information, see Configure Next-Gen Firewall.

Verify Captive Portal Configuration

You must configure captive portal on the device owner (Provider) organization.

  • Validate the captive portal configuration—There are two types of captive portal configurations: server certificate-based and CA certificate-based.
    • To validate a captive portal based on server certificate, issue the show orgs org-services <provider-organization-name> security captive-portal CLI command. For example: 
      admin@Branch-1-cli(config)% show orgs org-services <corp-provider> security captive-portal
      expiration-time 30;
      service-endpoints {
          Internet-1-Transport-VR {
              http-port 80;
              https-port 443;
              ip-addresses [ 10.11.11.12 ];
              server-url .*.versa-networks.com;
              server-certificate zone1-vpn.versa-networks.crt;
      }

      Note that if the SASE portal WAN is behind NAT, you must configure the internal IP address (current assigned WAN IP address on WAN interface) of WAN in the IP address.

    • To validate a captive portal based on a CA certificate, issue the show orgs org-services <ca-certificate-issuer-name> security captive-portal CLI command. For example:

      admin@SASE-Portal-cli(config)% show orgs org-services <Versa> security captive-portal
      ssl-ca-certificate Versa-Networks-CA.crt;
      service-endpoints {
          Internet-1-Transport-VR {
              http-port 80;
              https-port 443;
      }
      
  • If the captive portal configuration is server certificate-based, make sure the IP address matches the WAN on the portal.
  • For a server certificate-based configuration, also make sure the server URL matches the subject CN and subjective alternative names.

Verify Captive Portal Certificate

Verify that the certificate loaded for captive portal is valid and loads correctly. 

  • To verify the certificate loads correctly, issue the following CLI command:
    •  show orgs org-services <device-owner-organization> crypto pki certificates <certificate-used-in-captive-portal> 
  • Verify that the certificate has not expired.
  • Verify the subject CN and issuer. 
  • To verify the private key loads correctly, issue the following CLI command:
    • show orgs org-services <device-owner-organization> crypto pki private-keys <private-key-used-for-certificate> 
  • To view the certificate that a captive portal uses:
    1. Go to Versa Session Management Daemon (VSMD) VTY from the VOS shell by issuing vsh connect vsmd command.
    2. Run the show ssl decryption-profiles brief command. The captive portal certificate should display as shown in the following example:
      vsn-vcsn0> show ssl decryption-profiles brief
      ==============================================
      Number of OCSP cache entry:                  0
      ==============================================
      Number of ADDR to HOST mapping cached
      ----------------------------------------------
      Tenant-ID     Count
      1             0
      2             0
      ==============================================
      
      Decryption Profiles
      ----------------------------------------------
      Tenant-ID Profile-Name             Profile-ID  Profile-Type      Certificate  Private-key
      1         cportal_decrypt_profile  9111        versa-full-proxy  Yes          Yes
    3. If the certificate is loaded after captive portal configuration, you can delete and then add the captive portal configuration.

Verify SSL Handshake Completion

You can verify that the SSL handshake is completed by accessing the HTTPS link of the SASE portal. 

To verify the SSL handshake is completed:

  1. Open a browser on the device on which the SASE client is installed.
  2. Paste the following URL:
    • https://<FQDN of SASE portal>/secure-access/services/gateway?action=discover&ent_name=<enterprise-name>
  3. To resolve the certificate, click the Lock icon next to the URL  and check if the certificate is valid. For example:

    verify-url-certificate.png
  4. If URL in point above does not work, run Wireshark on your device and check if the SSL handshake is successful. If not, go through the steps mentioned in Verify FQDN for Portal, Verify HTTP and HTTPS Packets, Verify Captive Portal Configuration, and Verify Captive Portal Certificate above.
  5. If this does not resolve the SSL handshake, enable SSL debug logs and check for errors in logs. To generate a log file, issue the following CLI command:
    admin@Branch-1-cli(config)% set debug ssl all-flags level all send to file name /tmp/ssl.log

Verify Secure Access Portal Authentication Profiles

You can verify that the correct authentication profiles are associated with secure access portal registration. 

To verify secure access portal authentication profiles:

  1. In Director view:
    1. Select the Configuration tab in the top menu bar.
    2. Select Templates > Device Templates in the horizontal menu bar.
    3. Select an organization in the left menu bar.
    4. Select a template in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Services > Secure Access > Gateway > General in the left menu bar. The following screen displays.

    secure-access-gateway-general.png
  4. Click the edit-icon.png Edit icon. The Add Services window displays.

    secure-access-gateway-add-services-auth-profile.png
  5. Check the Authentication field to verify that the correct authentication profile is selected. For more information, see Configure the Versa Secure Access Service.

Check the authentication profile configuration and user identification based on the authentication mechanism used. The following example is for SAML authentication. For other authentication configurations, see VOS Security Configuration.

  1. In Director view:
    1. Select the Administration tab in the top menu bar.
    2. Select Appliances in the left menu bar.
    3. Select a device name in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Object and Connectors > Connectors > Users/Groups > SAML Profile in the left menu bar.

    saml-profile-menu.png
  4. Click the + Add icon to add a new SAML profile, or select an existing profile. The Add/Edit SAML Profile popup window displays. For more information, see Configure SAML Profiles.

    add-saml-profile.png

To check the secure access session history: 

  1. Go to VSMD VTY from the VOS shell by issuing the vsh connect vsmd command.
  2. Run the show saccess session history <portal/gatewayall command.
  3. Look for services such as portal and action. Copy the ID and run the show saccess session history <portal/gateway> id ID command to display more information.

Verify Local User Authentication

To verify that local users are configured correctly, see Configure a Local Database.

Verify LDAP Authentication

  • To verify that the LDAP server is reachable from the SASE portal, run the ping CLI command for the routing instance where LDAP is configured:
    admin@ DC-Branch-1-cli(config)% show orgs org-services Corp-Inline-Customer-1 user-identification ldap-profiles
    Azure-AD {
        state                enabled;
        domain-name          versa-networks.com;
        ldap-base            "********";
        bind-dn              "********";
        bind-password        "********";
        server-type          active-directory;
        use-ssl              enabled;
        ssl-mode             ldaps;
        ca-cert              default;
        search-timeout       30;
        bind-timeout         30;
        servers {
            Azure-AD-Server {
                ip-address      40.40.42.36;
                port            636;
                routing-instances Internet-1-Transport-VR;
                fqdn            ldaps.versa-networks.com;
            }
        }
    }
    [ok][2025-09-13 19:12:23]
    [edit]
    admin@ DC-Branch-1-cli(config)% run ping ldaps.versa-networks.com routing-instance Internet-1-Transport-VR
    ldaps.versa-networks.com (40.32.42.46)
    PING 40.32.42.46 (40.32.42.46) 56(84) bytes of data.
    ^C
    --- 40.78.82.36 ping statistics ---
    3 packets transmitted, 0 received, 100% packet loss, time 2016ms

Ping may be blocked by the LDAP server but you must resolve the FQDN and requests must go through the routing instance based on which LDAP is configured.

  • To verify if the SASE portal is connected to the LDAP server, run the show orgs org-services organization-name user-identification ldap-server-data users brief CLI command:
    • This CLI must return domain users configured in LDAP. If it does not, you must troubleshoot the connectivity and authentication between the SASE portal and LDAP server. <Review Note: how is this trouble shooting done?>
    • Verify that the LDAP server allows the source IP address of the SASE portal to reach LDAP.
    • To check the connectivity to the LDAP server, run the ldapsearch command on Linux. For example: 
      • ldapsearch -H ldaps://LDAP-server-IP-Adresss> -D Domain -w password -b dc=xx,dc=yy,dc=zz,dc=zz -Z
  • Validate the LDAP server configuration. For more information, see Configure a Gateway To Use an LDAP Server for User Authentication.

SAML Authentication Issues

To troubleshoot SAML authentication:

  • Ensure that Network Time Protocol (NTP) is enabled on the SASE gateway and that the SASE client device time is synchronized. For more information, see Configure Time Settings.
  • If you are not prompted for user name and password, check logs and the SAML URI in SASE client logs. To export SASE client logs, see Perform Diagnostics and Export Logs.
  • Search the URL configured in the SAML profile on the portal in SASE client logs. You can view the SAML profile URL configuration from the Edit SAML Profile window. For more information, see Configure a SAML Profile.

    For example:

    edit-saml-profile.png
  • Copy the URL, paste it in your browser, and check if the login prompt displays. If the SAML URL does not work from your device, check the firewall rules of the device.
  • Check the connectivity to the SAML server from your device.
  • To check if SAML is configured correctly on the SASE portal, see Configure a SAML Profile.

Two-Factor or Multi-Factor Authentication Issues

If two-factor or multi-factor authentication (MFA) is enabled through external authentication, such as LDAP or Active Directory (AD), make sure that the email and phone number for your account are correctly configured on the external authentication servers.

On Microsoft AD server, you can find these details on the Attribute Editor tab. For example:

microsoft-ad-attribute-editor-tab.png

Troubleshoot Connection Issues

This section covers how to troubleshoot connection issues with the SASE gateway. 

Verify Authentication Profile

To verify that the correct authentication profile is associated with your SASE gateway:

  1. In Director view:
    1. Select the Configuration tab in the top menu bar.
    2. Select Templates > Device Templates in the horizontal menu bar.
    3. Select an organization in the left menu bar.
    4. Select a template in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Services > Secure Access > Gateway > General in the left menu bar. The following screen displays.

    secure-access-gateway-general.png
  4. Click the edit-icon.png Edit icon. The Add Services window displays.

    secure-access-gateway-add-services-auth-profile.png
  5. Check the Authentication field to make sure the correct authentication profile is selected. For more information, see Configure the Versa Secure Access Service.

Verify the Tunnel Password Profile is Associated with Gateway

If local authentication is enabled for secure access gateway, you should have an authenticator profile for one-time password (OTP) verification associated with the gateway.

To configure an authenticator profile:

  1. In Director view:
    1. Select the Administration tab in the top menu bar.
    2. Select Appliances in the left menu bar.
    3. Select a device name in the main panel. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Objects & Connectors > Connectors > Users/Groups > Authenticator Profiles in the left menu bar.

    users-groups-authenticator-profiles-home.png
  4. Click the + Add icon. The Add Authenticator Profiles window displays. 

    add-authenticator-profiles-otp.png
  5. Enter a name for the authenticator profile (here, OTP-profile).
  6. In the Authenticator Type field, select REST-based Authenticator Service to configure an OTP in the One-Time Password group of fields.
  7. Click Mobile to send an OTP to a mobile device.
  8. Click Email Address to send the OTP using email and to share a QR code to use to register the SASE client to the user's email address.
  9. For information about configuring other parameters, see Configure an Authenticator Profile
  10. Click OK.

To associate the authenticator profile with your secure access gateway profile:

  1. In Director view:
    1. Select the Configuration tab in the top menu bar.
    2. Select Templates > Device Templates in the horizontal menu bar.
    3. Select an organization in the left menu bar.
    4. Select a template in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Services > Secure Access > Gateway > General in the left menu bar.

    gateway-general-menu.png
  4. Click the edit-icon.png Edit icon. The Add Services window displays.

    secure-access-gateway-add-services-authenticator-profile-otp.png
  5.  In the Authenticator Profile field, select the authenticator profile you configured (here, OTP-profile).
  6. For information about configuring other parameters, see Configure a Secure Access Gateway.
  7. Click OK.

Verify IPsec Profile Certificate

You can verify that the certificate is loaded for the IPsec profile configured for SASE clients. 

To verify the certificate is loaded:

  1. Go to VSMD VTY using the shell command vsh connect vsmd.
  2. To find the tenant ID where the IPsec profile is configured, run the show vsf tenant all brief command. For example:
    vsm-vcsn0> show vsf tenant all brief
    Tenant Name             Tenant ID
    ----------------------------------
    Corp-Inline-Customer-1   1
    Corp-Inline-Provider     2
  3. Run the show ipsec config <tenant-id> all command. The output must display certificate code done, as shown in the example below. Note that the output is truncated.
     
    vsm-vcsn0> show ipsec config 1 all
    ####### Tenant 1 (Corp-Inline-Customer-1) config #########
    Config Ref-Count: 10
    Intf link Ref-Count: 10
    Intf Addr Ref-Count: 10
    -----------------------------------
    VPN Name - split-tunnel-RAS, OBJ ID 10, VPN ID 10
    VPN Type - RAS
    DHKey: Profile = []
    Steering - CLIENT-IP-BASED
    VRF ID - Internet-1-Transport-VR(14)
    Tunnel VRF ID - Corp-Inline-Customer-1-LAN-VR(9)
    Tunnel Tenant Id - 1
    VSN ID - 0
    Loaded - Yes (0x0x7f09617b2e08)
    Crypto offload - Enabled (i.e. use if any hw-accel available)
    Revocation Check - None
    Local interface : vni-0/0.0
    ------- Local Identity ---------
    Auth Type - Certificate
    Certificate-Authority - intermediate-1.crt
    Certificate - present
    Private key - present Certificate-status - Certificate decode done
    ID Type - FQDN
    ID - vpn.versa-networks.com
    Auth Domain : split-tun-authdom-1
  4. To check that the end entity certificate is issued by the CA chain, run the show orgs org-services <organization-name> crypto pki certificates <end-entity-certificate-name> CLI command. In the example below, the highlighted text shows that certificate is issued by CA chain. 
    admin@HE-DC-Branch-1-cli> show orgs org-services Corp-Inline-Customer-1 crypto pki certificates vpn.versa-networks.crt
    Certificate:
      Data:
        Version      = x509v3
        Serial num   = 1003
        Name         = vpn.<certificate-name>.crt
        SHA1 hash    = *****************
        Priv-Key     = <private-key>.key
        Signature Algorithm = sha256WithRSAEncryption
        Subject:
          Subject CN  = <domain-name>
          Org Unit    =
          Org Name    = Versa Networks Inc.
          Locality    = Fremont
          State       = CA
          Country     = US
        Validity:
          Not Before  = <start-date and time>
          Not After   = <expiry-date and time>
        Issuer:
          Issuer CN   = Versa Intermediate Certificate Authority 1     
          Org Unit    = Secure access,
          Org Name    = Versa Networks Inc.
          Locality    = San Jose
          State       = CA
          Country     = US
  5. To verify that the CA chain is valid, run the show orgs org-services <organization name> crypto pki certificates CA <chain certificate> CLI command.

Verify IPsec Services

To verify if IKE and IPsec services are running on your device:

  • For Windows, refer to Microsoft documentation about IKE and AuthIP errors.
  • For Linux, refer to strongSwan documentation. 

Verify IKE Negotiation

  • Enable IKE and IPsec logs by issuing the following configuration commands:
    • admin@Branch-1-cli(config)% set debug ike level debug-verbose
    • admin@Branch-1-cli(config)% set debug ipsec all-flags level all
  • Open the log file /var/log/versa/versa-ipsec-ctrl.log and search for 'Received' and 'Sending'. A successful handshake between the SASE client and SASE gateway looks similar to the following packet flow example:
    • If the SASE gateway does not receive the SA init packet, check the firewall between the SASE client device and SASE gateway.
    • If the SASE gateway receives the SA init packet, but the SASE client device does not receive the response, check the firewall between the SASE gateway and the device.
    • If there are certificate issues, it fails after the SASE gateway sends CERTREQ.
    • Check for errors in the /var/log/versa/versa-ipsec-ctrl.log file.
  • Received : [HDR, SA, KE, Nonce, N(REDIRECT_SUPPORTED), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP), N(FRAGMENTATION_SUPPORTED)]
    Sending  : [HDR, SA, KE, Nonce, N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP), N(HTTP_CERT_LOOKUP_SUPPORTED),
                 N(FRAGMENTATION_SUPPORTED), CERTREQ, Vid, Vid]
    Received : [HDR, IDi, N(INITIAL_CONTACT), N(MOBIKE_SUPPORTED), IDr, CP, N(ESP_TFC_PADDING_NOT_SUPPORTED), N(NON_FIRST_FRAGMENTS_ALSO), SA, TSi, TSr]
    Sending  : [HDR, IDr, CERT, AUTH, EAP, Vid, Vid]
    Received : [HDR, EAP]
    Sending  : [HDR, EAP, Vid, Vid]
    Received : [HDR, EAP]
    Sending  : [HDR, EAP, Vid, Vid]
    Received : [HDR, EAP]
    Sending  : [HDR, EAP, Vid, Vid]
    Received : [HDR, AUTH]
    Sending  : [HDR, AUTH, CP, SA, TSi, TSr, N(ESP_TFC_PADDING_NOT_SUPPORTED), N(NON_FIRST_FRAGMENTS_ALSO), Vid, Vid]

Verify ESP Packets 

To verify if ESP packets from the SASE client reach the SASE gateway:

  • Run tcpdump on the SASE gateway WAN interface by filtering the public IP address of the SASE client, and check if the SASE gateway receives ESP packets. To find the public IP address of your computer, open a web browser and type https://ipchicken.com/.

Verify IKE and ESP Packets are Unmodified

If ISPs modify IKE and ESP packets between the SASE client and SASE gateway, the SASE client and SASE gateway drop these packets. Check the SASE client device and SASE gateway packets to verify that the actual packets are not modified. 

Best Gateway Selection Issues

This section describes issues in selecting the best SASE gateway and how to avoid them.

Enable Versa Private TLV Infomation 

To avoid issues in selecting the best SASE gateway, ensure that you enable Versa private TLV information in the multiprotocol BGP (MP-BGP) instance.

To enable Versa private TLV information:

  1. In Director view:
    1. Select the Administration tab in the top menu bar.
    2. Select Appliances in the left menu bar.
    3. Select an appliance in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Networking > Virtual Routers in the left menu bar.
  4. Click the + Add icon. The Configure Virtual Router window displays.
  5. Select the BGP tab in the left menu bar. The main pane displays a list of the BGP instances that are configured.
  6. Click the + Add icon. The Add BGP Instance window displays.
  7. Select the Versa Private TLV tab. For more information, see Enable BGP Versa Private TLVs.

    edit-bgp-instance-versa-private-tlv-tab.png
  8. Click Announce Local to enable gateways or hub-controller nodes (HCN) to support selection of the best gateway.
  9. Click Announce Remote only if the gateways and hub-controller nodes are not in a full-mesh topology. 
  10. Click OK. For more information about selecting the best gateway, see Configure the Versa SASE Client To Select the Best Gateway.

Verify Optimal Gateway Status

To verify the optimal gateway status, check if the optimal-gateway status is true for the required secure access session. 

  1. To display the secure access sessions, run the show saccess session history all | grep <user-name> CLI command. For example:
    vsm-vcsn0> show saccess session history all | grep user-name
    879   1   112.100.10.10   gateway   discover     200   user@abc.com
    880   1   112.100.10.11   gateway   autoprelogin 200   user@abc.com
    881   1   112.200.10.12   gateway   discover     200   user@abc.com
  2. To check the if the optimal gateway status in a session is true, issue the show saccess history id <session-id> | grep optimal-gateway command. In the example below, the session id is 880 and optimal-gateway displays 'true'. Note that the output has been truncated.
    vsm-vcsn0> show saccess session history id 880 | grep optimal-gateway
    <versa-secure-access mandatory="true" version="1.0">
      <prelogin mandatory="true">
        <code>200</code>
        <message>success</message>
      </prelogin>
      <gateway mandatory="true">
        <actions mandatory="true">
          <prelogin>prelogin</prelogin>
          <login>login</login>
          <otp-gen>otp_gen</otp-gen>
          <otp-verify>otp_verify</otp-verify>
          <metrics>metrics</metrics>
          <discover-gateway>discover_gateway</discover-gateway>
        </actions>
      </gateway>
      <optimal-gateway>true</optimal-gateway>
  • If optimal-gateway is 'false', check that the Versa private TLV is enabled as explained in the first point above. Run the following VSMD VTY commands to confirm all SASE gateway information is learnt and shared between them. To connect to VSMD VTY, run the Linux shell command vsh connect vsmd:
    • show vsm sdwan site-information all 0. For example:
      vsm-vcsn0> show vsm sdwan site-information all 0
      +-----------+-----------------------------------+-------------------+-------------------------+------------+--------+----------------------------+--------+--------+----+
      | Tenant ID | Site Name                         | WAN-IP(s)       | Tenant-Name-List      | Site Type  | Flags  | Co-ordinates        | CPU(%) | MEM(%) | REGION  |
      +-----------+-----------------------------------+-------------------+-------------------------+------------+--------+----------------------------+--------+--------+-----+
      | 1         | Site 1                            | [IP-1]          | [tenant-name]         | Branch     | -      | [location]          | 3      | 16     |         |
      | 1         | Site 2                            | [IP-2]          | [masked-name]         | Branch     | -      | [location]          | 3      | 14     |         |
      | 1         | Site 3                            | [IP-3]          | [masked-name]         | Branch     | -      | [location]          | 2      | 42     |         |
      | 1         | Site 4                            | [IP-4]          | [masked-name]         | Branch     | -      | [location]          | 2      | 32     |         |
      | 1         | Site 5                            | [IP-5]          | [masked-name]         | Branch     | -      | [location]          | 5      | 21     |         |
      | 1         | Site 6                            | [IP-6]          | [masked-name]         | Branch     | -      | [location]          | 2      | 32     |         |
      | 1         | Site 7                            | [IP-7]          | [masked-name]         | Branch     | -      | [location]          | 4      | 25     |         |
      +-----------+-----------------------------------+-------------------+-------------------------+------------+--------+----------------------------+--------+--------+-----+
    • show vsm sdwan domain-information all 0. For example:
      vsm-vcsn0> show vsm sdwan domain-information all 0
      +---------------------------+-----------+-----------------------------------+-------+
      | Domain Name        | Tenant ID | Site Name                  | Tenant Name   |
      +---------------------------+-----------+-----------------------------------+-------+
      | [domain-1]         | 1         | [site-1]                   | [tenant]      |
      | [domain-1]         | 1         | [site-2]                   | [tenant]      |
      | [domain-1]         | 1         | [site-3]                   | [tenant]      |
      | [domain-1]         | 1         | [site-4]                   | [tenant]      |
      | [domain-2]         | 1         | [site-1]                   | [tenant]      |
      | [domain-2]         | 1         | [site-2]                   | [tenant]      |
      | [domain-3]         | 1         | [site-1]                   | [tenant]      |
      | [domain-4]         | 1         | [site-2]                   | [tenant]      |
      | [domain-5]         | 1         | [site-3]                   | [tenant]      |
      | [domain-6]         | 1         | [site-4]                   | [tenant]      |
      | [domain-7]         | 1         | [site-5]                   | [tenant]      |
      | [domain-8]         | 1         | [site-6]                   | [tenant]      |
      | [domain-9]         | 1         | [site-7]                   | [tenant]      |
      | [domain-10]        | 1         | [site-8]                   | [tenant]      |
      | [domain-11]        | 1         | [site-9]                   | [tenant]      |
      +---------------------------+-----------+-----------------------------------+-------+

IKE or IPsec Flaps

Versa Networks recommends the following configurations for IKE and IPsec in secure access and IPsec VPN profiles due to rekey issues on Windows or MacOS:

admin@HE-DC-Branch-1-cli(config)% show orgs org-services Corp-Inline-Customer-1 ipsec vpn-profile split-tunnel-RAS
vpn-type     remote-access-server;
local-auth-info {
    auth-type certificate;
    cert-name vpn.versa-networks.crt;
    ca-chain intermediate-1.crt;
}
local {
    interface-name vni-0/0.0;
}
routing-instance     Internet-1-Transport-VR;
tunnel-routing-instance Corp-Inline-Customer-1-LAN-VR;
ipsec {
    force-nat-t disable;
    mode tunnel;
    encryption-algorithms [ 3des aes128 aes128-ctr aes128-gcm aes256 aes256-gcm ];
    hash-algorithms       [ md5 xcbc sha1 sha256 sha384 sha512 ];
    pfs-groups            [ mod-none mod1 mod2 mod5 mod14 mod15 mod16 mod19 mod20 mod21 mod25 mod26 ];
    anti-replay enable;
    life {
        duration 12600;
    }
}
ike {
    version v2;
    groups                [ mod1 mod2 mod5 mod14 mod15 mod16 mod19 mod20 mod21 mod25 mod26 ];
    encryption-algorithms [ 3des aes128 aes256 ];
    hash-algorithms       [ md5 sha1 sha256 sha384 sha512 ];
    lifetime 21600;
    auth-domain     split-tun-authdom;
}
address-pools {
    address-range 172.30.57.1-172.57.1.254;
    netmask 255.255.255.0;
    accessible-subnets 10.0.0.0/8;
    dns internal {
        nameserver [ 10.48.0.99 ];
        domain [ versa-networks.com ];
}
}
remote-auth-type     eap;
ras-id               split-tunnel;
remote-auth-eap-type mschap-v2;
[ok][2021-07-02 14:49:21]
[edit]
admin@HE-DC-Branch-1-cli(config)%
admin@HE-DC-Branch-1-cli(config)% show orgs org-services Corp-Inline-Customer-1 secure-access servers
Fremont {
    priority 100;
    ipsec-profile-id split-tunnel;
    host {
        fqdn vpn.versa-networks.com;
    }
    tunnel-authentication {
        x509-cert intermediate-1.crt;

    }
    traffic-steering {
        split-tunnel enabled;
        routes [ private_ip ];
    }
    captive-portal {
        url https://vpn.versa-networks.com/secure-access/services/gateway;
        https enabled;
        certificate {
        ca-cert intermediate-1.crt;
    }
    version 0.0.1;
    }
    ike {
        dpd-timeout 30;
        pfs-group mod2;
        lifetime 28800;
        ike-transform 3des-sha1;
        ike-version v2;
    }
    ipsec {
        pfs-group mod2;
        lifetime 3600;
        ipsec-transform esp-3des-sha1;
    }
    client-auth-type eap;
    client-auth-eap-type mschap-v2;
    dns-resolvers [ versa-networks.com ];
    app-delete disabled;
 }
[ok][2021-07-02 14:49:53]
[edit]
admin@HE-DC-Branch-1-cli(config)% show orgs org-services Corp-Inline-Customer-1 secure-access profiles
default-servers {
    traffic-steering {
    split-tunnel enabled;
    routes [ private_ip ];
    }
    ike {
        dpd-timeout 30;
        pfs-group mod2;
        lifetime 28800;
        ike-transform 3des-sha1;
        ike-version v2;
    }
    ipsec {
        pfs-group mod2;
        lifetime 3600;
        ipsec-transform esp-3des-sha1;
    }
    dns-resolvers [ versa-networks.com ];
    servers [ Fremont ];
    client-controls {
        add-custom-gateway  enabled;
        edit-gateway        enabled;
        multi-tenancy       enabled;
        remember-credential enabled;
        change-password-url https://https://10.40.46.248:9182/vnms/secure/access/localuser;
        portal-lifetime 1440;
        }
}

Troubleshoot SASE Gateway Traffic Issues

This section describes how to troubleshoot scenarios in which traffic does not work through the SASE gateway.

Verify the Gateway FQDN

To verify that your organization's SASE gateway FQDN resolves without any conflicts:

  1. In Director view:
    1. Select the Administration tab in the top menu bar.
    2. Select Appliances in the left menu bar.
    3. Select a device name in the main panel. The view changes to Appliance view.
    4. Select an organization.
  2. Select the Configuration tab in the top menu bar.
  3. Select Others > Organization > Limits in the left menu bar. The main pane displays the associated organizations.
  4. Click an organization name in the main pane. The Edit Organization Limit window displays.

    edit-organization-limit-general-tab.png
  5. In the General tab, check the Gateway FQDN field for the SASE gateway FQDN, and add or update as required.
  6. For information about configuring other parameters, see Configure Organization Limits.
  7. Click OK.

To check if the FQDN resolves to the IP address, run the nslookup CLI command. For example:

C:\Users\user-name> nslookup
Default Server:  dns-hq.versa-networks.com
Address:  10.10.11.111

> server 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8

> vpn.versa-networks.com
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    vpn.versa-networks.com
Address: 200.20.60.81

Check Firewall Rules on the SASE Gateway

To check firewall rules on the SASE gateway to allow traffic coming through the Versa Secure Access (VSA) tunnel, configure firewall rules on the SASE gateway to allow traffic from SASE client. Use the predefined ‘remote-client’ zone to match all traffic coming over the VSA tunnel.

To configure firewall rules on the SASE gateway:

  1. In Director view:
    1. Select the Administration tab in the top menu bar.
    2. Select Appliance in the left menu bar.
    3. Select the device in the main pane. The view changes to Appliance view.
  2. Select the Configuration tab in the top menu bar.
  3. Select Services > Next Gen Firewall > Security > Policies in the left menu bar, and then select the Rules tab.
  4. Click the add-icon-black-on-white-22.png Add icon to define rules for the policy. The Add Rule window displays.

    ngfw-source-tab.png
  5. Select the Source tab.
  6. In the Source Zone field, click the add-icon-black-on-white-22.png icon, and then select the predefined zone 'remote-client'.
  7. Select the Enforce tab, and then select any security profile based on your requirement. For more information, see Configure Access Policy Rules (ACL Rules).
  8. Click OK.

Verify Traffic Sent to the Customer Site

To verify traffic sent to the customer site:

  • If the customer site is directly connected over LAN on SASE gateway, issue tcpdump to verify that traffic is leaving the LAN, and filter the source by the tunnel IP address of the SASE client.
  • If the customer site is connected over SD-WAN, verify that traffic is going over the SD-WAN tunnel to remote SD-WAN devices.
  • If the customer site is connected over a site-to-site IPsec tunnel, verify that traffic is sent out of the IPsec tunnel to the customer site router. For more information, see Configure Site-to-Site Tunnels

Verify the Reverse Route from the Customer Site 

You can NAT all traffic from the SASE client to the pool IP address, or route it without any NAT. Verify that there is a reverse route in the customer site router for traffic sourced and sent to the customer site. 

Supported Software Information 

Releases 21.2.1 and later support all content described in this article.

  • Was this article helpful?