vtun-users — General VTun questions

[Vtun-Users] 3.0.4.1 UDP tun not timing out on client side

[Jean-Philippe L. <jp...@ss...>]

I have been testing 3.0.4.1 for the past few weeks, upgrading from 3.0.3.

I quickly noticed that if the internet line goes down, the client side 
does not notice the tunnel is dead and never tries to reconnect to the 
server. I have rolled back to 3.0.3 and the behavior is not happening.

If anyone has any idea or tests I could do on 3.0.4.1, let me know and I 
will be glad to help.

I have these options on the client
   keepalive yes;
   persist yes;

and on the server:
   keepalive yes;
   multi killold;

With 3.0.3, this is the log I see appearing when the connection is 
detected dead:
vtund[31296]: Session zz-zza network timeout

This message does not appear in 3.0.4.1 and the process stays up idle 
with a dead tunnel on the client side


Jean-Philippe

Re: [Vtun-Users] fedora26 error 4 in libcrypto.so.1.1.0f

[Dean D. <dea...@wi...>]

All good Sorted.

 

Patched in fedora 27.   Patch now in fedora 26 updates-testing and being
pushed to main repo for fedora 26.

 

Thanks you 

Dean

 

 

 

 

From: Dean Davis [mailto:dea...@wi...] 
Sent: Tuesday, 31 October 2017 7:05 PM
To: vtu...@li...
Subject: [Vtun-Users] fedora26 error 4 in libcrypto.so.1.1.0f

 

Fresh install of fedora26 using dnf to install vtun crashes 

 

Oct 31 20:36:31 vtund[8787]: VTun client ver 3.X 09/02/2017 started

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]:
Connecting to XXXXXXXXXXXX

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]: Remote
Server sends <UuKE1>

                                                         .

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]:
Session XXXXXXX[XXXXXXXXXX] opened

Oct 31 20:36:31 systemd-udevd[8788]: link_config: autonegotiation is unset
or enabled, the speed and duplex are not writable.

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7156] manager:
(tun6): new Tun device (/org/freedesktop/NetworkManager/Devices/7)

Oct 31 20:36:31 vtund[8787]: XXXXXX connecting to XXXXXXXXXXX[8787]: UDP
connection initialized

Oct 31 20:36:31 vtund[8787]: XXXXXXX tun tun6[8787]: Blowfish-128-ECB
encryption initialized

Oct 31 20:36:31 audit[8787]: ANOM_ABEND auid=0 uid=0 gid=0 ses=1 pid=8787
comm="vtund" exe="/usr/sbin/vtund" sig=11 res=1

Oct 31 20:36:31 kernel: vtund[8787]: segfault at 70 ip 00007fa6b63142c0 sp
00007ffd8e0e1c38 error 4 in libcrypto.so.1.1.0f[7fa6b61c7000+25f000]

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7549] device
(tun6): state change: unmanaged -> unavailable (reason 'connection-assumed',
internal state 'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7569] keyfile: add
connection in-memory (bccc6b26-d88a-4b8e-aad6-f8f3bf2dd43c,"tun6")

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7577] device
(tun6): state change: unavailable -> disconnected (reason
'connection-assumed', internal state 'external')

Oct 31 20:36:31 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=systemd-coredump@3-8793-0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:31 systemd[1]: Started Process Core Dump (PID 8793/UID 0).

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7591] device
(tun6): Activation: starting connection 'tun6'
(bccc6b26-d88a-4b8e-aad6-f8f3bf2dd43c)

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7596] device
(tun6): state change: disconnected -> prepare (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7604] device
(tun6): state change: prepare -> config (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7607] device
(tun6): state change: config -> ip-config (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7612] device
(tun6): state change: ip-config -> ip-check (reason 'none', internal state
'external')

Oct 31 20:36:31 dbus-daemon[706]: [system] Activating via systemd: service
name='org.freedesktop.nm_dispatcher'
unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.3' (uid=0
pid=766 comm="/usr/sbin/NetworkManager --no-daemon ")

Oct 31 20:36:31 systemd[1]: Starting Network Manager Script Dispatcher
Service...

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7669] device
(tun6): state change: ip-check -> unmanaged (reason 'unmanaged', internal
state 'removed')

Oct 31 20:36:31 dbus-daemon[706]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'

