Description:
This document describes the monitoring function provided by the action tab=
le and notifications sent to the administrator via e-mail and/or SMS text m=
essage.
Information:
For notification via SMS, you need at least LCOS version 8.84 and a=
LANCOM 3G or 4G router.
Requirements:
Scenario:
The administrator should be notified of the failure of a VPN connection by=
e-mail. To perform this, the line is polled and an action is defined that =
sends an e-mail or SMS in the event of an unintended connection failure. In=
contrast, planned connection outages (e.g.: a forced re-connect of the DSL=
connection by the provider) should be ignored.
The monitoring by polling and the notification in case of disconnection on=
ly needs to be configured at the headquarters/central site. This will recog=
nize the failure of any VPN connection and send information appropriately.<=
br>
However, at least one of the remote sites should also be configured to sen=
d out a notification in case of DSL failure at the central site , as the ce=
ntral site would be unable to send out any e-mails.
Three types of polling are available with a LANCOM VPN router.
- PPP LCP echo monitoring: This can be used when the link is a dynamic VP=
N connection over ICMP, when the link uses the ISDN D-channel or the ISDN B=
-channel.
- Dead Peer Detection: Sends "are you there" packets as part of the IKE p=
rocess.
- ICMP polling: Sends ICMP packets to an IP address on the remote device =
(ideally the internal IP address of the remote VPN router).
It is possible to define several pollings to operate simultaneously. Only =
one type of polling has to be defined in order to recognize a connection fa=
ilure.
The example scenario assumes a star-form VPN structure with three remote s=
ites and one central site. The connections are established automatically by=
the remote sites (keep alive).
Headquarters: Network ID: 192.168.0.0/24 Local IP: 192.168.0.1 Remote site 1:=
Network ID: 192.168.1.0/24 Local IP: 192.168.1.1 Remote site 2: =
Network ID: 192.168.2.0/24 Local IP: 192.168.2.1 Remote site 3: N=
etwork ID: 192.168.3.0/24 Local IP: 192.168.3.1
Procedure:
The example shows how to use LANconfig to carry out the configuration for,=
in this case, the headquarters and remote site 1. When setting up other re=
mote sites, the procedure at the headquarters remains the same.
=
1) Activating polling to monitor the VPN connection
This scenario uses DPD polling at both ends. This sends "Are you there" pa=
ckets during the IKE at a configurable interval. It is activated by setting=
a time value for the Dead Peer Connection parameter in the connecti=
on list.
2) Configuring SMTP parameters
SMTP data are entered under Configuration -> Log & Trace -> S=
MTP Account.
3) Configuring the SMS module<=
/b>
If you are operating a 3G or 4G-capable LANCOM router with LCOS version=
8.84 or later, you have the option to send notifications via SMS. <=
br>
To do this, you configure the SMS module in the menu Configuration ->=
; Log & Trace -> SMS messages.
- Under Inbox size you set the maximum number of text messages sto=
red in the device inbox. If the preset number is exceeded, the oldest messa=
ge will be deleted. In this case there is no SYSLOG entry. The value 0 disa=
bles the limit, i.e. there is no limit on the number of messages stored.
- The item Deletion of sent messages decides how the device handle=
s sent text messages.
- Immediately: Sent messages are not saved.
- Never: Sent messages are saved permanently.
- Under Outbox size you set the maximum number of text messages st=
ored in the device outbox. If the preset number is exceeded, the oldest mes=
sage will be deleted. In this case there is no SYSLOG entry. The value 0 di=
sables the limit, i.e. there is no limit on the number of messages stored.<=
/li>
- Under Syslog messaging you specify if and how the arrival of tex=
t messages is logged to the SYSLOG.
-
- No: Incoming text messages are not logged to SYSLOG.
- Only sender/no content: The arrival of a text message is recorde=
d to the SYSLOG together with the sender's phone number.
- Full: The arrival of a text message is recorded to the SYSLOG to=
gether with the sender's phone number and the message in full.
- Optional: Under Mail forwarding address you specify the e=
-mail address to which the device forwards the incoming SMS text messages. =
E-mail routing will only work if a valid SMTP account is configured in the =
device (see step 2).
4) Time server configuration (NTP client)
The router must be configured as an NTP client of a time server in order t=
o communicate the correct time of failure. In most applications this featur=
e makes it easier to attribute the correct time of the log and monitoring.<=
br>
For this purpose an NTP server can be specified under Configuration -&g=
t; Date & Time -> Synchronization. The addresses of several popu=
lar NTP servers are already defined. Several addresses can be configured to=
acheive redundancy.
5) Generating a notifica=
tion
The action table stores the connection status of the remote devices. An ac=
tion specified here should be performed if there is no response to the poll=
ing.
5.1) Notification by e-mail
The syntax for the action is:
mailto:test@lancom.de?s=
ubject=3DVPN connection down at %t?body=3DVPN connection to Office 1 is=
down.
- mailto: =3D command
- test@lancom.de =3D target e-mail address
- ? =3D separator
- subject =3D subject line
- %t =3D variable for current system time (optional)
- body =3D text body
5.2) Notification by SMS<=
br> Information:
For notification via SMS, you need at least LCOS version 8.84 and a=
LANCOM 3G or 4G router.
The syntax for the action is:
exec: smssend -d <phone number&=
gt; -t <text max. 160 characters>
- Example: exec: smssend -d 017112345678 -t "The VPN connection to=
Office 1 is down."
6) Suppressing e-mail notification in th=
e event of a forced disconnect of the underlying DSL link
Most DSL connections are subject to a forced re-connect every 24 hours. Pe=
rform the following steps to avoid an e-mail being generated for this event=
.
The forced re-connect is rescheduled to 3 AM using a real-time CRON job. Command: do /other/manual/disconnect <remote_device_name>
Another CRON entry deactivates the action table entry used to generate the=
outage e-mail before the line is disconnected.
Command: set /set=
up/wan/action-table/X no
The placeholder X stands for the=
index entry in the action table (e.g., )set /setup/wan/action-table/1 n=
o)
The action table is reactivated after the forced re-connection of the line=
.
Command: set /setup/wan/action-table/X yes
The pl=
aceholder X stands for the index entry in the action table (e.g., se=
t /setup/wan/action-table/1 yes)
|
|