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.