Oct 31 20:36:31 systemd[1]: Started Network Manager Script Dispatcher
Service.

Oct 31 20:36:31 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:31 nm-dispatcher[8797]: req:1 'pre-up' [tun6]: new request (1
scripts)

Oct 31 20:36:31 systemd-coredump[8796]: Process 8787 (vtund) of user 0
dumped core.

 

                                                                    Stack
trace of thread 8787:

                                                                    #0
0x00007fa6b63142c0 EVP_CIPHER_CTX_test_flags (libcrypto.so.1.1)

                                                                    #1
0x00007fa6b63122b7 EVP_EncryptUpdate (libcrypto.so.1.1)

                                                                    #2
0x000055a040f1ae8c encrypt_buf (vtund)

                                                                    #3
0x000055a040f19c9d linkfd (vtund)

                                                                    #4
0x000055a040f1783b tunnel (vtund)

                                                                    #5
0x000055a040f15c06 client (vtund)

                                                                    #6
0x000055a040f11f88 main (vtund)

                                                                    #7
0x00007fa6b5e1288a __libc_start_main (libc.so.6)

                                                                    #8
0x000055a040f1205a _start (vtund)

Oct 31 20:36:31 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=systemd-coredump@3-8793-0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:32 abrt-server[8807]: Deleting problem directory
ccpp-2017-10-31-20:36:31.847623-8787 (dup of
ccpp-2017-10-31-16:03:22.1189-740)

Oct 31 20:36:32 dbus-daemon[706]: [system] Activating service
name='org.freedesktop.problems' requested by ':1.42' (uid=0 pid=8847
comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v") (using
servicehelper)

Oct 31 20:36:32 dbus-daemon[706]: [system] Successfully activated service
'org.freedesktop.problems'

Oct 31 20:36:32 abrt-notification[8853]: Process 2359 (vtund) crashed in
??()

 

If I try to install from source get 

make: *** [Makefile:59: lfd_encrypt.o] Error 1

 

above my knowledge, can anyone help ?

[Vtun-Users] fedora26 error 4 in libcrypto.so.1.1.0f

[Dean D. <dea...@wi...>]

Fresh install of fedora26 using dnf to install vtun crashes 

 

Oct 31 20:36:31 vtund[8787]: VTun client ver 3.X 09/02/2017 started

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]:
Connecting to XXXXXXXXXXXX

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]: Remote
Server sends <UuKE1>

                                                         .

Oct 31 20:36:31 vtund[8787]: XXXXXXX connecting to XXXXXXXXXXX[8787]:
Session XXXXXXX[XXXXXXXXXX] opened

Oct 31 20:36:31 systemd-udevd[8788]: link_config: autonegotiation is unset
or enabled, the speed and duplex are not writable.

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7156] manager:
(tun6): new Tun device (/org/freedesktop/NetworkManager/Devices/7)

Oct 31 20:36:31 vtund[8787]: XXXXXX connecting to XXXXXXXXXXX[8787]: UDP
connection initialized

Oct 31 20:36:31 vtund[8787]: XXXXXXX tun tun6[8787]: Blowfish-128-ECB
encryption initialized

Oct 31 20:36:31 audit[8787]: ANOM_ABEND auid=0 uid=0 gid=0 ses=1 pid=8787
comm="vtund" exe="/usr/sbin/vtund" sig=11 res=1

Oct 31 20:36:31 kernel: vtund[8787]: segfault at 70 ip 00007fa6b63142c0 sp
00007ffd8e0e1c38 error 4 in libcrypto.so.1.1.0f[7fa6b61c7000+25f000]

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7549] device
(tun6): state change: unmanaged -> unavailable (reason 'connection-assumed',
internal state 'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7569] keyfile: add
connection in-memory (bccc6b26-d88a-4b8e-aad6-f8f3bf2dd43c,"tun6")

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7577] device
(tun6): state change: unavailable -> disconnected (reason
'connection-assumed', internal state 'external')

Oct 31 20:36:31 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=systemd-coredump@3-8793-0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:31 systemd[1]: Started Process Core Dump (PID 8793/UID 0).

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7591] device
(tun6): Activation: starting connection 'tun6'
(bccc6b26-d88a-4b8e-aad6-f8f3bf2dd43c)

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7596] device
(tun6): state change: disconnected -> prepare (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7604] device
(tun6): state change: prepare -> config (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7607] device
(tun6): state change: config -> ip-config (reason 'none', internal state
'external')

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7612] device
(tun6): state change: ip-config -> ip-check (reason 'none', internal state
'external')

