| Home Prev |  cOS Stream 4.00.03 Administration Guide
|
Next |
|---|
This section deals with how to troubleshoot the common problems that are found with VPN.
In all types of VPNs some basic troubleshooting checks can be made:
Check that all IP addresses have been specified correctly.
Check that all pre-shared keys and usernames/passwords are correctly entered.
Use ICMP Ping to confirm that the tunnel is working. With roaming clients this is best done by "Pinging" the internal IP address of the local network interface on the Clavister NetShield Firewall from a client (in LAN to LAN setups pinging could be done in any direction). If cOS Stream is to respond to a Ping then the following rule must exist in the main IP rule set:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|
| Allow | vpn_tunnel | all-nets-ip4 | core | all-nets-ip4 | ICMP |
Ensure that another IPsec Tunnel definition is not preventing the correct definition being reached. The tunnel list is scanned from top to bottom by cOS Stream and a tunnel in a higher position with the Remote Network set to all-nets-ip4 and the Remote Endpoint set to none could prevent the correct tunnel being reached. A symptom of this is often an Incorrect Pre-shared Key message.
Try and avoid duplication of IP addresses between the remote network being accessed by a client and the internal network to which a roaming client belongs.
If a roaming client becomes temporarily part of a network such as a Wi-Fi network at an airport, the client will get an IP address from the Wi-Fi network's DHCP server. If that IP also belongs to the network behind the Clavister NetShield Firewall accessible through a tunnel, then Windows will still continue to assume that the IP address is to be found on the client's local network. Windows therefore will not correctly route packets bound for the remote network through the tunnel but instead route them to the local network.
The solution to this problem of local/remote IP address duplication is to create a new route in the client's Windows routing table that explicitly routes the IP address to the tunnel. For example, suppose 192.168.99.2 is the server to be reached, 192.168.0.0/24 is the remote network and 192.168.99.2 is assigned by L2TP or PPTP to the Windows computer. The Windows command line to add a route would be:
C:\> route add 192.168.0.2 mask 255.255.255.255 192.168.99.2
Is the correct tunnel being selected? When an external client connects, cOS Stream makes a decision about which IPsec tunnel object to use by choosing the tunnel that has the parameters that most closely match the incoming connection. However, the tunnel object selected in the initial exchange between client and cOS Stream may have to change because a mismatch is discovered in a later phase.
This can result, for example, in a situation where the proposal list matches one IPsec tunnel object but authentication matches another tunnel object. The administrator should be aware that this can happen so unexpected behavior can be understood. This topic is discussed with more depth in Section 13.2.8, IPsec Tunnels.
The properties are:
They allow cOS Stream to behave like an IPsec client with a predefined set of authentication parameters. These properties are not used in a live traffic environment.
If certificates have been used in a VPN solution then the following should be looked at as a source of potential problems:
Check that the correct certificates have been used for the correct purposes.
Check that the certificate .cer and .key files have the same filename. For example, my_cert.key and my_cert.cer.
Check that the certificates have not expired. Certificates have a specific lifetime and when this expires they cannot be used and new certificates must be issued.
Check that the system date and time is set correctly. If the system time and date is wrong then certificates can appear as being expired when, in fact, they are not.
Consider time-zone issues with newly generated certificates. The Clavister NetShield Firewall's time zone may not be the same as the CA server's time zone and the certificate may not yet be valid in the local zone.
Disable CRL (revocation list) checking to see if CA server access could be the problem. CA server issues are discussed further in Section 16.2, CA Server Access.
Use the ike CLI command to clear the certificate cache:
System:/> ike -certflushcOS Stream uses the certificate version that is in the cache if it is there. If there has been a change to a certificate either locally or remotely then the cache may need to be updated.
The contents of the cache can be examined using only the -certshow option on its own. Some example output is given below:
System:/> ike -certshow
IKE Certificates
# Subject
- ----------------------------------
1 C=SE, O=Clavister, OU=R&D, CN=TTG
2 C=SE, O=Clavister, OU=R&D, CN=TTG2
3 C=SE, O=Clavister, OU=R&D, CN=GGSN
4 DC=local, DC=devlab, CN=labsrvThe abbreviations found in this output have the following meanings for each cached certificate:
C - ISO3166 two character country code.
ST - State or province.
L - Locality. Usually a city.
O - Organization. Usually a company name.
OU - The organization unit. Typically, the certificate type.
CN - The common name. Typically a product name.
DC - The domain component.
The -verbose option with the -certshow option can provide more detailed information about the cache contents:
System:/> ike -certshow -verbose
IKE Certificates
# Subject Issuer Valid From Valid To Status
- --------------- -------------- ------------- ------------ ------
1 C=SE, DC=local, 2024-05-09 2026-05-09 Valid
O=Clavister, DC=lab, 06:37:00 06:47:00
OU=R&D, CN=TTG CN=labsrv
2 C=SE, DC=local, 2024-06-28 2026-06-28 Valid
O=Clavister, DC=lab, 08:34:49 08:44:49
OU=R&D, CN=TTG2 CN=labsrv
3 C=SE, DC=local, 2024-07-28 2026-07-28 Valid
O=Clavister, DC=lab, 07:55:33 08:05:33
OU=R&D, CN=GGSN CN=labsrv
4 DC=local, DC=local, 2024-10-11 2026-10-11 Valid
DC=lab, DC=lab, 10:09:29 10:17:17
CN=labsrv CN=labsrv
A number of commands can be used to diagnose IPsec tunnel issues:
Using the flow CLI Command
IPsec traffic consists of ESP flows. A flow is unidirectional and ESP traffic consists of a single, unidirectional flow. ESP flows can be examined using the flow CLI command.For example, all flows could be examined using the command:
System:/> flow -show
Proto Source Destination Timeout
------- ----------------------------- ----------------------------- -------
ESP core:53.0.0.1 ext:53.0.1.2:0x757d8003 125
ICMP ipsec-1:192.100.1.9:2048 gtp-1:192.200.0.1:17683 7
ESP ext:53.0.1.2 core:53.0.0.1:0x608f21ad 129
UDP core:53.10.0.2:2152 int:53.10.0.1:2152 129
UDP core:53.10.0.2:2123 int:53.10.0.1:2123 113
ESP ext:53.0.1.2 core:53.0.0.1:0x42c5fd04 75
UDP core:172.22.53.101:514 mgm:172.22.53.1:514 125
![[Caution]](images/caution.png) |
Caution: ESP uses hexadecimal numbers in flow output |
|---|---|
|
It is important to be aware that instead of decimal port numbers in the flow command output for ESP, the values displayed are SPI numbers and these are specified using hexadecimal. |
The reverse flows for the above can be displayed using the -verbose option:
System:/> flow -show -verbose
Proto Source Destination Timeout
------- ----------------------------- ----------------------------- -------
ESP core(0):53.0.0.1 ext:53.0.1.2:0x757d8003 126
...rev: core(0):53.0.0.1 ext:53.0.1.2:0x757d8003 126
ICMP ipsec-1(33):192.100.1.9:2048 gtp-1:192.200.0.1:17683 7
...rev: ipsec-1(33):192.100.1.9:17683 gtp-1:192.200.0.1:0 7
ESP ext(0):53.0.1.2 core:53.0.0.1:0x608f21ad 129
...rev: ext(0):53.0.1.2 core:53.0.0.1:0x608f21ad 129
UDP core(0):53.10.0.2:2152 int:53.10.0.1:2152 129
...rev: core(0):53.10.0.2:2152 int:53.10.0.1:2152 129
UDP core(0):53.10.0.2:2123 int:53.10.0.1:2123 110
...rev: core(0):53.10.0.2:2123 int:53.10.0.1:2123 110
ESP ext(0):53.0.1.2 core:53.0.0.1:0x42c5fd04 72
...rev: ext(0):53.0.1.2 core:53.0.0.1:0x42c5fd04 72
UDP core(0):172.22.53.101:514 mgm:172.22.53.1:514 121
...rev: core(0):172.22.53.101:514 mgm:172.22.53.1:514 121
![[Note]](images/note.png) |
Note |
|---|---|
|
The reverse flows in the output above (beginning with "...rev:") have the source and destination shown in reverse order so they do not match the column heading. |
The displayed list can be filtered using any of a number of filtering parameters. For example, all flows that have a destination of the IPsec tunnel called my_tunnel could be examined with the command:
System:/> flow -show -destiface=my_tunnel
All options for the flow command can be found in the separate CLI Reference Guide.
The following command can provide a snapshot of the current state of negotiated tunnels:System:/> ike -statThis can be used to show that IPsec tunnels have been correctly established. A typical example of output from this command is shown below:
System:/> ike -stat
IKE Statistics
Statistic Value
---------------------------- -----
IKE SAs active 2
IKE SA negotiations active 0
IKE SA negotiations done 3
IKE SA negotiations failed 1
IKE SA rekeys active 0
IKE SA rekeys done 0
IKE SA rekeys failed 0
IPsec SAs active 2
IPsec SA negotiations active 0
IPsec SA negotiations done 2
IPsec SA negotiations failed 0
IPsec SA rekeys active 0
IPsec SA rekeys done 0
IPsec SA rekeys failed 0
The ike -stat command provide a static view of IPsec tunnels. To see what is happening during the IKE negotiation of tunnel setup, the -snoop option should be used and this is discussed next.
VPN Tunnel Negotiation
When setting up IPsec tunnels, problems can arise because the initial negotiation fails when the network devices at either end of a VPN tunnel try but fail to agree on which protocols and encryption methods will be used.The CLI command ike -snoop is a tool that can be used to identify such problems by showing the details of the exchanges that occur when the peers at either end of the IPsec tunnel try to agree on a mutually acceptable set of algorithms. The algorithm lists they exchange are often referred to as proposal lists.
Using ike -snoop
The ike -snoop command is entered via a CLI console.To begin monitoring with basic, summarized output, the full CLI command is:
System:/> ike -snoop -briefThis causes diagnostic output to be continuously sent to the console for all VPN tunnel IKE negotiations that take place, regardless of interface.
To turn off monitoring, the command is:
System:/> ike -snoop -off
Presented below is some typical ike -snoop output (the formatting has been changed slightly to fit the page). The tunnel negotiation considered is based on pre-shared Keys. A negotiation based on certificates is not discussed here but the principles are the same.
SNOOP: IKEv2: 2025-11-22 12:30:09 172.22.53.18:500 <- 172.22.53.23:500 IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] SNOOP: IKEv2: 2025-11-22 12:30:09 172.22.53.18:500 -> 172.22.53.23:500 IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ] SNOOP: IKEv2: 2025-11-22 12:30:09 172.22.53.18:500 <- 172.22.53.23:500 IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ] SNOOP: IKEv2: 2025-11-22 12:30:09 172.22.53.18:500 -> 172.22.53.23:500 IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]
In these listings the direction of packet movement is indicated by the <- and -> symbols. The IPv4 address and port number given on the left side of these symbols is local. The address and port number given on the right side is remote. Each packet movement is preceded by a timestamp.
Consider the first part:
172.22.53.18:500 <- 172.22.53.23:500
Indicates that an initial request to set up a security association was made and originates from remote IPv4 address 172.22.53.23, port 500, which will be the remote tunnel endpoint. This was received at local IPv4 address 172.22.53.18, port 500 on the local firewall and this will be the local tunnel endpoint.
The nature of this request is described next:
IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
It is a security association (SA) initialization and the various abbreviations describe the details:
KE - Key Exchange
No - NONCE
N - Notify
The notification payloads in this case are NATD_S_IP and NATD_D_IP.
The second part of the output shows the local firewall sending the IKE response back to IPv4 address 172.22.53.23:
172.22.53.18:500 -> 172.22.53.23:500
The third part of the output (IKE_AUTH request 1) is a request from the remote tunnel endpoint 172.22.53.23 to try and agree algorithms:
IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N (NON_FIRST_FRAG)
The actual algorithms in the proposal lists sent by each tunnel peer are not shown in this summary version of the ike command. However, the sequence of steps leading to success or failure are shown.
Complete ike command options and abbreviation descriptions can be found in the Clavister cOS Stream CLI Reference Guide.
If any VPN tunnel is set up and then the management interface no longer operates then it is likely to be a problem with the management traffic being routed back through the VPN tunnel instead of the correct interface.
This happens when a route is established in the main routing table which routes any traffic for all-nets-ip4 through the VPN tunnel. If the management interface is not reached by the VPN tunnel then the administrator needs to create a specific route that routes management interface traffic leaving the Clavister NetShield Firewall back to the management sub-network.
This section will deal with specific error messages that can appear with VPN and what they indicate. The messages discussed are:
1. Could not find acceptable proposal / no proposal chosen.
2. Incorrect pre-shared key.
3. Ike_invalid_payload, Ike_invalid_cookie.
4. Payload_Malformed.
5. No public key found.
1. Could not find acceptable proposal / no proposal chosen
This is the most common IPsec related error message. It means that depending on which side initiates tunnel setup, the negotiations in either the IKE or the IPSec phase of setup failed since they were unable to find a matching proposal that both sides could agree on.Troubleshooting this error message can be involved since the reasons for this message can be multiple depending on where in the negotiation it occurred.
If the negotiation fails during phase-1 – IKE
The IKE proposal list does not match. Double check that the IKE proposal list matches that of the remote side. A good idea is to use the ike -snoop -full command in the console and get the tunnel to initiate the tunnel from the remote side. You will be able to then see what proposals the remote side is sending and then compare the results with your own IKE proposal list. At least one proposal has to match in order for it to pass phase-1. Don't forget that the lifetimes are also important.
If the negotiation fails during phase-2 – IPsec
The IPsec proposal list does not match. Double check that the IPsec proposal list matches that of the remote side. The same method described above of using ike -snoop can be used from when the remote side initiates the tunnel and compare it against your own proposal list. What is "extra" in the IPsec phase is that the networks are negotiated here. Even if the IPsec proposal list seems to match the problem may be with mismatching networks. The Local Network(s) on your side needs to be the Remote Network on the other side and vice versa. Remember that multiple networks will generate multiple IPsec SAs, one SA per network (or host if you use that option). The defined network size is also important in that it must have exactly the same size on both sides, as will be mentioned again later in the symptom section.
There are also some cOS Stream settings on the IPsec tunnel that can be involved in a no-proposal chosen issue. Such as Main or Aggressive mode, DH Group (for the IKE phase) and PFS (for IPsec phase).
2. Incorrect pre-shared key
A problem with the pre-shared key on either side has caused the tunnel negotiation to fail. This is perhaps the easiest of all the error messages to troubleshoot since it can be only one thing, and that is an incorrect pre-shared key. Double-check that the pre-shared key is also of the same type (Passphrase or Hex-key) and correctly added on both sides of the tunnel.Another reason for why cOS Stream detects that the pre-shared key is incorrect could be because the wrong tunnel is triggering during tunnel negotiations. IPsec tunnels are processed from the top to the bottom of the system tunnel list and are initially matched against the remote gateway. An example is if there is a roaming tunnel that uses all-nets-ip4 as its remote gateway. This tunnel will trigger before your defined tunnel if it is above it in the tunnel list.
3. Ike_invalid_payload, Ike_invalid_cookie
In this case the IPsec engine in cOS Stream receives an IPsec IKE packet but is unable to match it against an existing IKE.If a VPN tunnel is only established on one side, this can be the resulting error message when traffic arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has only gone down from the initiator side but the terminator still sees it as up. It then tries to send packets through the tunnel but when they arrive at the initiator it will drop them since no matching tunnel can be found.
Simply remove the tunnel from the side that believes it is still up to solve the immediate problem. An investigation as to why the tunnel only went down from one side is recommended. It could be that DPD and/or Keep-Alive is only used on one side. Another possible cause could be that even though it has received a DELETE packet, it has not deleted/removed the tunnel.
4. Payload_Malformed
This problem is very similar to the Incorrect pre-shared key problem described previously. A possible reason is that the PSK is of the wrong TYPE on either side (Passphrase or Hex key).Verify that you are using the same type on both sides of the IPsec tunnel. If one side is using Hex and the other Passphrase, this is most likely the error message that you will receive.
5. No public key found
This is a very common error message when dealing with tunnels that use certificates for authentication.Troubleshooting this error message can be very difficult. It is very important to keep in mind that when dealing with certificates it may be required to combine the output from ike -snoop with standard event logs because ike -snoop does not give that much information about certificates. A good suggestion before starting to troubleshoot certificate based tunnels is to first configure it as a PSK tunnel and then verify that it can successfully establish, then move on to using certificates. (Unless the configuration type prohibits that).
The possible causes are as follows:
The certificate on either side is not signed by the same CA server.
The certificate's validity time has expired or it has not yet started to be valid. The latter can happen if the clock is set incorrectly on either the CA server or the Clavister NetShield Firewall or they are in different time zones.
The Clavister NetShield Firewall is unable to reach the Certificate Revocation List (CRL) on the CA server in order to verify if the certificate is valid or not. Double-check that the CRL path is valid in the certificate's properties. (Using the CRL feature could be turned off.) Make sure also that there is a DNS client configured in cOS Stream in order for it to be able to correctly resolve the path to the CRL.
The tunnel can only be initiated from one side
This is a common problem and is due to a mismatch of the size in local or remote network and/or the lifetime settings on the proposal list(s).To troubleshoot this, the settings for the local network, remote network, IKE proposal list and IPsec proposal list on both sides need to be examined to try to identify a miss-match.
For example, suppose there are the following IPsec settings at either end of a tunnel:
Side A
Local Network = 192.168.10.0/24
Remote Network = 10.10.10.0/24
Side B
Local Network = 10.10.10.0/24
Remote Network = 192.168.10.0/16
In this scenario, the defined remote network on Side B is larger than that defined for Side A's local network. This means that Side A can only initiate the tunnel successfully towards Site B as its network is smaller. When Side B tries to initiate the tunnel, Side A will reject it because the network is bigger than what is defined. The reason it works the other way around is because a smaller network is considered more secure and will be accepted. This also applies to the lifetimes in the proposal lists.
