Traces - general:

LANCOM routers provide the option of logging internal processes in order to diagnose errors.
This trace function can be accessed from the telnet console.

Below you will find a VPN trace with the meaning of each message explained.

Application:

The VPN trace function us used to monitor that a VPN connection is correctly established.
This applies both to VPN LAN-LAN connections as well as to VPN dial-in connections.

To do this, enter the command "trace + vpn-status" at a telnet console.

VPN trace in detail:

2004/01/20 15:18:34,500 Timestamp, precedes all output
VPN: connecting to BUGFIX (213.23.254.24) first VPN message: The connection to remote site "BUGFIX" is being established. BUGFIX has the IP address: 213.23.254.24
2004/01/20 15:18:34,510
VPN: start dynamic VPN negotiation for BUGFIX (213.23.254.24) via ICMP/UDP		 An ICMP packet is now being sent in order to transmit the local IP address to the remote site.
2004/01/20 15:18:34,510
VPN: create authentication packet for BUGFIX (213.23.254.24)
DNS: 10.98.0.241, 0.0.0.0
NBNS: 10.98.0.241, 0.0.0.0		 An authentication packet, including transmission of the local DNS and NBNS servers,
is now being generated for this station.
2004/01/20 15:18:34,510
VPN: installing ruleset for BUGFIX (213.23.254.24)		 The VPN rules are now being generated for the remote site.
2004/01/20 15:18:34,520
VPN: ruleset installed for BUGFIX (213.23.254.24)		 The VPN rules have been generated.
2004/01/20 15:18:34,520
VPN: start IKE negotiation for BUGFIX (213.23.254.24)		 The local device is now starting IKE negotiation.
2004/01/20 15:18:34,530
VPN: installed rulesets		 The creation of VPN rules has now been concluded.
2004/01/20 15:18:34,530
VpnIpm: info; phase-1 negotiation started for peer isakmp-peer-BUGFIX		 Phase 1 of VPN negotiation has now started.
2004/01/20 15:18:34,530
VpnIpm: info; Phase-1 negotiation started for peer BUGFIX rule isakmp-peer-BUGFIX using MAIN mode		 Main mode is being used.
2004/01/20 15:18:34,740
VPN: received authentication packet from BUGFIX (213.23.254.24)
DNS: 192.168.2.1, 0.0.0.0
NBNS: 192.168.2.1, 0.0.0.0		 An authentication packet has been received from BUGFIX and the addresses of its DNS and NBNS servers have been communicated.
2004/01/20 15:18:34,800
VpnIpm: info; The remote server 213.23.254.24:500 id <no_id> is Enigmatec IPSEC version 1.4.0		 The remote server (other router) is using an Enigmatec IPsec stack.
The ID will be displayed instead of <no_id> if aggressive mode is used.
2004/01/20 15:18:34,800
VpnIpm: info; phase-1 proposal failed; remote No 1 encryption algorithm = BLOWFISH_CBC <-> local No 1 encryption algorithm = AES_CBC		 There is no agreement on the first negotiation proposal. The remote site requests Blowfish-CBC encryption while we want AES-CBC.
2004/01/20 15:18:34,800
VpnIpm: info; phase-1 proposal failed; remote No 1 encryption algorithm = BLOWFISH_CBC <-> local No 2 encryption algorithm = AES_CBC		 There is no agreement on the second negotiation proposal. The local setting for the 2nd proposal is also AES-CBC.
2004/01/20 15:18:34,810
VpnIpm: info; Phase-1 remote proposal 1 matched with local proposal 3		 The remote site's 1st proposal matches the 3rd local proposal.
2004/01/20 15:18:37,530
VpnIpm: info; Phase-1 [inititiator] between initiator id 213.54.81.158, responder id 213.23.254.24 done		 The negotiation of phase 1 for the connection between the current public addresses has been completed.
2004/01/20 15:18:37,530
VpnIpm: info; SA ISAKMP for peer BUGFIX encryption blowfish-cbc authentication md5		 The encryption negotiated for phase 1 is now displayed.
2004/01/20 15:18:37,530
VpnIpm: info; life time ( 108000 sec/ 0 kb)		 The lifetime of phase 1 of the connection has been set to 108000.
2004/01/20 15:18:40,190
VpnIpm: info; Phase-2 [inititiator] done with 2 SAS for peer BUGFIX rule ipsec-0-BUGFIX-pr0-l0-r0		 Initialization of phase 2 for remote site BUGFIX.
2004/01/20 15:18:40,190
VpnIpm: info; rule:' ipsec 10.98.0.240/255.255.255.240 <-> 192.168.2.0/255.255.255.0 '		 The IPSec rule for communication between the two local networks is being created.
2004/01/20 15:18:40,190
VpnIpm: info; SA ESP [0x6cfe59fb] alg BLOWFISH keylength 128 +hmac HMAC_SHA outgoing		 The outgoing packet encryption that was negotiated is displayed.
2004/01/20 15:18:40,190
VpnIpm: info; SA ESP [0x3444a4b9] alg BLOWFISH keylength 128 +hmac HMAC_SHA incoming		 The incoming packet encryption that was negotiated is displayed.
2004/01/20 15:18:40,200
VpnIpm: info; life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)		 The lifetimes for phase 2 are being set.
2004/01/20 15:18:40,200
VpnIpm: info; tunnel between src: 213.54.81.158 dst: 213.23.254.24 		The tunnel for phase 2 between the public IP addresses has been established.
2004/01/20 15:18:41,360
VPN: BUGFIX (213.23.254.24) connected, set poll timer to 30 sec		 VPN negotiation has been completed; the connection is established.
The timer to monitor the connection at regular intervals is set.