Oct 31 20:36:31 dbus-daemon[706]: [system] Activating via systemd: service
name='org.freedesktop.nm_dispatcher'
unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.3' (uid=0
pid=766 comm="/usr/sbin/NetworkManager --no-daemon ")

Oct 31 20:36:31 systemd[1]: Starting Network Manager Script Dispatcher
Service...

Oct 31 20:36:31 NetworkManager[766]: <info>  [1509442591.7669] device
(tun6): state change: ip-check -> unmanaged (reason 'unmanaged', internal
state 'removed')

Oct 31 20:36:31 dbus-daemon[706]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'

Oct 31 20:36:31 systemd[1]: Started Network Manager Script Dispatcher
Service.

Oct 31 20:36:31 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:31 nm-dispatcher[8797]: req:1 'pre-up' [tun6]: new request (1
scripts)

Oct 31 20:36:31 systemd-coredump[8796]: Process 8787 (vtund) of user 0
dumped core.

 

                                                                    Stack
trace of thread 8787:

                                                                    #0
0x00007fa6b63142c0 EVP_CIPHER_CTX_test_flags (libcrypto.so.1.1)

                                                                    #1
0x00007fa6b63122b7 EVP_EncryptUpdate (libcrypto.so.1.1)

                                                                    #2
0x000055a040f1ae8c encrypt_buf (vtund)

                                                                    #3
0x000055a040f19c9d linkfd (vtund)

                                                                    #4
0x000055a040f1783b tunnel (vtund)

                                                                    #5
0x000055a040f15c06 client (vtund)

                                                                    #6
0x000055a040f11f88 main (vtund)

                                                                    #7
0x00007fa6b5e1288a __libc_start_main (libc.so.6)

                                                                    #8
0x000055a040f1205a _start (vtund)

Oct 31 20:36:31 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 msg='unit=systemd-coredump@3-8793-0 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Oct 31 20:36:32 abrt-server[8807]: Deleting problem directory
ccpp-2017-10-31-20:36:31.847623-8787 (dup of
ccpp-2017-10-31-16:03:22.1189-740)

Oct 31 20:36:32 dbus-daemon[706]: [system] Activating service
name='org.freedesktop.problems' requested by ':1.42' (uid=0 pid=8847
comm="/usr/bin/python3 /usr/bin/abrt-action-notify -d /v") (using
servicehelper)

Oct 31 20:36:32 dbus-daemon[706]: [system] Successfully activated service
'org.freedesktop.problems'

Oct 31 20:36:32 abrt-notification[8853]: Process 2359 (vtund) crashed in
??()

 

If I try to install from source get 

make: *** [Makefile:59: lfd_encrypt.o] Error 1

 

above my knowledge, can anyone help ?

Re: [Vtun-Users] Connection denied without explanation

[Laurent C. <lau...@ac...>]

Hello

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
port 21 because we do not know how some firewalls are managed for our
clients.

Usually port 21 is open.

But

One of the ISP our client is using seems to have a ftp proxy to save
bandwith. Transparent ftp proxy on port 21. Bad. Bad bad thing. It could
be interpreted as a MIM attack, and it's barely legal here in France !

Using another port saved the thing

Anyway, the point is that vtun is really laconic about the reason he
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.

Laurent

Le 27/01/2017 à 00:02, Chris Fowler a écrit :
> DPI 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 @@
> case ST_HOST:
> 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
> 
>  
> 
> ------------------------------------------------------------------------
> 
>     *From: *"Laurent COOPER" <lau...@ac...>
>     *To: *vtu...@li...
>     *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)
> 
>     Server config :
> 
>     ---------
> 
>     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
>     Vtu...@li...
>     https://lists.sourceforge.net/lists/listinfo/vtun-users
> 

Re: [Vtun-Users] Connection denied without explanation

[Chris F. <cf...@ou...>]

DPI 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 @@ 
case ST_HOST: 
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 

> From: "Laurent COOPER" <lau...@ac...>
> To: vtu...@li...
> 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)

> Server config :

> ---------

> 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
> Vtu...@li...
> https://lists.sourceforge.net/lists/listinfo/vtun-users

