Thank you all for reading so far and searching an answer.
I've finally found the problem. Quite a nasty thing. We use vtun over
clients.
Usually port 21 is open.
bandwith. Transparent ftp proxy on port 21. Bad. Bad bad thing. It could
failed. No explanation : just connection denied. Why ? Auth ? SSL
connection failed ? Unknow host ? no explanation at all. I think this
should be improved.
Thak you all and have a nice day.
Post by Chris FowlerDPI firewall at a location that is now inspecting? Happens to me often.
Mondays most. Techs come in, see rule on firewall, and change it not
knowing. If a unit goes down on the weekend then 90% of the time it is
due to network adjustments.
Are they really remotes? My systems are port scanned often.
On on server I modified the source to log the host argument to syslog so
I could fix these. I can't find the changes now,
but I made a patch off another vtun src tree. It may be wrong and in
the wrong place. It is just to show you.
diff -ruN a/auth.c b/auth.c
--- a/auth.c 2009-05-15 07:23:39.000000000 +0000
+++ b/auth.c 2017-01-26 22:46:58.873752909 +0000
@@ -342,6 +342,7 @@
if( !strcmp(str1,"HOST") ){
host = strdup(str2);
+ vtun_syslog(LOG_INFO,"Request for %s", host);
gen_chal(chal_req);
print_p(fd,"OK CHAL: %s\n", cl2cs(chal_req));
-------
I also made some changes that could help you
diff -u -r a/client.c b/client.c
--- a/client.c 2012-07-08 05:32:57.000000000 +0000
+++ b/client.c 2017-01-12 04:45:51.601352228 +0000
@@ -46,6 +46,11 @@
#include "compat.h"
#include "netlib.h"
+
+extern int get_delay(void);
+
+static int sl = 0;
+
static volatile sig_atomic_t client_term;
static void sig_term(int sig)
{
@@ -58,6 +63,8 @@
struct sockaddr_in my_addr,svr_addr;
struct sigaction sa;
int s, opt, reconnect;
+ int sl = 0;
+ int initial_connect = 0;
vtun_syslog(LOG_INFO,"VTun client ver %s started",VTUN_VER);
@@ -78,7 +85,20 @@
if( reconnect && (client_term != VTUN_SIG_HUP) ){
if( vtun.persist || host->persist ){
/* Persist mode. Sleep and reconnect. */
- sleep(5);
+ /**
+ CFOWLER
+ To reduce load averages on the remote server we will
+ not reconnect every minute. Instead each device will
+ pick a random sleep value between 30 - 180s at the fist
+ connect and use that.
+ **/
+ if(initial_connect == 1) {
+ sl = get_delay();
+ vtun_syslog(LOG_INFO, "Will delay %d(s) before reconnect", sl);
+ sleep(sl);
+ } else {
+ sleep(30);
+ }
} else {
/* Exit */
break;
@@ -140,6 +160,7 @@
host->rmt_fd = s;
/* Start the tunnel */
+ initial_connect = 1;
client_term = tunnel(host);
vtun_syslog(LOG_INFO,"Session %s[%s] closed",host->host,vtun.svr_name);
diff -u -r a/main.c b/main.c
--- a/main.c 2012-07-08 05:32:57.000000000 +0000
+++ b/main.c 2017-01-12 04:45:51.605352327 +0000
@@ -53,6 +53,18 @@
/* for the NATHack bit. Is our UDP session connected? */
int is_rmt_fd_connected=1;
+int delay = 0;
+
+int get_delay(void) {
+ if(delay == 0) {
+ srand(time(NULL));
+ delay = 1 + (int) (150.0 * (rand() / (RAND_MAX + 1.0)));
+ // At least 30s
+ delay = delay + 30;
+ }
+ return delay;
+}
+
int main(int argc, char *argv[], char *env[])
{
int svr, daemon, sock, dofork, fd, opt;
diff -u -r a/netlib.c b/netlib.c
--- a/netlib.c 2009-03-29 10:44:02.000000000 +0000
+++ b/netlib.c 2017-01-12 04:45:51.605352327 +0000
@@ -70,6 +70,9 @@
#ifdef HAVE_NETDB_H
#include <netdb.h>
#endif
+#include <arpa/nameser.h>
+#include <resolv.h>
+
#include "vtun.h"
#include "lib.h"
@@ -247,6 +250,13 @@
addr->sin_family = AF_INET;
addr->sin_port = htons(vtun.bind_addr.port);
+ /*
+ glibc will cache nameserver info forever
+ */
+ res_init();
+
+ vtun_syslog(LOG_INFO, "DNS resolution of: %s", vtun.svr_name);
+
/* Lookup server's IP address.
* We do it on every reconnect because server's IP
* address can be dynamic.
My email client may have made it unusable.
If I restart vtun server many units will all connect back. I'm using a
wrapper to ppp so this increases load.
1. Pick a random sleep time at start and use that.
This caused a problem with device setup because the first failure could
happen before we've negotiated link speed with the Cisco switch.
If someone was configuring 7 units to ship that situation added 21
minutes to staging. I changed it to do the random after first connect.
We got our 3 minutes back in config for each device.
2. These devices can be up for 24x7 365. Vtun is a persist client. It
would cache dns. TCP kernel tuning on the client with PPPD LCP options
will drop after 1 minute of failure. LCP_ECHO_INTERVAL is short to deal
with brain-dead NAT firewalls. If they move the server and change DNS
vtun would not have known. I force resolution at every connect attempt.
We originally used my VPN programs up till 2003 when I found VTUN. I've
been using it ever since. 14 years I'd say. The patches may not be the
correct way, but they address some of the issues I ran into. I've been
debating about a "ZEROCONF" pool where the units may not have correct
credentials, but get a P-t-P scheme for config. Sometimes people will
remove a database entry, but leave the device onsite. It will keep
trying. If I can grant it an address firewalled off I can turn vtun
off. I could also change the code to exit after 1000 attempts. Aprox.
3 days of non-stop attempts.
Let me know if I should post the patch on Dropbox.
Chris
------------------------------------------------------------------------
*Sent: *Thursday, January 26, 2017 10:54:56 AM
*Subject: *[Vtun-Users] Connection denied without explanation
Hello everybody
I'm seeking help into debuggig a strange situation
We 've got here a bunch of VTUN hosts and I've got a strange behavior
from certain computer
Server is using vtun 3.0.3
Client have vtun 3.0.2 (and some 2.6, but that's not the fact)
---------
options {
port 21; # Listen on this port.
# Path to various programs
ifconfig /sbin/ifconfig;
route /sbin/route;
}
# Default host options
default {
compress no; # Compression is off by default
speed 0; # By default maximum speed, NO shaping
}
# host A
hosta{
passwd passa;
type tun;
proto tcp;
encrypt oldblowfish128ecb;
keepalive no;
up {
program /usr/local/sbin/killtun "hosta 10.239.3.4 %d" wait;
ifconfig "%% 10.239.3.3 pointopoint 10.239.3.4 mtu 1350";
};
}
# host b
hostb{
passwd passb;
type tun;
proto tcp;
encrypt oldblowfish128ecb;
keepalive no;
up {
program /usr/local/sbin/killtun "hostb 10.239.3.6 %d" wait;
ifconfig "%% 10.239.3.5 pointopoint 10.239.3.6 mtu 1350";
};
}
------------
On the client side
-----
options {
port 21;
timeout 60;
ifconfig /sbin/ifconfig;
route /sbin/route;
firewall /sbin/iptables;
}
hosta {
passwd passa;
device tun0;
up {
ifconfig "%% 10.239.3.4 pointopoint 10.239.3.3 mtu 1000";
};
}
------------
And same thing for host B (hostb, passb and IP changed of course)
Host B connect flawlessly
Host A just has in syslog a "connection denied by <server IP>"
On the server side in syslog "connection denied from <Client IP>"
The configs are identical, the systems are identical, the versions are
identical
That's not a firewall problem, tcpdump show connection on both sides
How is it possible ? How can I have a bit more information on the deny
reason ?
TIA for your help
Sincerly
Laurent COOPER
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Vtun-Users mailing list
https://lists.sourceforge.net/lists/listinfo/vtun-users