Frequent error messages and their meaning in the VPN trace:


Error message: Remote site is not responding:

[VPN-Status] 2007/12/04 14:37:57,210
VPN: connection for BUGFIX (213.23.254.24) timed out: no response		 This message shows that the remote station has not responded to the connection request.
It is displayed 30 seconds after the connection attempt begins.
[VPN-Status] 2007/12/04 14:37:57,210
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for BUGFIX (213.23.254.24)		 The internal error message is generated and communicated, for example to the LANmonitor. The remote station has not responded.


Meaning:
The remote station is not responding to the LANCOM's connection request. There is no response.

Possible causes:
- The gateway address is not correct. A DynDNS name of the remote station has not been updated or the IP address entered is not correct.
- The remote station has not been configured for this connection and cannot assign the connection request. It therefore does not respond.
- A firewall is preventing the LANCOM's request packet from reaching the remote station.

Further action:
- Perform a VPN trace on the remote station in order to determine the cause.


Error message: Line polling failed:

[VPN-Status] 2007/12/04 01:24:43,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval		 There was a timeout during polling for remote station BUGFIX; a polling packet was not answered within the time set.
setting poll time to 1 sec. As a reaction to this the LANCOM sets the polling counter to one second. Polling now occurs every second.
(5 retries left) This is now retried 5 times. If this fails, the line will be disconnected.
send poll frame to 192.168.3.254 A polling packet is sent to this address.
[VPN-Status] 2007/12/04 01:24:44,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval
(4 retries left)
send poll frame to 192.168.3.254

[VPN-Status] 2007/12/04 01:24:45,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval
(3 retries left)
send poll frame to 192.168.3.254

[VPN-Status] 2007/12/04 01:24:46,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval
(2 retries left)
send poll frame to 192.168.3.254

[VPN-Status] 2007/12/04 01:24:47,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval
(1 retries left)
send poll frame to 192.168.3.254		 This will now be repeated another four times.
[VPN-Status] 2007/12/04 01:24:48,710
VPN: poll timeout for BUGFIX (213.23.254.24)
remote site did not answer during interval
no retries left, disconnect channel		 The five attempts were not successful; the remote station did not respond.

The line is now being disconnected.
[VPN-Status] 2007/12/04 01:24:48,720
VPN: Error: IFC-X-Line-polling-failed (0x1307) for BUGFIX (213.23.254.24)		 The official error message is now generated for this.
[VPN-Status] 2007/12/04 01:24:48,720
VPN: disconnecting BUGFIX (213.23.254.24)		 Disconnection is now initiated.


Meaning:
The remote station is not responding to the line monitoring. As these packets are not being answered the line is disconnected.

Possible causes:
- The polling address is not correct. For this reason the wrong address is being sent packets and it does not respond.
- The VPN connection has been established but is not working correctly, e.g. because a firewall is preventing correct communication
- Packets are being sent to the IP address of the remote LANCOM but this has the option "Ping blocking" set and is therefore not responding.

Further action:
- Check polling settings in the polling table and the PPP list.
- If necessary check whether polling packets are arriving there using an ICMP trace at the remote site.
- The polling destination is ideally the LAN IP address of the remote LANCOM. If this is not possible, use another address in the LAN that must ALWAYS be reachable. The connection will not work if this address is unreachable.



Error message: No entry in polling table and keepalive is set:


[VPN-Status] 2007/12/04 01:24:48,720
VPN: Error: IFC-I-No-poll-table-entry-matched (0x1108) for BUGFIX (213.23.254.24)		 the error message "No entry in polling table and keepalive is set" is generated.

Meaning:
Keepalive has been set for this connection (keepalive "9999" in the VPN connection list) but there is no polling entry in the polling table.

Cause:
- Keepalive has been set for this connection (keepalive "9999" in the VPN connection list) but there is no polling entry in the polling table.

Further action:
- Create a polling entry in the polling table for this remote station. Please note that the polling address must always respond as otherwise the connection cannot be established.



All LANCOM products and software versions are subject to LANCOM Software Lifecycle Management.
You can find information on our website at https://www.lancom-systems.com/products/firmware/software-lifecycle-management

© 2019-2024 LANCOM Systems GmbH