[Vtun-Users] Connection denied without explanation

[Laurent C. <lau...@ac...>]

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)

Server config :

---------

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

[Vtun-Users] Connection denied without explanation

[Laurent C. <lau...@ac...>]

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)

Server config :

---------

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

Re: [Vtun-Users] Android client for vtun

[bishop <bi...@pl...>]

[bounced to the proper list]

Vladimir,

I haven't seen a client built for Android yet, and I think there's no
cross set up to build one.  Have you found a third-party build that works?

 - bish

Vladimir Stankovic wrote:
> Hi, 
> 
> What would be the best practices for configuring vtun client on Android
> mobile phone? 
> 
> I haven't found official support or documentation that would provide
> more details.
> 
> Kind Regards,
> Vladimir Stankovic
> 

[Vtun-Users] Nudging VTun into a spammy loop with a well-timed SigHUP (bug58, patch24)

[bishop <bi...@pl...>]

Hey Folks,

Gabe Somlo alerted me to a patch for a suspected bug, relabeled as a
security issue.

[1] http://osdir.com/ml/fedora-package-announce/2016-04/msg00410.html

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1319858
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1319859
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1319860
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1319861

They all stem from this report:
[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818489

which also is repeated here:
[7] http://seclists.org/oss-sec/2016/q2/157

but rejected here:
[8] http://seclists.org/oss-sec/2016/q2/173

When it comes down to it, and since I worry the Debian package has a few
patches that aren't reflected/sent upstream, I'm not sure it's not just
affecting them.

[9] https://sourceforge.net/p/vtun/patches/24/
[10] https://sourceforge.net/p/vtun/bugs/58/

So.  I'd like to get a feel for it.  Are you able to provoke the issue
as mentioned in [6]?  I'm not seeing anything like 'this is the log
messages' or 'this is how I can provoke it', so I'm lost a little here.
 I'd like to confirm it affects Upstream before the patches are bought
in; especially if they can affect host->persist behaviour.

Roland?  Do you have anything on debian's bug tracker there that I'm not
seeing and which can help show what's up?

Thanks
 - bish
   janitor and fishmonger

[Vtun-Users] Best ppp options

[Chris F. <cf...@ou...>]

Hello, 

I've been dealing with a buggy link for a few days and I'm now looking at my ppp command line options. 

ICMP across the tunnel works fine. Any large burst of traffic kills it. On the wire I'm see TCP retransmissions. I am 99% sure this s a problem one the site's edge. I'm looking at my options to see if I can fix this without looking at their equipment. 

1. compression disabled 
2. Vtun 3.0.1 
3. Protocol is TCP 
4. All endpoints are on private nets behind firewalls. Port 5000 is NAT'ed to the vtun server. Endpoint firewalls allow TCP outbound. 
5. On successful auth ppp is executed with the following options on client. 

/sbin/pppd noipdefault nomagic lcp-echo-interval 30 lcp-echo-failure 2 lock unit 100 

Why lcp? 12 years ago we discovered what I all dumb NAT firewalls. The amount of traffic on these links can be so low that 60s could pass with not one IP packet traversing the tunnel. Firewalls would assume the connection is "dead", remove from their list, and then we had to wait for the 2 hour timeout to hit. We can also add keepalive to the config. 

These tunnels need to be up 24/7 so the kernel is tuned to hit KA every 5 minutes. Those LCP options will kill pppd in 60s. Lowering the lcp-echo-interval to 20 would increase traffic. 

Using tun on my tunnel is not really possible with this setup. It is a complex config, 100s are connected, and everything is database driven. No mods to vtun. Only config creation, pppd start, etc. 

If I SSH to the device inside the tunnel and execute 'dmesg' the output burst terminates tunnel. I use trickle -u 20 -d 20 -t 0.1 ssh to assist. On the remote I have to throttle its traffic so I have a program I run output through to slow it down. 0.02s/char, Yes, it sucks, and this is just temp so I can fix this. 

One option is to add speed to the config of each tunnel and throttle this one down. See if that works. Speed is ignored on the client. will it attampt to burst and the server throttle? If so I may need to start vtun on the remote with trickle. 

To explain complexity, 

1. vtund on server accept()s connection and does auth. 
2. Instead of pppd it executes program. 
3. Program creates command line for real pppd. Executes it on pseduo 
4. ip-up/ip-down are called once ip is up on pppd. 
5. Those programs look in database for routes. 
6. If routes are found the apply them. 
7. ip-up/ip-down can actually down another ppp interface with same address. 
That interface could be a demand mode ppp interface attached to modem. 

Yep, do a ping and kill the network. Ping will pause and then start back, but latency has grown. This is not used often. 

This is where using ppp in vtun works very well. 

Thanks, 
Chris 

[Vtun-Users] vtun and pppd do not detect lost connection at the same time

[Pascal H. <har...@ya...>]

  When pppd detects that the link is down, it closes the pppdsession but vtun takes 2 hours to detect that the link is down and that pppd isclosed before to close session.The « timeout » parameter has been set to« 30 »

[Vtun-Users] VTun /var/lock with Systemd and EL7

[bishop <bi...@pl...>]

Hey Folks,

I have a newer enterprise linux box, and it's been inflicted with the 
systemd plague of creeping kludge; and /var/lock is now volatile.

I noticed the following was required after rpmbuild -ta'ing the vtun 303 
tarball:

# cat <<EOF> /etc/tmpfiles.d/vtund.conf
d /run/lock/vtund 0755 root root -
EOF

# systemd-tmpfiles --create

.. and that should allow the lock dir to exist; maybe even over reboots. 
  If your box has

I'll see about opening a bug so's it can get into a release.  Other than 
that little tune-up, the 303 tarball seems to build only with minor griping.


-- 
  - bish

p.s.:  Relevant log bits

Oct 20 13:29:03 ghostyghost vtund[s]: authentication[5986]: Can't create 
temp lock file /var/lock/vtund/me2you

[root@ghostyghost ~]# ls -l /var/lock/vtund/
[root@ghostyghost ~]# rpm -V !$
rpm -V vtun
S.5....T.  c /etc/vtund.conf
missing     /var/lock/vtund

[root@ghostyghost ~]# df /var/lock
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs            3941272  8592   3932680   1% /run

Re: [Vtun-Users] Application with high number of TCP connections over VTUN

[Michael R. <mic...@rs...>]

As i know, as long your VPN-Gateway is not a NAT-Router the number of
simultaneous TCP-Connections is insignificant.

vTUN only creates a TUN/TAP Device and configure the parameters for this
device as needed.

vTUN can also encrypt and compress your traffic and do some traffic shaping.
If all these options are disabled, you can reach high bandwidth like a
charm.
We are pushing real 100 MBits via ARM-Hardware.

If your VPN-Gateway is a NAT-Router, the used VPN-Mechanisms does not
impact the speed / simultaneous TCP connections. It belongs to your CPU,
RAM and Kernel because the kernel have to build NAT-Sessions for each
TCP-Connection and each forwarded packet have to be routed trough a
hash-table (NAT-Table).

With two static IP-Addresses i suggest to use GRE / IPIP because this
protocols have lower overhead.
If you have one static and one dynamic or both dynamic ip-addresses, so you
have no other choice and have to use OpenVPN, vTUN, PPP.


Liebe Grüße aus Freilassing,

*Michael Rack*
RSM Freilassing
-- 
RSM Freilassing                 Tel.: +49 8654 607110
Nocksteinstr. 13                Fax.: +49 8654 670438
D-83395 Freilassing            www.rsm-freilassing.de


2014-03-12 2:17 GMT+01:00 Guido Sanchez <gui...@gm...>:

> Hi,
>
>     I use an application that uses a high number of simultaneous TCP
> connections (over 16,000) over a tunnel to hide the source IP of the
> traffic. I was using GRE or IPIP but I want to start using VTUN for this
> since I don't have such modules enabled on my new environment. I tried
> openvpn but it didn't work quite well and I was wondering if I can set
> up vtun to do this and if there's any limitation or configuration that I
> should be aware of.
>    It's not much traffic in bandwidth (usually 30Mbps) but like I said
> it's a lot of connections at the same time. If I could preserve a good
> part of the bw that would be good too. I don't need encryption or
> compression.
>
> Thanks,
> Guido.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Vtun-Users mailing list
> Vtu...@li...
> https://lists.sourceforge.net/lists/listinfo/vtun-users
>

[Vtun-Users] Application with high number of TCP connections over VTUN

[Guido S. <gui...@gm...>]

Hi,

    I use an application that uses a high number of simultaneous TCP 
connections (over 16,000) over a tunnel to hide the source IP of the 
traffic. I was using GRE or IPIP but I want to start using VTUN for this 
since I don't have such modules enabled on my new environment. I tried 
openvpn but it didn't work quite well and I was wondering if I can set 
up vtun to do this and if there's any limitation or configuration that I 
should be aware of.
   It's not much traffic in bandwidth (usually 30Mbps) but like I said 
it's a lot of connections at the same time. If I could preserve a good 
part of the bw that would be good too. I don't need encryption or 
compression.

Thanks,
Guido.

Re: [Vtun-Users] Pseudo terminal problems under CentOS 6

[bishop <bi...@pl...>]

Hey Max,

You can create a ticket in SF, as long as you have a SF ID.

But I see an old patch was recommended for 300, but it didn't land until
303 was considered; and it's bogus for 303.  You may want to see if it
refactors for 303 and we can see if it lands in 304.

http://sourceforge.net/p/vtun/bugs/_discuss/thread/9ef7c052/0dc5/attachment/vtun-3.0.1_pts.patch

It's not a configure patch;  it's a source patch to handle the loss of
legacy PTYs in newer kernel builds.  " all I needed was to add the
PTS_XXXXXX defines," Christophe says, "and then vtun started using
/dev/pts instead of /dev/ttypX."  It sounds almost similar to what I
think you may be seeing, but it does it differently.  I'm worried that I
don't see the mentioned defines anywhere, and maybe it also needs the
configure fix.

Here's the bug it refers to, at least:
http://sourceforge.net/support/tracker.php?aid=1692526

If you don't think this patch avoids your issue, just file a new one.

 - bish



Iron Max wrote:
> 
> Bish,
> 
>     I elect you!  ;-)
> 
> Well actually I would have suggested a fix if I understood how the
> config system works ... it is one of those things I have never got my
> head around. On the other hand I *could* potentially have written some
> code that would detect /dev/pts/ (or not) and used dload() to
> dynamically load the grant() etc. routines as necessary - this might
> make the executable more portable ... however, this then would require
> dload() detection by the config system, so the we wouid be back to
> finding someone to change configure :-)
> 
>     Seriously, do we have a ticket for this one yet?  This one sounds a
>     little familiar.  If not, can you log one?
> 
> Ummm, are you asking me to create a ticket? ... I have never looked into
> doing so for this project, am I even allowed to? Do we have a volunteer?
> Pretty please (or tell me what to do, sigh).
> 
> Max
> 
> 
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Vtun-Users mailing list
> Vtu...@li...
> https://lists.sourceforge.net/lists/listinfo/vtun-users
> 

