#666 Problem with vpn-watch script

[Dermot]

I have a net to net VPN set up from my IPCOP to another IPCOP in another country. My side has static DNS, the remote side has dynamic DNS so we have created a DDNS name for their side.

The VPN can activate and operate successfully but when their IP address changes the VPN goes down and does not get reconnected. The remote side correctly notifies the DDNS server of the change of IP address.

While debugging this problem I noticed an error in the vpn-watch script that runs locally here trying to detect a change in IP address at the peer. This is not the complete cause of my problem because it still does not reconnect without someone at the remote side forcing a restart, but it is an error that must be fixed.

The vpn-watch script uses the command /usr/bin/host to lookup the IP address for the configured FQDN of the peer. I think the output from /usr/bin/host must have changed some time, because the remainder of the function to get the IP address fails and the script tries 3 times then terminates.

The output from /usr/bin/host is like this:

peer.dyndns.org has address 12.34.56.78
peer.dyndns.org mail is handled by 10 mail.fred.net.

I think the reporting of MX record results must be a recent change to /usr/bin/host (in fact I think it is a bug in /usr/bin/host since the default operation is meant to return only A records, not MX). The check for a valid IP address fails because the second line is present.

The following change in get_ip() fixes the script:

OLD:
RESULT=$(/usr/bin/host "$1" 2>/dev/null| awk '{ print $4 }')

NEW:
RESULT=$(/usr/bin/host -t A "$1" 2>/dev/null| awk '{ print $4 }')

With this change my side sees the IP address change and restarts VPN services, but the VPN still does not come back up until someone at the other side manually selects restart of the VPN entry. I will keep on debugging but if anyone has any ideas I would be pleased to hear them. The debug options for VPN generate a lot of output, but it is not easy to follow...

Dermot

[Olaf Westrik]

Logged In: YES
user_id=1120714
Originator: NO

/usr/bin/host has not changed since some months. Could there have been a change in your dyndns service ?

Your fix looks good (regardless of what has changed).

[Dermot]

Logged In: YES
user_id=1893184
Originator: YES

There was no change to the dyndns service - it never worked for me when the IP address changed and it was just that my debugging turned up the reason why. Perhaps other dyndns services do not have MX records? Anyway - as you say the script patch to only return A records will work whether or not /usr/bin/host is fixed, so it should be OK to include at the earliest opportunity as a fix for 1.4.x. I believe there is a release imminent and this is not risky at all but I don't know how it gets included.

[Olaf Westrik]

Logged In: YES
user_id=1120714
Originator: NO

Sorry, your original report let me believe that it worked before, because you assumed a change in /usr/bin/host ;-)
Never mind.

IIRC dyndns reports MX records depending on service (free or charged for ;-))

I'll include your fix soon. Thanks for reporting and tracking the bug.

[Olaf Westrik]

Logged In: YES
user_id=1120714
Originator: NO

> I'll include your fix soon. Thanks for reporting and tracking the bug.

Forget that, Gilles has already done so (some time ago)...

[SourceForge Robot]

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[Olaf Westrik]

Logged In: YES
user_id=1120714
Originator: NO

With 1.4.21 this bug has returned.

[Dermot]

Logged In: YES
user_id=1893184
Originator: YES

Yes it seems that the most recent fix to bug 1835486 "vpn-watch error on alias dnsname" breaks the fix made for this bug.

Without the "-t A" parameter, /usr/bin/host can return MX records if available, definitely breaking the script.

It seems that perhaps including the "-t A" parameter but then parsing for the last entry in the list will address both bugs. Perhaps not elegantly, but avoiding the need for a configuration option or complex decision making.

Like this:

RESULT=$(/usr/bin/host -t A "$1" | /usr/bin/tail -1 2>/dev/null| /usr/bin/awk '{ print $4 }')

Of course I cannot test that it fixes Bug 1835486 because I have no aliases.