Re: [Vtun-Users] Pseudo terminal problems under CentOS 6

[Iron M. <ye_...@ya...>]

Bish,

I elect you!  ;-)
>Well actually I would have suggested a fix if I understood how the config system works ... it is one of those things I have never got my head around. On the other hand I *could* potentially have written some code that would detect /dev/pts/ (or not) and used dload() to dynamically load the grant() etc. routines as necessary - this might make the executable more portable ... however, this then would require dload() detection by the config system, so the we wouid be back to finding someone to change configure :-)


Seriously, do we have a ticket for this one yet?  This one sounds a
>little familiar.  If not, can you log one?
>Ummm, are you asking me to create a ticket? ... I have never looked into doing so for this project, am I even allowed to? Do we have a volunteer? Pretty please (or tell me what to do, sigh).

Max

Re: [Vtun-Users] Pseudo terminal problems under CentOS 6

[bishop <bi...@pl...>]

Hey Max,

I elect you!  ;-)

Seriously, do we have a ticket for this one yet?  This one sounds a
little familiar.  If not, can you log one?

 - bish



Iron Max wrote:
> 
> OK, so this is a real problem ... is there someone who can fix the
> 'configure' so that config.h gets the correct defines?
> 
> Given that the sourceforge downloads page contains an ".el6." RPM which
> is not configured correctly for el6 this is something that I believe
> should be sorted out (I assume el6 in this case is designed for
> Redhat/CentOS 6.x).
> 
>     ------------------------------------------------------------------------
>     *From:* Chris Fowler <cf...@ou...>
>     **...
>     I've had this problem on 3.X since I began using that version.  I
>     automatically now modify pty_dev.c and replace that define HAV* with
>     a 1. 
> 

Re: [Vtun-Users] Pseudo terminal problems under CentOS 6

[Iron M. <ye_...@ya...>]

OK, so this is a real problem ... is there someone who can fix the 'configure' so that config.h gets the correct defines?

Given that the sourceforge downloads page contains an ".el6." RPM which is not configured correctly for el6 this is something that I believe should be sorted out (I assume el6 in this case is designed for Redhat/CentOS 6.x).


>________________________________
> From: Chris Fowler <cf...@ou...>
>...
>I've had this problem on 3.X since I began using that version.  I
    automatically now modify pty_dev.c and replace that define HAV* with
    a 1.  
>

Re: [Vtun-Users] Pseudo terminal problems under CentOS 6

[Chris F. <cf...@ou...>]

On 02/04/2014 11:11 PM, Iron Max wrote:
>
> I could be wrong, but it appears that the configuration time detection 
> of how to access pseudo terminals is broken, at least for CentOS 6. I 
> noticed this when testing vtun-3.0.3-1.el6.x86_64.rpm (from the vtun 
> download page) ... things where failing because vtun was trying to 
> access "/dev/ptyXY" devices, rather than using 
> getpt()/grantpt()/unlockpt()/ptsname(). CentOS 6 does not have 
> "/dev/ptyXY" devices, but I could get CentOS 6 happily using 
> getpt()/grantpt()/unlockpt()/ptsname() to return "/dev/pts/XY" names.

I've had this problem on 3.X since I began using that version.  I 
automatically now modify pty_dev.c and replace that define HAV* with a 1.

Chris

[Vtun-Users] Pseudo terminal problems under CentOS 6

[Iron M. <ye_...@ya...>]

I could be wrong, but it appears that the configuration time detection of how to access pseudo terminals is broken, at least for CentOS 6. I noticed this when testing vtun-3.0.3-1.el6.x86_64.rpm (from the vtun download page) ... things where failing because vtun was trying to access "/dev/ptyXY" devices, rather than using getpt()/grantpt()/unlockpt()/ptsname(). CentOS 6 does not have "/dev/ptyXY" devices, but I could get CentOS 6 happily using getpt()/grantpt()/unlockpt()/ptsname() to return "/dev/pts/XY" names.

[You can see this behaviour if you try to use the "sz" session that comes in the distribution's vtund.conf, a trace of the server session showing it trying to open "/dev/ptyp0" to "/dev/ptyzv"]

I pulled down the latest sources, vtun-3.0.3.tar.gz, and tried a ./configure, make, ... as far as I can see configure sees that getpt()/grantpt()/unlockpt()/ptsname() are available ...

>  # /configure
>  ...
>  checking for getpt... yes
>  checking for grantpt... yes
>  checking for unlockpt... yes
>  checking for ptsname... yes
>  ...
>  configure: creating ./config.status
>  config.status: creating Makefile
>  config.status: creating config.h

but config.h does not have HAVE_GETPT / HAVE_GRANTPT / HAVE_PTSNAME / HAVE_UNLOCKPT defined in it, nor do any other .h files ...

>  # egrep -r 'HAVE_GETPT|HAVE_GRANTPT|HAVE_UNLOCKPT|HAVE_PTSNAME' *.h

nothing is found.

However pty_dev.c / pty_open() needs all the 4 HAVE_* values defined before it will use getpt()/grantpt()/unlockpt()/ptsname() ...

>  ...
>  int pty_open(char *sl_name)
>  {
>      int  mr_fd;
>  #if defined (HAVE_GETPT) && defined (HAVE_GRANTPT) && defined (HAVE_UNLOCKPT) && defined (HAVE_PTSNAME)
>      char *ptyname;
>
>      if((mr_fd=getpt()) < 0)
>          return -1;
>  ...

The make/compile of pty_dev.c shows ...

>  gcc -g -O2  -I/usr/include/lzo -I/usr/include/openssl -I/usr/include/openssl -I/usr/include/openssl \
>              -I/usr/include/openssl -DVTUN_CONFIG_FILE=\"/usr/local/etc/vtund.conf\" \
>              -DVTUN_PID_FILE=\"/usr/local/var/run/vtund.pid\" -DVTUN_STAT_DIR=\"/usr/local/var/log/vtund\" \
>              -DVTUN_LOCK_DIR=\"/usr/local/var/lock/vtund\" \
>              -c pty_dev.c

so no -DHAVE_* are passed to the compile either.

config.log does have the defines ...

>  # egrep 'HAVE_GETPT|HAVE_GRANTPT|HAVE_UNLOCKPT|HAVE_PTSNAME' config.log
>  #define HAVE_GETPT 1
>  #define HAVE_GRANTPT 1
>  #define HAVE_PTSNAME 1
>  #define HAVE_UNLOCKPT 1

Am I misunderstanding how this should be working, or is there a bug?

For completeness, here is a test program using getpt()/grantpt()/unlockpt()/ptsname() that did work under CentOS 6.2 ...

>  #include <stdio.h>
>  #define _XOPEN_SOURCE
>  #define __USE_XOPEN
>  #include <stdlib.h>
>  
>  main()
>  {
>    int  mr_fd;
>    char *ptyname;
>  
>    if((mr_fd=getpt()) < 0)
>        return -1;
>    if(grantpt(mr_fd) != 0)
>        return -1;
>    if(unlockpt(mr_fd) != 0)
>        return -1;
>    if ((ptyname = (char *) ptsname(mr_fd)) == NULL)
>        return -1;
>    printf( "<%s>\n" , ptyname );
>    exit( 0 );
>  }

Max

[Vtun-Users] "Invalid argument (22)" when using blowfish256

[Matthias F. <txt...@tx...>]

Hey folks

I want to set up a tunnel and want to use blowfish256ofb as encryption.
Sadly I am running into an error.
When I set "encryption blowfish256ecb" the tunnel works fine. But with
all other block cipher modes I get "Invalid argument (22)". The error
occurs as soon as I transfer data through the tunnel. To test the tunnel
I use either iperf or ping. Both programs return the same result.

My server is a virtual server running on kvm with debian wheezy amd64
and the client is a Intel Atom notebook also on debian wheezy amd64.

cia txt.file

[Vtun-Users] stat collection file(s)

[CARTWRIGHT, C. C <cc...@at...>]

Hello,

Where can I find the header definitions for the statistics files?

Thanks,

[Vtun-Users] Reload VTUN config without restart?

[Adam R. <ar...@ra...>]

Hi All,

     i'm using VTUN as encrypted tunnel on the operator link, for some
reasons this is better for me than ipsec for example, now i'm using
bandwidth shaping via tunnel config:

speed xxxx;

now my operator changed speed of this link but i don't want to restart
vtund because many routes will need reconfiguration.

There is a method to reload/read new configuration without restart?

Pozdrawiam,
Adam Rybak

[Vtun-Users] Question about the term "L2 tunnel"

[Buiosu <dar...@wp...>]

Hello,
I'm trying to do my own review on layer 2 frames tunneling methods.
I've quite an issue due to my English skills or due to ambiguity between network architects, programmers etc. I mean, sometimes "layer 2 tunnel" refers to connect VPNs at layer 2, while sometimes it refers to connect remote sites along with their layer 2 - what allows to tunnel VLANs, too (or even other L2 protocols like Frame Relay).
I couldn't find so far any direct information in the mailing list archive nor the website, so could someone please confirm to me that VTUN allows to transport Ethernet/802.1Q?

Kind regards
Thomas

Re: [Vtun-Users] a couple of questions

[Joe P. <jo...@q7...>]

i was able to determine that the malloc function makes the buffer big 
enough to hold the length and then returns a pointer past that. it is 
scary to see the assignment in the proto functions, but at least it 
isn't a problem.

On 2013-05-16 09:23, Joe Pruett wrote:
> i didn't see this in the docs, but from a quick reading of the code, it
> would appear that udp tunnels don't do fragmentation. so if i am trying
> to bridge an ethernet, i should use tcp to avoid truncating packets, right?
>
> and also from looking at the code for the tcp and udp protos, i see that
> the packet size is being written into memory that is before the
> beginning of the buffer. looking at linkfd.c it doesn't look like the
> buffer being passed in is really designed for that. am i missing something?
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Vtun-Users mailing list
> Vtu...@li...
> https://lists.sourceforge.net/lists/listinfo/vtun-users
>