openvpn-devel — OpenVPN developers list

Re: Re[2]: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[James Y. <ji...@yo...>]

Richard Mueller <mu...@te...> said:

> Hello James,
> 
> Thursday, December 19, 2002, 3:59:16 PM, you wrote:
> 
> JY> * How is --peerinit different from --ipchange?
> Good question. None. sh*t Please see below. :)
> 
> JY> * Shouldn't
> JY>   if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
> JY>    ...
> JY> be
> JY>   if (signal_received == SIGUSR1 && options->sigusr1_script)
> JY>    ...
> JY> ?
> d*mn. yes. this is the sprit of "cut'n'paste" coding. Think I pasted
> the condition some lines above.
> 
> I wrote it short afer visiting "Lord of the Rings II" and a 18h
> workday without any coffee (I am allergic).

Hey, that's an interesting excuse...  Tolkien had a great sense of foreboding
about the advancing march of technology and industrialization and he would
probably have taken some pleasure in knowing that his storyweaving would throw
a wrench into the workings of someone's machinery...  not to mention being
under the influence of a lack of caffeine :)

> So sorry for the bad code, I won't do it again. ;-(
> I took the conclusion for me:
> $ patch && test && sleep && test && submit
> 
> 
> JY> The failover idea is interesting.
> It works quite good in my enviroment here (even better after fixing the
> patch ;) ).
> 
> - If openvpn is stopped on both sides, the alternative route is taken
>   immediateley.
> 
> - If the link between the two tun-endpoints breaks it takes as long
--ping-restart.
>   The prefered route is taken immediateley when the tunnel returns.

So it looks like all we need is a --sigusr1-script option.  That seems pretty
reasonable.  After you've tested it somewhat, would you mind writing an entry
for the HOWTO that explains how to use the ipchange and sigusr1 scripts to set
up a failover configuration?  Probably just a restatement of what you've
described in your emails, but maybe with a bit more detail such as how to set
up the Linux Advanced Routing component of the setup.  I think people would
find it very useful, and this is certainly a case where the code itself (i.e.
the script patch) is fairly trivial but the documentation on how to do it is
the far more essential component.

Thanks,
James

> 
> 
> Best regards and sorry again for the bad code,
> 
> Richard Mueller
> 



-- 

Re[2]: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[Richard M. <mu...@te...>]

Hello James,

Thursday, December 19, 2002, 3:59:16 PM, you wrote:

JY> * How is --peerinit different from --ipchange?
Good question. None. sh*t Please see below. :)

JY> * Shouldn't
JY>   if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
JY>    ...
JY> be
JY>   if (signal_received == SIGUSR1 && options->sigusr1_script)
JY>    ...
JY> ?
d*mn. yes. this is the sprit of "cut'n'paste" coding. Think I pasted
the condition some lines above.

I wrote it short afer visiting "Lord of the Rings II" and a 18h
workday without any coffee (I am allergic).
So sorry for the bad code, I won't do it again. ;-(
I took the conclusion for me:
$ patch && test && sleep && test && submit


JY> The failover idea is interesting.
It works quite good in my enviroment here (even better after fixing the
patch ;) ).

- If openvpn is stopped on both sides, the alternative route is taken
  immediateley.

- If the link between the two tun-endpoints breaks it takes as long --ping-restart.
  The prefered route is taken immediateley when the tunnel returns.


Best regards and sorry again for the bad code,

Richard Mueller

Re: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[James Y. <ji...@yo...>]

Hi Richard,

The failover idea is interesting.  I have a couple comments on the patch:

* How is --peerinit different from --ipchange?

* Shouldn't
  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
   ...
be
  if (signal_received == SIGUSR1 && options->sigusr1_script)
   ...
?

James

Richard Mueller <mu...@te...> said:

> Hello openvpn-developers,
> 
> I needed two more places in openvpn where to exec some scripts
> because I wanted to build a "fail-over" solution between two
> tuns.
> 
> 
> 1.) Situation:
>   +---------+       tun0 (ISP0)    +---------+
>   | BOX 1   +----------------------+ BOX 2   |
>   |         |                      |         |
>   |         +----------------------+         |
>   +---------+       tun1 (ISP1)    +---------+
> 
> tun0 is prefered but if tun0 fails tun1 should do
> the job.
> 
> Linux advanced routing has a usable solution for this:
>   Two routing tables with one prefered.
> 
> Because of this I needed to add/delete routes at this points:
> 
> - After the first "answer" from the peer (add route for tun?)
> - At a SIGUSR1 == "peer dead" (del route for tun?)
> 
> 
> 2.) I used following configs:
> 
> [BOX1: tun0]
> 
> # interface configuration
> dev tun0
> 
> # Peer connect configuartion
>  remote 172.16.90.4
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> # 10.255.253.8 is our local  VPN endpoint
> # 10.255.253.9 is our remote VPN endpoint
> ifconfig 10.255.254.122  10.255.254.121
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box1.crt
> key  /etc/openvpn/certs/box1.key
> tls-verify "/usr/local/sbin/verify-cn box2"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun0.up
> sigusr1  /etc/openvpn/scripts/tun0.down
> 
> lport 5006
> rport 5007
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX1: tun1]
> 
> # interface configuration
> dev tun1
> 
> # Peer connect configuartion
>  remote 172.16.90.4
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> # 10.255.253.8 is our local  VPN endpoint
> # 10.255.253.9 is our remote VPN endpoint
> ifconfig 10.255.253.122  10.255.253.121
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box1.crt
> key  /etc/openvpn/certs/box1.key
> tls-verify "/usr/local/sbin/verify-cn box2"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun1.up
> sigusr1  /etc/openvpn/scripts/tun1.down
> 
> lport 5506
> rport 5507
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX2: tun0]
> 
> # interface configuration
> dev tun0
> 
> # Peer connect configuartion
>  remote 172.16.90.1
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> ifconfig 10.255.254.121  10.255.254.122
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box2.crt
> key  /etc/openvpn/certs/box2.key
> tls-verify "/usr/local/sbin/verify-cn box1"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun0.up
> sigusr1  /etc/openvpn/scripts/tun0.down
> 
> lport 5007
> rport 5006
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX1: tun1]
> 
> # interface configuration
> dev tun1
> 
> # Peer connect configuartion
>  remote 172.16.90.1
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> ifconfig 10.255.253.121  10.255.253.122
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box2.crt
> key  /etc/openvpn/certs/box2.key
> tls-verify "/usr/local/sbin/verify-cn box1"
> 
> peerinit /etc/openvpn/scripts/tun1.up
> sigusr1  /etc/openvpn/scripts/tun1.down
> 
> lport 5507
> rport 5506
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> 4.) Here is the patch:
> 
> [PATCH START]
> diff -u openvpn-1.3.2/openvpn.c openvpn-1.3.2-droute/openvpn.c
> --- openvpn-1.3.2/openvpn.c     Mon Oct 21 03:46:52 2002
> +++ openvpn-1.3.2-droute/openvpn.c      Wed Dec 18 19:18:12 2002
> @@ -341,7 +341,7 @@
>                      options->local_port, options->remote_port,
>                      options->bind_local, options->remote_float,
>                      options->inetd,
> -                    udp_socket_addr, options->ipchange,
> +                    udp_socket_addr, options->ipchange,
options->peerinit_script,
>                      options->resolve_retry_seconds);
>  
>  #ifdef USE_CRYPTO
> @@ -1406,6 +1406,15 @@
>        run_script (options->down_script, tuntap_actual, MAX_RW_SIZE_TUN
(&frame),
>                   max_rw_size_udp, options->ifconfig_local,
options->ifconfig_remote);
>      }
> +   /*
> +    * Execute sigusr1 script 
> +    */
> +  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
> +    {
> +     msg (M_INFO, "Executing sigusr1 script %s",options->sigusr1_script);
> +     system_check (options->sigusr1_script, "sigusr1 command failed", false);
> +    }
> +
>   done:
>    /* pop our garbage collection level */
>    gc_free_level (gc_level);
> diff -u openvpn-1.3.2/options.c openvpn-1.3.2-droute/options.c
> --- openvpn-1.3.2/options.c     Sat Oct 19 23:26:11 2002
> +++ openvpn-1.3.2-droute/options.c      Wed Dec 18 18:52:24 2002
> @@ -316,6 +316,9 @@
>    SHOW_STR (writepid);
>    SHOW_STR (up_script);
>    SHOW_STR (down_script);
> +  SHOW_STR (peerinit_script);
> +  SHOW_STR (sigusr1_script);
> +  SHOW_STR (down_script);
>    SHOW_BOOL (daemon);
>    SHOW_BOOL (inetd);
>    SHOW_INT (nice);
> @@ -726,6 +729,16 @@
>      {
>        ++i;
>        options->down_script = p2;
> +    }
> +  else if (streq(p1, "peerinit") && p2) 
> +    {
> +      ++i;
> +      options->peerinit_script = p2;
> +    }
> +  else if (streq(p1, "sigusr1") && p2) 
> +    {
> +      ++i;
> +      options->sigusr1_script = p2;
>      }
>    else if (streq (p1, "daemon"))
>      {
> diff -u openvpn-1.3.2/options.h openvpn-1.3.2-droute/options.h
> --- openvpn-1.3.2/options.h     Sat Oct 19 22:25:46 2002
> +++ openvpn-1.3.2-droute/options.h      Wed Dec 18 18:25:46 2002
> @@ -87,6 +87,8 @@
>    const char *writepid;
>    const char *up_script;
>    const char *down_script;
> +  const char *peerinit_script;
> +  const char *sigusr1_script;
>    bool daemon;
>    bool inetd;
>    int nice;
> diff -u openvpn-1.3.2/socket.c openvpn-1.3.2-droute/socket.c
> --- openvpn-1.3.2/socket.c      Sat Oct 19 23:23:19 2002
> +++ openvpn-1.3.2-droute/socket.c       Wed Dec 18 18:56:18 2002
> @@ -105,6 +105,7 @@
>                  bool inetd,
>                  struct udp_socket_addr *usa,
>                  const char *ipchange_command,
> +                const char *peerinit_command,
>                  int resolve_retry_seconds)
>  {
>    CLEAR (*sock);
> @@ -112,6 +113,7 @@
>    sock->remote_float = remote_float;
>    sock->addr = usa;
>    sock->ipchange_command = ipchange_command;
> +  sock->peerinit_command = peerinit_command;
>  
>    /* were we started by inetd or xinetd? */
>    if (inetd)
> @@ -190,6 +192,22 @@
>           sock->set_outgoing_initial = true;
>           mutex_unlock (L_SOCK);
>           msg (M_INFO, "Peer Connection Initiated with %s", print_sockaddr
(&usa->actual));
> +
> +         if (sock->peerinit_command) 
> +           {
> +             char command[256];
> +             struct buffer out;
> +
> +             msg (M_INFO, "Executing peerinit_script
%s",sock->peerinit_command);
> +
> +             buf_set_write (&out, command, sizeof (command));
> +             buf_printf (&out, "%s %s",
> +                         sock->peerinit_command,
> +                         print_sockaddr_ex (&usa->actual, true, " "));
> +             msg (D_TLS_DEBUG, "executing ip-change command: %s", command);
> +             system_check (command, "peerinit command failed", false);
> +            }
> +
>           if (sock->ipchange_command)
>             {
>               char command[256];
> diff -u openvpn-1.3.2/socket.h openvpn-1.3.2-droute/socket.h
> --- openvpn-1.3.2/socket.h      Sat Oct 19 23:26:10 2002
> +++ openvpn-1.3.2-droute/socket.h       Wed Dec 18 18:49:01 2002
> @@ -42,6 +42,7 @@
>    bool remote_float;
>    struct udp_socket_addr *addr;
>    const char *ipchange_command;
> +  const char *peerinit_command;
>    int sd;                      /* file descriptor for socket */
>  };
>  
> @@ -56,6 +57,7 @@
>                  bool inetd,
>                  struct udp_socket_addr *addr,
>                  const char *ipchange_command,
> +                 const char *peerinit_command,
>                  int resolve_retry_seconds);
>  
>  void
> [PATCH START]
> 
> 5.) If it is interesting for you, James, you are free to clean the
>     code and fix the documentation and merge it in your branch.
>     Just write a Creditline in the changelog. ;-)
> 
> 6.) Feel free to ask, if you have some questions.
> 
> bye
> richard
> 
> -- 
> Richard Mueller     mailto:mu...@te...  Fon: +49 9171 896287
> Teamix GmbH         http://www.teamix.de       Fax: +49 9171 896286
> 
> PGP Public Key      http://www.teamix.net/pgp/rm_public_key_2048
> Fingerprint:        ea 50 21 6c a5 39 e9 03 a6 59 af e3 c5 1f 63 8e
> 
> Networks - Consulting - Training - Software Development - eCommerce
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
> MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
> T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[Richard M. <mu...@te...>]

Hello openvpn-developers,

I needed two more places in openvpn where to exec some scripts
because I wanted to build a "fail-over" solution between two
tuns.


1.) Situation:
  +---------+       tun0 (ISP0)    +---------+
  | BOX 1   +----------------------+ BOX 2   |
  |         |                      |         |
  |         +----------------------+         |
  +---------+       tun1 (ISP1)    +---------+

tun0 is prefered but if tun0 fails tun1 should do
the job.

Linux advanced routing has a usable solution for this:
  Two routing tables with one prefered.

Because of this I needed to add/delete routes at this points:

- After the first "answer" from the peer (add route for tun?)
- At a SIGUSR1 == "peer dead" (del route for tun?)


2.) I used following configs:

[BOX1: tun0]

# interface configuration
dev tun0

# Peer connect configuartion
 remote 172.16.90.4
# float

persist-tun
persist-key
ping 7
ping-restart 21

# 10.255.253.8 is our local  VPN endpoint
# 10.255.253.9 is our remote VPN endpoint
ifconfig 10.255.254.122  10.255.254.121

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box1.crt
key  /etc/openvpn/certs/box1.key
tls-verify "/usr/local/sbin/verify-cn box2"

# Routen setzen
peerinit /etc/openvpn/scripts/tun0.up
sigusr1  /etc/openvpn/scripts/tun0.down

lport 5006
rport 5007

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX1: tun1]

# interface configuration
dev tun1

# Peer connect configuartion
 remote 172.16.90.4
# float

persist-tun
persist-key
ping 7
ping-restart 21

# 10.255.253.8 is our local  VPN endpoint
# 10.255.253.9 is our remote VPN endpoint
ifconfig 10.255.253.122  10.255.253.121

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box1.crt
key  /etc/openvpn/certs/box1.key
tls-verify "/usr/local/sbin/verify-cn box2"

# Routen setzen
peerinit /etc/openvpn/scripts/tun1.up
sigusr1  /etc/openvpn/scripts/tun1.down

lport 5506
rport 5507

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX2: tun0]

# interface configuration
dev tun0

# Peer connect configuartion
 remote 172.16.90.1
# float

persist-tun
persist-key
ping 7
ping-restart 21

ifconfig 10.255.254.121  10.255.254.122

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box2.crt
key  /etc/openvpn/certs/box2.key
tls-verify "/usr/local/sbin/verify-cn box1"

# Routen setzen
peerinit /etc/openvpn/scripts/tun0.up
sigusr1  /etc/openvpn/scripts/tun0.down

lport 5007
rport 5006

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX1: tun1]

# interface configuration
dev tun1

# Peer connect configuartion
 remote 172.16.90.1
# float

persist-tun
persist-key
ping 7
ping-restart 21

ifconfig 10.255.253.121  10.255.253.122

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box2.crt
key  /etc/openvpn/certs/box2.key
tls-verify "/usr/local/sbin/verify-cn box1"

peerinit /etc/openvpn/scripts/tun1.up
sigusr1  /etc/openvpn/scripts/tun1.down

lport 5507
rport 5506

comp-lzo
#daemon

reneg-sec 600

verb 5

4.) Here is the patch:

[PATCH START]
diff -u openvpn-1.3.2/openvpn.c openvpn-1.3.2-droute/openvpn.c
--- openvpn-1.3.2/openvpn.c     Mon Oct 21 03:46:52 2002
+++ openvpn-1.3.2-droute/openvpn.c      Wed Dec 18 19:18:12 2002
@@ -341,7 +341,7 @@
                     options->local_port, options->remote_port,
                     options->bind_local, options->remote_float,
                     options->inetd,
-                    udp_socket_addr, options->ipchange,
+                    udp_socket_addr, options->ipchange, options->peerinit_script,
                     options->resolve_retry_seconds);
 
 #ifdef USE_CRYPTO
@@ -1406,6 +1406,15 @@
       run_script (options->down_script, tuntap_actual, MAX_RW_SIZE_TUN (&frame),
                  max_rw_size_udp, options->ifconfig_local, options->ifconfig_remote);
     }
+   /*
+    * Execute sigusr1 script 
+    */
+  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
+    {
+     msg (M_INFO, "Executing sigusr1 script %s",options->sigusr1_script);
+     system_check (options->sigusr1_script, "sigusr1 command failed", false);
+    }
+
  done:
   /* pop our garbage collection level */
   gc_free_level (gc_level);
diff -u openvpn-1.3.2/options.c openvpn-1.3.2-droute/options.c
--- openvpn-1.3.2/options.c     Sat Oct 19 23:26:11 2002
+++ openvpn-1.3.2-droute/options.c      Wed Dec 18 18:52:24 2002
@@ -316,6 +316,9 @@
   SHOW_STR (writepid);
   SHOW_STR (up_script);
   SHOW_STR (down_script);
+  SHOW_STR (peerinit_script);
+  SHOW_STR (sigusr1_script);
+  SHOW_STR (down_script);
   SHOW_BOOL (daemon);
   SHOW_BOOL (inetd);
   SHOW_INT (nice);
@@ -726,6 +729,16 @@
     {
       ++i;
       options->down_script = p2;
+    }
+  else if (streq(p1, "peerinit") && p2) 
+    {
+      ++i;
+      options->peerinit_script = p2;
+    }
+  else if (streq(p1, "sigusr1") && p2) 
+    {
+      ++i;
+      options->sigusr1_script = p2;
     }
   else if (streq (p1, "daemon"))
     {
diff -u openvpn-1.3.2/options.h openvpn-1.3.2-droute/options.h
--- openvpn-1.3.2/options.h     Sat Oct 19 22:25:46 2002
+++ openvpn-1.3.2-droute/options.h      Wed Dec 18 18:25:46 2002
@@ -87,6 +87,8 @@
   const char *writepid;
   const char *up_script;
   const char *down_script;
+  const char *peerinit_script;
+  const char *sigusr1_script;
   bool daemon;
   bool inetd;
   int nice;
diff -u openvpn-1.3.2/socket.c openvpn-1.3.2-droute/socket.c
--- openvpn-1.3.2/socket.c      Sat Oct 19 23:23:19 2002
+++ openvpn-1.3.2-droute/socket.c       Wed Dec 18 18:56:18 2002
@@ -105,6 +105,7 @@
                 bool inetd,
                 struct udp_socket_addr *usa,
                 const char *ipchange_command,
+                const char *peerinit_command,
                 int resolve_retry_seconds)
 {
   CLEAR (*sock);
@@ -112,6 +113,7 @@
   sock->remote_float = remote_float;
   sock->addr = usa;
   sock->ipchange_command = ipchange_command;
+  sock->peerinit_command = peerinit_command;
 
   /* were we started by inetd or xinetd? */
   if (inetd)
@@ -190,6 +192,22 @@
          sock->set_outgoing_initial = true;
          mutex_unlock (L_SOCK);
          msg (M_INFO, "Peer Connection Initiated with %s", print_sockaddr (&usa->actual));
+
+         if (sock->peerinit_command) 
+           {
+             char command[256];
+             struct buffer out;
+
+             msg (M_INFO, "Executing peerinit_script %s",sock->peerinit_command);
+
+             buf_set_write (&out, command, sizeof (command));
+             buf_printf (&out, "%s %s",
+                         sock->peerinit_command,
+                         print_sockaddr_ex (&usa->actual, true, " "));
+             msg (D_TLS_DEBUG, "executing ip-change command: %s", command);
+             system_check (command, "peerinit command failed", false);
+            }
+
          if (sock->ipchange_command)
            {
              char command[256];
diff -u openvpn-1.3.2/socket.h openvpn-1.3.2-droute/socket.h
--- openvpn-1.3.2/socket.h      Sat Oct 19 23:26:10 2002
+++ openvpn-1.3.2-droute/socket.h       Wed Dec 18 18:49:01 2002
@@ -42,6 +42,7 @@
   bool remote_float;
   struct udp_socket_addr *addr;
   const char *ipchange_command;
+  const char *peerinit_command;
   int sd;                      /* file descriptor for socket */
 };
 
@@ -56,6 +57,7 @@
                 bool inetd,
                 struct udp_socket_addr *addr,
                 const char *ipchange_command,
+                 const char *peerinit_command,
                 int resolve_retry_seconds);
 
 void
[PATCH START]

5.) If it is interesting for you, James, you are free to clean the
    code and fix the documentation and merge it in your branch.
    Just write a Creditline in the changelog. ;-)

6.) Feel free to ask, if you have some questions.

bye
richard

-- 
Richard Mueller     mailto:mu...@te...  Fon: +49 9171 896287
Teamix GmbH         http://www.teamix.de       Fax: +49 9171 896286

PGP Public Key      http://www.teamix.net/pgp/rm_public_key_2048
Fingerprint:        ea 50 21 6c a5 39 e9 03 a6 59 af e3 c5 1f 63 8e

Networks - Consulting - Training - Software Development - eCommerce

[Openvpn-devel] Re: Multiple VPN connections on the same port

[<ccm...@ne...>]

Hi,

I am interested to know what is the update/status one above.
I see email thread  as:

Hi Sampo,
                                  
                                  > I have been busy writing a forking server
                                  > addon to openvpn.
                                  
                                  Cool... Does each potential connecting client need a separate config file,
                                  or does the server use a common client template and then keep track of
                                  things like dynamic ports, dynamic endpoint addresses, etc?
                                  
                                  > In openvpn.c I have separated the processing of
                                  > parameters from main() to a new function and
                                  > moved main to another file to allow me to
                                  > link against different main() functions.
                                  >
                                  > One that implements normal peer2peer vpn
                                  > and two others that produces forkin' server
                                  > and client.
                                  >
                                  > These use a simple UDP protocol to agree a
                                  > port to use, after which server forks do
                                  > some handshaking with client and then
                                  > calls openvpn() funcition from openvpn.c
                                  
                                  Are you sure there needs to be a new protocol to do this?
                                  
                                  Suppose the master server listens on a particular port, reads the initial
                                  datagram from a connecting client, verifies the integrity of the datagram
                                  using a --tls-auth variant, allocates a dynamic port, forks a new server
                                  process, and continues in its event loop.
                                  
                                  When the forked process finishes up the TLS authentication, it can take the
                                  Common Name from the client certificate and use it to determine the
                                  appropriate config profile to use (containing ifconfig addresses, route
                                  statements, etc.)
                                  
                                  Or the handshaking could be done by passing a configuration string in the
                                  TLS payload, similar to the string now built by options_string().
                                  
                                  > This way I have been able to keep
                                  > those well tested procedures and protocol
                                  > of openvpn untouched.
                                  >
                                  > I still have some questions unsolved like
                                  > DoS protection, dropping root priviledges
                                  > and how to handel SIGUSR1 and SIGHUP.
                                  
                                  Maybe keep track of all children, so when the master process gets a signal,
                                  it dispatches it to each child process, then to itself.
                                  
                                  > I hope I can overcome these and mail
                                  > you a patch.
                                  >
                                  >
                                  >
                                  >
                                  > Sampo
                                  >
                                  >
                                  >
                                  > > Hi Michael,
                                  > >
                                  > > Right now OpenVPN doesn't support a forking-server model on a single
                                  port,
                                  > > it's strictly peer-to-peer with an OpenVPN process instantiated at both
                                  ends
                                  > > of the connection, and each connection on a unique port.
                                  > >
                                  > > There has been some recent discussions about a forking-server
                                  implementation
                                  > > on this list -- see the "add a server feature to openvpn to share udp
                                  > > ports?" thread in the openvpn-devel archives.
                                  > >
                                  > > I think the simplest way to do this would be something like:
                                  > >
                                  > > (1) Add a --forking-server flag that causes the main OpenVPN event loop
                                  to
                                  > > fork a new process for each initial datagram received from a client.
                                  > > (2) The newly forked server process switches to a dynamic port before
                                  > > responding back to the connecting client.  This is quite a bit simpler
                                  and
                                  > > more efficient than trying to run all clients over the same UDP port.
                                  > > (3) OpenVPN already has code (see the implementation of --float) that
                                  will
                                  > > adapt to the new port number returned by the response to initial
                                  datagram
                                  > > sent from server to client.  I have also confirmed that this type of UDP
                                  > > port switch is recognized by both Linux and Cisco stateful firewalls.
                                  > >
                                  > > There are a some complications that would need to be handled:
                                  > >
                                  > > (1) You would need to protect against DoS attacks that flood the server
                                  with
                                  > > fork requests.  Possibly some variation of --tls-auth that would
                                  > > authenticate the initial packet before the fork call.
                                  > >
                                  > > (2) If a client connects, gets disconnected, then connects again, you
                                  would
                                  > > need to make sure that the old server process gets killed before a new
                                  > > server process is forked.
                                  > >
                                  > > Unfortunately I'm pretty busy right now with my day job, so I may not
                                  get to
                                  > > this for a while.  If you want to take a shot at some kind of
                                  > > implementation, I will do my best to answer your questions.
                                  > >
                                  > > Best Regards,
                                  > > James
                                  > >
                                  > > ----- Original Message -----
                                  > > From: "Michael Grigoriev" <mag@ni...>
                                  > > To: <openvpn-devel@li...>
                                  > > Sent: Monday, July 22, 2002 6:53 PM
                                  > > Subject: [Openvpn-devel] Multiple VPN connections on the same port
                                  > >

__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: [Openvpn-devel] RE: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD

[Matthias A. <ma+...@dt...>]

On Wed, 27 Nov 2002, James Yonan wrote:

> Given that this assumption is flawed, it is probably necessary to add a new 
> variable which I am calling tun_mtu_extra which is the maximum number of 
> bytes in excess of the MTU size that a TUN/TAP device might return in a read 
> operation.
> 
> I've put together a new beta of OpenVPN which allows this parameter to be 
> set using a new --tun-mtu-extra option.
> 
> In my testing, --tun-mtu-extra 64 worked fine with a wide range of MTU sizes 
> on TAP devices.
> 
> The tarball is here (also on CVS):
> 
> http://openvpn.sourceforge.net/beta/openvpn-1.3.2.2.tar.gz
> 
> Zhen, let me know if it works for you.
> 
> Also, for other OpenVPN developers, is this the right solution?  It seems 
> like a bit of a kludge, though it also seems like a bug that a TAP device 
> would expect a reader to accomodate a read greater than its MTU size.  If it 
> is the right solution, should it be defaulted to some reasonably 
> conservative value and hidden under the hood, or should it be exposed as an 
> option (as I have done) to potentially confuse and/or empower end-users?
> 
> Comments?

Warning: I haven't followed the openvpn-users thread.

What do the maintainers of the TUN and TAP drivers have to say? Did you
ask them? They might have an explanation or fix a driver bug or two.

[Openvpn-devel] RE: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD

[James Y. <ji...@yo...>]

Zhen,

I'm moving this thread to openvpn-devel as it is starting to touch on more 
development oriented issues.

Well the good news is that I was able to reproduce your problem with MTU 
settings on TAP devices (on Linux) and I have a proposed fix.

The problem is that OpenVPN apparently has a flawed assumption about the 
relationship between the MTU size that a TAP device is ifconfiged with, and 
the maximum packet size which might be returned in a read() operation on 
that device.

For example, I ifconfiged a TAP device to an MTU of 1200, did a ping -s 2000 
over the link (through OpenVPN), and found that OpenVPN needed to have a 
large enough buffer on read() to read/write 1210 bytes to/from the TAP 
device.  By contrast, a TUN device MTUed to 1200 would never try to push 
more than 1200 bytes onto a read() operation.

Until now, OpenVPN assumed that if the MTU of TUN/TAP device was x, that it 
would be sufficient to read from that device using read(tun_tap_fd, buffer, 
x) where buffer is of size x.

Given that this assumption is flawed, it is probably necessary to add a new 
variable which I am calling tun_mtu_extra which is the maximum number of 
bytes in excess of the MTU size that a TUN/TAP device might return in a read 
operation.

I've put together a new beta of OpenVPN which allows this parameter to be 
set using a new --tun-mtu-extra option.

In my testing, --tun-mtu-extra 64 worked fine with a wide range of MTU sizes 
on TAP devices.

The tarball is here (also on CVS):

http://openvpn.sourceforge.net/beta/openvpn-1.3.2.2.tar.gz

Zhen, let me know if it works for you.

Also, for other OpenVPN developers, is this the right solution?  It seems 
like a bit of a kludge, though it also seems like a bug that a TAP device 
would expect a reader to accomodate a read greater than its MTU size.  If it 
is the right solution, should it be defaulted to some reasonably 
conservative value and hidden under the hood, or should it be exposed as an 
option (as I have done) to potentially confuse and/or empower end-users?

Comments?

James

Zhen Xu <zh...@lo...> said:

> James,
> 
> Tried out the method you suggested by setting tun-mtu and let the udp-mtu
> float does not work. I have tried tun-mtu at 1200, 1300, 1400, and none of
> them work. The way I am testing it is to do a "ping -c 1 -s 4000 <peer>".
> The tcpdump on the tap device will show trucated-ip missing bytes.
> 
> zxu
> 
> -----Original Message-----
> From: James Yonan
> To: Zhen Xu; ''ope...@li...' '
> Sent: 11/25/02 1:22 PM
> Subject: RE: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD
> 
> Zhen Xu <zh...@lo...> said:
> 
> > Hi all,
> > 
> > This is just a follow up on my discoveries on OpenVPN with TAP
> interfaces.
> > As I have said in the previous email, the caculated tun-mtu by OpenVPN
> does
> > not work. My statement in the previous email regarding OpenVPN is not
> > caculating the tun-mtu when udp-mtu is specified maybe wrong. By
> looking at
> > the source, it seems that udp-mtu/tun-mtu is only calculated when
> encryption
> > is used. As the example I am using in the previous email is not using
> any
> > encryption, OpenVPN will just use the same mtu for both udp/tun.
> However,
> > the result is the same--the calculated tun-mtu does not work with the
> TAP
> > interface. By debugging the connection, packet transfers between two
> peers
> > at the UDP level is working fine. The problem is actually at the
> tun/tap
> > level. By using the calculated tun-mtu, tcpdump will show truncated-ip
> > missing byte error when large packets need to be fragmented into
> smaller
> > ones and then de-fragmented at the other end. As it is truncated-ip
> with
> > missing byte, the checksum will be wrong and the peer will simply drop
> the
> > packet. Consequently, the message of the day in ssh will crash the ssh
> > client. Why the calculated tun-mtu will not work with TAP drivers, I
> am not
> > sure and James may give more insight. 
> > 
> > To get around the problem, I managed to use --udp-mtu 1300 in the
> config
> > file and use a hard coded mtu for the tun interface in the --up
> script. For
> > any given udp-mtu in the config file, (udp-mtu size - 100) will work
> > perfectly for your tun-mtu. For example, with udp-mtu set to 1300, I
> will
> > use 1200 as the mtu for the tap interface (OpenVPN will calculate and
> > recommend 1258). In my --up script, I will have "ifconfig $1 inet
> x.x.x.x
> > netmask x.x.x.x mtu 1200 up" instead of "ifconfig $1 inet x.x.x.x
> netmask
> > x.x.x.x mtu $2 up". This will resolve all the problems I am having
> with
> > OpenVPN/TAP interface. Why this? I have not figured out yet.
> > 
> > With the above resolved, I am happy to report that Zebra/OSPF works
> perfect
> > with OpenVPN. I can not have 4 sites running with a mix of
> FreeBSD/Linux and
> > the virtual network routes automatically with OSPF. 
> > 
> > zxu
> 
> Zxu,
> 
> Just to clarify how OpenVPN handles MTU, there are 3 variables of
> interest, with 2 degrees of freedom:
> 
> (1) udp-mtu is the max size of an encapsulated packet + encryption
> related overhead.  Thus, udp-mtu is the max size of a UDP datagram which
> will be exchanged between the peers.
> 
> (2) tun-mtu is the MTU size of the TUN or TAP device, i.e. the max frame
> size of the underlying transport (IP in the case of a TUN device, or
> Ethernet in the case of a TAP device).
> 
> (3) A parameter we will call "delta" is the size of the encapsulation
> overhead, including encryption overhead.
> 
> As you probably surmised from reading the code, the MTU equation is as
> follows: udp_mtu = tun_mtu + delta.
> 
> OpenVPN allows either (1) or (2), but not both, to be explicitly defined
> on the command line or config file.  (3) is calculated internally based
> on the amount of encryption overhead which OpenVPN will need, given a
> set of encryption options.  As you correctly observed, when OpenVPN is
> run without encryption, obviously there will be no encryption-related
> overhead, therefore delta == 0 and (1) == (2).
> 
> For reasons of flexibility, OpenVPN allows either udp-mtu or tun-mtu to
> be explicitly defined.  OpenVPN will then calculate the other variable
> based on the MTU equation above.  This flexibility is important, because
> setting the MTU in an encapsulated protocol environment is a complex
> exercise given the issues of fragmentation and other constraints.  For
> example, when you use the udp-mtu parameter, OpenVPN assumes that
> (udp_mtu - delta) is a legal MTU size for the TUN or TAP device.  In
> practice this might not be the case, as you observed with a TAP driver
> in your example above.
> 
> The intended solution to the problem of the TUN or TAP device only
> accepting certain MTU values is to set the value explicitly using the
> tun-mtu parameter, and let the udp-mtu "float" according to the equation
> udp_mtu = tun_mtu + delta.
> 
> In your example above, this could be accomplished by setting tun-mtu
> (the tun-mtu parameter in OpenVPN means the MTU of the TUN _or_ TAP
> device) to 1200 and then leave the up file as 
> 
> ifconfig $1 inet x.x.x.x netmask x.x.x.x mtu $2 up
> 
> OpenVPN would then use 1200 as the TAP MTU and approximately 1242
> (depending on encapsulation overhead) as the UDP MTU.  In the script
> above, $2 would be set to 1200 by OpenVPN.
> 
> Does that make sense (and more importantly does it work for you)?
> 
> James
> 
> > 
> > -----Original Message-----
> > From: James Yonan
> > To: Zhen Xu; 'ope...@li...'
> > Sent: 11/23/02 2:26 PM
> > Subject: Re: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD
> > 
> > Zhen Xu <zh...@lo...> said:
> > 
> > > Hi all,
> > > 
> > > Is anyone using OpenVPN with TAP device on either Linux or FreeBSD
> > with
> > > success? If not, I like to know if OpenVPN is well tested with the
> TAP
> > > driver. 
> > > 
> > > I was trying to use OpenVPN with TAP driver, but ran into some weird
> > > problems that I could not solve myself. The situation is this:
> > > 
> > > * Setup VPN with OpenVPN with a mix of Linux (2.4.7/2.4.19) and
> > FreeBSD
> > > (4.4)
> > > * Use TAP driver so that Zebra/OSPFD can see it and do OSPF routing
> > across a
> > > couple VPN sites (for some weird reason, Zebra/OSPFD does not see
> tun
> > > point-to-point devices and can not run OSPF over it)
> > > 
> > > The setup of OpenVPN is as smooth as it could be and bringing up the
> > link
> > > between two sites went just fine. For site A, we have "ifconfig $1
> > inet
> > > 10.0.0.1 netmask 255.255.255.252 mtu $2 up". For site B, we have
> > "ifconfig
> > > $1 inet 10.0.0.2 netmask 255.255.255.252 mtu $2 up". On either site
> A
> > or B,
> > > pinging the remote site went through just fine without any problem.
> > However,
> > > the problem occurs once one of them starts to transfer large data.
> For
> > > example, if you run ssh on site A to connect to site B, the ssh
> > > authentication will pass, but right after login, the remote site is
> > sending
> > > over the message of the day, the ssh session will die. Tried to
> debug
> > the
> > > link by using --verb 8, each key strok you type on the ssh client
> that
> > you
> > > are running on site A is actually sent to the site B, however, the
> ssh
> > > screen will freez with just one or two lines of the message of the
> > day.
> > > Trying the same with ftp and scp, the same result will happen. For
> > ftp, the
> > > ftp client will give out message like connection timeout. To isolate
> > > problems, I have tried to run OpenVPN without encryption or anything
> > special
> > > options except lzo compression across LAN on the same switch. Both
> > sides are
> > > Linux 2.4.19. If the TAP driver is used, the VPN link will behave
> the
> > same.
> > > To dig further, I have tried the tun driver with the above setup,
> > everything
> > > works great even transfering 100+M data across scp. For tun setup,
> > instead
> > > of using the up script, the config file has "ifconfig 10.0.0.1
> > 10.0.0.2".
> > > Originally, I am suspecting the MTU size, however, changing from
> > udp-mtu
> > > 1000 to 1500 does not fix the problem I am having. As the same
> problem
> > > occurrs even with two machine setup on the same switch, MTU patch
> > discovery
> > > blocked by firewall inbetween is not part of the problem. Could
> anyone
> > give
> > > me any hints? Thanks much!
> > > 
> > > zxu
> > 
> > Zhen,
> > 
> > Unfortunately I haven't used TAP devices other than in a simple
> testing
> > situation, so I can't give you very much feedback.  From what you
> > report, it sounds like some kind of MTU problem.  You said that small
> > packets like ssh keystrokes work fine, but the "message of the day"
> > locks up the connection.  With OpenVPN running --verb 8, does the
> > message of the day actually transit the UDP link between the OpenVPN
> > peers?  Where exactly in the chain of transmission is the message
> > dropped?  Since a TUN based connection works perfectly, I would
> suspect
> > some kind of problem in the way you are using the TAP device.  Are you
> > bridging the TAP device with an ethernet NIC?  If so, are you ensuring
> > MTU compatibility between the real and virtual ethernets.  Have you
> > checked the linux brctl list for the usual gotchas regarding this type
> > of configuration?  Have you tried a Linux <-> Linux TAP connection
> > (perhaps some problem between Linux and FreeBSD TAP drivers -- in the
> > past, I have encounter!
> > ed fragmentation incompatibilities between TUN drivers of different
> > OSes.  See the note in INSTALL about OpenBSD and the "scrub"
> directive)?
> > Are you only using a TAP driver instead of a TUN driver to get around
> > the problem of Zebra/OSPFD not seeing TUN devices?  If so, you might
> > look deeper into the problem of how to solve this problem, because TAP
> > drivers are usually only used by people who want to do ethernet
> > bridging, and as such they introduce some extra complexity which is
> not
> > present in the simpler case of the TUN driver.
> > 
> > It is an interesting problem, making Zebra/OSPFD work over virtual
> > links, and I don't recall this topic being discussed here before.  If
> > you figure it out, be sure to let us know how you made it work!
> > 
> > James
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Openvpn-users mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> > 
> 
> 
> 
> -- 
> 
> 



-- 

[Openvpn-devel] how to link openvpn statically to libssl libcrypto and libpthread..

[Etienne C. <Cha...@be...>]

Hi,

I would like to use openvpn on a leaf bering ( leaf.sourceforge.net) .
I would like to minimize the dependencies on shared libs
Is it possible to link staticaly on those libraries the way it's done with
liblzo...

Thanks in advance
Etienne Charlier
Cha...@be...

Re: [Openvpn-devel] QoS

[Craig K. <cr...@pu...>]

> I think TOS pass-through would be a nice optional feature to add to OpenVPN.  I would be curious to know how this works for you, i.e. extracting the TOS from the TUN/TAP data and calling setsockopt before the encrypted packet gets written to the UDP port.

It does work. 
Some results are (the two ping test run at the same time with a couple
of large scp (TOS=0x08) copies going at the same time):

ping -Q 0x08 [otherside of tunnel]
------------------------------------------------------------------
10 packets transmitted, 10 received, 0% loss, time 9085ms
rtt min/avg/max/mdev = 1097.163/1282.668/2088.874/276.205 ms, pipe 2


ping -Q 0x10 [otherside of tunnel]
-----------------------------------------------------------------
10 packets transmitted, 10 received, 0% loss, time 9089ms
rtt min/avg/max/mdev = 45.979/97.734/138.788/26.672 ms


> Some caveats that immediately come to mind:
> 
> * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits.

My quick hack (3 lines) assumes it is only IPv4 (as it always is for
me), for other protocols such as IPv6 I wouldn't know how to handle it,
but you could always check the first 8bits are 0x45 before trying to
read the TOS field.

> * Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted?

I don't think this matters.  When packets are fragmented they would get
the TOS of the original packet.
 
> * This process causes the TOS to be sent as plaintext, which could be undesirable from a security standpoint.

I can't think of any other way to get the same result.

Re: [Openvpn-devel] QoS

[Aaron S. <and...@ra...>]

On Wed, 30 Oct 2002, James Yonan wrote:
>
> Some caveats that immediately come to mind:
>
> * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits.
Well if you end up looking at the ip header by using struct iphdr, you'd
be able to determine the version of IP packet whether it was 4 or 6, then
from there you'd need to use either struct iphdr or struct ipv6hdr,
respectively.  This would be very similiar to the IPv6 detection stuff I
had to do to get ipv6 tunnelling to work with Linux.
 >
> * Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted?
TOS is independent of the protocol riding on top of it as it is strictly
done on the IP level.

The thing to consider is, depending on the OS, setting the TOS to certain
levels might require root privledges.

Aaron

Re: [Openvpn-devel] QoS

[James Y. <ji...@yo...>]

Craig Knox <cr...@pu...> said:

> Hi,
> 
> > One of the problems I can see with this is that you give some information
> > away about the payload, mind you not much, but you are regardless.
> 
> That is true - but for me its either give away TOS or have things become
> unresponsive.
> 
> >  I
> > guess if you really wanted to do this, one could modify openvpn to look at
> > the IP headers directly inside of openvpn and get the TOS off of the
> > packet and then use setsockopt() to set it for the outgoing packet.  It
> > might not seem pretty, but it'll work.  Let me know if you want me to hack
> > up a patch for you to do this.
> 
> Cheers - Think I've manage to make the changes by getting the TOS field
> of the incoming packet and setting it on the udp packet - in that it
> seems to work.

I think TOS pass-through would be a nice optional feature to add to OpenVPN.  I would be curious to know how this works for you, i.e. extracting the TOS from the TUN/TAP data and calling setsockopt before the encrypted packet gets written to the UDP port.

Some caveats that immediately come to mind:

* Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits.

* Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted?

* This process causes the TOS to be sent as plaintext, which could be undesirable from a security standpoint.

James

[Openvpn-devel] Re: [Openvpn-users] CRL with TLS security?

[James Y. <ji...@yo...>]

Felipe Sanchez <iz...@as...> said:

> 
> Hi, I've been using openvpn for about a month now with great success, I
> have already setup about a dozen VPN connections in various environments.
> 
> Lately I began wondering what would happen if I don't want some peer to be
> able to connect to my server anymore? From reading the docs I think I have
> these options:
> 
> a) Use a different CA for signing the certificate of each client, so when
>    I don't want that client to connect I just stop using the related
>    CA's certificate and key at the server.
> 
> b) Use my organization's CA for signing all the certificates (Which is
>    what I'm currently doing) and use --tls-verify and some scripting to
>    verify if the certificate presented by the peer is still acceptable
> 
> c) Use a Certificate Revocation List (CRL) to invalidate any certificates
>    I don't want to accept anymore.
> 
> 
> Looks like c) could be done in the same way that b) by using --tls-verify
> and the OpenSSL tools. My question is: Do I have to do that or does
> OpenVPN have built-in CRL support? I have found no mention of it in the
> documentation.
> 
> Felipe Sanchez.

You are right that while (a) and (b) are currently supported, (c) is not.  Having said that, I would imagine that adding CRL support would be straightforward.  If you are interested in writing a patch, init_ssl() in ssl.c would be the place to look + the OpenSSL docs concerning CRLs.  It's probably just a matter of adding the right OpenSSL calls to init_ssl to add the CRL to the SSL context.

James

Re: [Openvpn-devel] QoS

[Craig K. <cr...@pu...>]

Hi,

> One of the problems I can see with this is that you give some information
> away about the payload, mind you not much, but you are regardless.

That is true - but for me its either give away TOS or have things become
unresponsive.

>  I
> guess if you really wanted to do this, one could modify openvpn to look at
> the IP headers directly inside of openvpn and get the TOS off of the
> packet and then use setsockopt() to set it for the outgoing packet.  It
> might not seem pretty, but it'll work.  Let me know if you want me to hack
> up a patch for you to do this.

Cheers - Think I've manage to make the changes by getting the TOS field
of the incoming packet and setting it on the udp packet - in that it
seems to work.

Re: [Openvpn-devel] QoS

[Aaron S. <and...@ra...>]

On 28 Oct 2002, Craig Knox wrote:

> Hi there,
>    I use QoS routing and it works great except over openvpn/tun device.
>
>    Correct me if I am wrong but I think this is because the packets are
> encapsulated within a UDP packet with no regard to what the original
> packets TOS field was, so once it reaches a "real" device it is just
> treated as bulk even it was suppose to be for example minimum-delay.
>
>    Is there anyway the TOS of the UDP packet could be set the match its
> payload's TOS?
One of the problems I can see with this is that you give some information
away about the payload, mind you not much, but you are regardless.  I
guess if you really wanted to do this, one could modify openvpn to look at
the IP headers directly inside of openvpn and get the TOS off of the
packet and then use setsockopt() to set it for the outgoing packet.  It
might not seem pretty, but it'll work.  Let me know if you want me to hack
up a patch for you to do this.

Regards,

Aaron

Re: [Openvpn-devel] QoS

[James Y. <ji...@yo...>]

Craig,

No, right now OpenVPN (and I believe the Linux TUN driver as well) has no special handling for QoS such as TOS pass through between different encapsulation layers (though it's an interesting idea).

You could, of course, apply QoS rules to OpenVPN's UDP connection or make use of OpenVPN's traffic shaping option (--shaper) for basic control over output speed.

By using multiple tunnels between the same hosts, each with different QoS rules, you could accomplish some of the same effect.

James

Craig Knox <cr...@pu...> said:

> Hi there,
>    I use QoS routing and it works great except over openvpn/tun device. 
> 
>    Correct me if I am wrong but I think this is because the packets are
> encapsulated within a UDP packet with no regard to what the original
> packets TOS field was, so once it reaches a "real" device it is just
> treated as bulk even it was suppose to be for example minimum-delay.
> 
>    Is there anyway the TOS of the UDP packet could be set the match its
> payload's TOS? 
> 
> Cheers
> Craig
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] QoS

[Craig K. <cr...@pu...>]

Hi there,
   I use QoS routing and it works great except over openvpn/tun device. 

   Correct me if I am wrong but I think this is because the packets are
encapsulated within a UDP packet with no regard to what the original
packets TOS field was, so once it reaches a "real" device it is just
treated as bulk even it was suppose to be for example minimum-delay.

   Is there anyway the TOS of the UDP packet could be set the match its
payload's TOS? 

Cheers
Craig

Re: [Openvpn-devel] OpenVPN 1.3.2 Released

[Matthias A. <ma+...@dt...>]

On Thu, 24 Oct 2002, James Yonan wrote:

> Download:
> 
> https://sourceforge.net/projects/openvpn/
> 
> Change Log:
> 
> * Added FreeBSD 4.1.1+ TUN/TAP driver notes to
>   INSTALL (Matthias Andree).

The FreeBSD port update (to version 1.3.2, you'd guessed that) has just
been committed to the ports tree and will show up on the mirrors soon.

It now features an example start script that shows the user how to load
the "tap" kernel module automatically at boot-up, to avoid "device not
configured" errors. (It's not really more than comments, case and
kldload.)

-- 
Matthias Andree

[Openvpn-devel] OpenVPN 1.3.2 Released

[James Y. <ji...@yo...>]

Well here it is at last... Thanks to everyone who contributed!

James

********************

Download:

https://sourceforge.net/projects/openvpn/

Change Log:

* Added SSL_CTX_set_client_CA_list call
  to follow the canonical form for TLS initialization
  recommended by the OpenSSL docs.  This change allows
  better support for intermediate CAs and has no impact
  on security.
* Added build-inter script to easy-rsa package, to
  facilitate the generation of intermediate CAs.
* Ported to NetBSD (Dimitri Goldin).
* Fixed minor bug in easy-rsa/sign-req.  It refers to
  openssl.cnf file, instead of $KEY_CONFIG, like all
  other scripts (Ernesto Baschny).
* Added --days 3650 to the root CA generation command
  in the HOWTO to override the woefully small 30 day
  default (Dominik 'Aeneas' Schnitzer).
* Fixed bug where --ping-restart would sometimes
  not re-resolve remote DNS hostname.
* Added --tun-ipv6 option and related infrastructure
  support for IPv6 over tun.
* Added IPv6 over tun support for Linux (Aaron Sethman).
* Added FreeBSD 4.1.1+ TUN/TAP driver notes to
  INSTALL (Matthias Andree).
* Added inetd/xinetd support (--inetd) including
  documentation in the HOWTO.
* Added "Important Note on the use of commercial certificate
  authorities (CAs) with OpenVPN" to HOWTO based on
  issues raised on the openvpn-users list.

Re: [Openvpn-devel] Another pre-1.3.2 beta

[Matthias A. <ma+...@dt...>]

On Sun, 20 Oct 2002, James Yonan wrote:

> Changes since last beta:
> 
> * Added inetd/xinetd support (--inetd) including
>   documentation in the HOWTO.

Works for me. Thanks.

[Openvpn-devel] Another pre-1.3.2 beta

[James Y. <ji...@yo...>]

Another beta is available to test.  This one adds support and documentation for on-demand xinetd instantiation of the openvpn daemon.

Changes since last beta:

* Added FreeBSD 4.1.1+ TUN/TAP driver notes to
  INSTALL (Matthias Andree).
* Added inetd/xinetd support (--inetd) including
  documentation in the HOWTO.

Download from CVS or:

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.10.tar.gz

Beta version of the website is here with some additions to the documentation and HOWTO:

http://openvpn.sourceforge.net/beta/www/

James

Re: [Openvpn-devel] New pre-1.3.2 beta available, please test

[James Y. <ji...@yo...>]

Matthias,

Thanks, I've merged with CVS.

James

Matthias Andree <ma+...@dt...> said:

> On Thu, 17 Oct 2002, James Yonan wrote:
> 
> > 
> > Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.
> 
> No problems, just documentation about FreeBSD. Most of this has been
> filed as update against FreeBSD's 1.3.0 port.
> 
> FreeBSD currently installs tap0...tap3 and tun0...tun3 by default.
> 
> The FreeBSD GENERIC kernel has tun support compiled in, no further work
> necessary. However, for tap support, the admin must execute "kldload
> if_tap" once (or he can recompile and install the kernel after adding
> the line "pseudo-device tap").
> 
> (kldload is called insmod on Linux, rmmod -> kldunload, lsmod ->
> kldstat).
> 
> I suggest this patch (against CVS) -- it also includes two whitespace
> fixes, so don't copy & paste, but pipe it into patch:
> 
> Index: INSTALL
> ===================================================================
> RCS file: /cvsroot/openvpn/openvpn/INSTALL,v
> retrieving revision 1.22
> diff -u -r1.22 INSTALL
> --- INSTALL~	28 Jul 2002 07:54:57 -0000	1.22
> +++ INSTALL	18 Oct 2002 23:33:02 -0000
> @@ -152,20 +152,35 @@
>    openvpn.init script, these steps are taken care of for you.
>  
>  * Linux 2.2 or Solaris:
> - 
> +
>    You should obtain
>    version 1.1 of the TUN/TAP driver from
>    http://vtun.sourceforge.net/tun/
>    and follow the installation instructions.
>  
> +* FreeBSD 4.1.1+:
> +
> +  FreeBSD ships with the TUN/TAP driver, and the device nodes for tap0,
> +  tap1, tap2, tap3, tun0, tun1, tun2 and tun3 are made by default.
> +  However, only the TUN driver is linked into the GENERIC kernel.
> +
> +  To load the TAP driver, enter: 
> +
> +	kldload if_tap
> +
> +  See man rc(8) to find out how you can do this at boot time.
> +
> +  The easiest way is to install OpenVPN from the FreeBSD ports system,
> +  the port includes a sample script to automatically load the tap driver
> +  at boot-up time.
> +
>  * OpenBSD:
>  
>    OpenBSD ships with tun0 and tun1 installed by default.
>  
>  * Mac OS X:
>  
> -  Obtain Christoph Pfisterer's
> -  tun driver at
> +  Obtain Christoph Pfisterer's tun driver at
>    http://chrisp.de/en/projects/tunnel.html
>  
>   See the man page for more information, usage examples, and
> 
> -- 
> Matthias Andree
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

Re: [Openvpn-devel] New pre-1.3.2 beta available, please test

[Matthias A. <ma+...@dt...>]

On Thu, 17 Oct 2002, James Yonan wrote:

> 
> Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.

No problems, just documentation about FreeBSD. Most of this has been
filed as update against FreeBSD's 1.3.0 port.

FreeBSD currently installs tap0...tap3 and tun0...tun3 by default.

The FreeBSD GENERIC kernel has tun support compiled in, no further work
necessary. However, for tap support, the admin must execute "kldload
if_tap" once (or he can recompile and install the kernel after adding
the line "pseudo-device tap").

(kldload is called insmod on Linux, rmmod -> kldunload, lsmod ->
kldstat).

I suggest this patch (against CVS) -- it also includes two whitespace
fixes, so don't copy & paste, but pipe it into patch:

Index: INSTALL
===================================================================
RCS file: /cvsroot/openvpn/openvpn/INSTALL,v
retrieving revision 1.22
diff -u -r1.22 INSTALL
--- INSTALL~	28 Jul 2002 07:54:57 -0000	1.22
+++ INSTALL	18 Oct 2002 23:33:02 -0000
@@ -152,20 +152,35 @@
   openvpn.init script, these steps are taken care of for you.
 
 * Linux 2.2 or Solaris:
- 
+
   You should obtain
   version 1.1 of the TUN/TAP driver from
   http://vtun.sourceforge.net/tun/
   and follow the installation instructions.
 
+* FreeBSD 4.1.1+:
+
+  FreeBSD ships with the TUN/TAP driver, and the device nodes for tap0,
+  tap1, tap2, tap3, tun0, tun1, tun2 and tun3 are made by default.
+  However, only the TUN driver is linked into the GENERIC kernel.
+
+  To load the TAP driver, enter: 
+
+	kldload if_tap
+
+  See man rc(8) to find out how you can do this at boot time.
+
+  The easiest way is to install OpenVPN from the FreeBSD ports system,
+  the port includes a sample script to automatically load the tap driver
+  at boot-up time.
+
 * OpenBSD:
 
   OpenBSD ships with tun0 and tun1 installed by default.
 
 * Mac OS X:
 
-  Obtain Christoph Pfisterer's
-  tun driver at
+  Obtain Christoph Pfisterer's tun driver at
   http://chrisp.de/en/projects/tunnel.html
 
  See the man page for more information, usage examples, and

-- 
Matthias Andree

[Openvpn-devel] New pre-1.3.2 beta available, please test

[James Y. <ji...@yo...>]

Here is the latest pre-1.3.2 beta that now supports IPv6 over tun on Linux.  Please test.  I plan to release 1.3.2 shortly if there are no problems reported.

Download from CVS or

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.7.tar.gz

Change Log:

* Added SSL_CTX_set_client_CA_list call
  to follow the canonical form for TLS initialization
  recommended by the OpenSSL docs.  This change allows
  better support for intermediate CAs and has no impact
  on security.
* Added build-inter script to easy-rsa package, to
  facilitate the generation of intermediate CAs.
* Ported to NetBSD (Dimitri Goldin).
* Fixed minor bug in easy-rsa/sign-req.  It refers to
  openssl.cnf file, instead of $KEY_CONFIG, like all
  other scripts (Ernesto Baschny).
* Added --days 3650 to the root CA generation command
  in the HOWTO to override the woefully small 30 day
  default (Dominik 'Aeneas' Schnitzer).
* Fixed bug where --ping-restart would sometimes
  not re-resolve remote DNS hostname.
* Added --tun-ipv6 option and related infrastructure
  support for IPv6 over tun.
* Added IPv6 over tun support for Linux (Aaron Sethman).
* Added "Important Note on the use of commercial certificate
  authorities (CAs) with OpenVPN" to HOWTO based on
  issues raised on the openvpn-users list.

James

Re: [Openvpn-devel] tunnelling ipv6 on linux

[Aaron S. <and...@ra...>]

On Fri, 4 Oct 2002, James Yonan wrote:

> Hi Aaron,
>
> I've incorporated your IPv6 over tun patch for Linux into the latest OpenVPN beta, and added some basic infrastructure code and a --tun-ipv6 option which enables the IPv6 over tun support.  The option makes a placeholder for all OSes to support IPv6 over tun that is off by default and does not break any existing usage.
>
> Beta is available here and on CVS:
>
> http://openvpn.sourceforge.net/beta/openvpn-1.3.1.6.tar.gz
>
> My IPv6 testing capabilities are limited at this point, so please test.
I've tested between two Linux boxes and it seems to be working perfect at
this point.  I'll give it some more testing and see how it goes.  I'll
also look into testing on a Solaris box, but I'm guessing that will need
some extra help to get working.

Regards,

Aaron

Re: [Openvpn-devel] tunnelling ipv6 on linux

[James Y. <ji...@yo...>]

Hi Aaron,

I've incorporated your IPv6 over tun patch for Linux into the latest OpenVPN beta, and added some basic infrastructure code and a --tun-ipv6 option which enables the IPv6 over tun support.  The option makes a placeholder for all OSes to support IPv6 over tun that is off by default and does not break any existing usage.

Beta is available here and on CVS:

http://openvpn.sourceforge.net/beta/openvpn-1.3.1.6.tar.gz

My IPv6 testing capabilities are limited at this point, so please test.

Best Regards,
James

Aaron Sethman <and...@ra...> said:

> 
> 
> On Sat, 28 Sep 2002, James Yonan wrote:
> 
> > Aaron,
> >
> > Thanks for the patch, however I was not able to get it to work with IPv4 while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running the patch.  The code compiles and runs, but pings don't go through.  Perhaps there is a minimum kernel version necessary for this to work?  Does the kernel need to be built with IPv6 support in order for this code to work with IPv4?
> Well, it shouldn't require any IPv6 support in the kernel to simply pass
> IPv4 packets.  I'll need to look at the tun driver in 2.4.9.  Both of my
> machines here are running 2.4.19.
> >
> > There is also the issue of breaking protocol compatibility by adding the ETH_P_IPV6/ETH_P_IP to the IP-over-tun packet encoding.  I would propose that:
> Well, it doesn't break the protocol at all, what ends up happening is, the
> kernel takes the tun_pi header and strips it off, so those headers never
> get sent on the wire.
> 
>  >
> > (1) We run-time conditionalize your patch on a --tun-ipv6 option.
> 
> >
> > (2) We compile-time (e.g. #ifdef bracket on HAVE_NETINET_IF_ETHER_H, ETH_P_IPV6, etc.) and/or run-time conditionalize so that usage of --tun-ipv6 produces a run-time error if ipv6 over tun is not supported.
> That sounds like a good idea.
> >
> > (3) We add --tun-ipv6 enabled/disabled state to the options_string function in options.h as a sanity check between peers.
> >
> > (4) We think about how to make --tun-ipv6 portable across the platforms which OpenVPN supports.  This may be better addressed at the tun driver level, to reduce the machine-specific ugliness in tun.c?
> Well, this one might be a bit more difficult if the tunnel driver doesn't
> support it, of course it might be worth the effort to submit patches to
> the respective OSes for this.
> 
> >
> > (5) We look into making an ipv6 option for the tunnel UDP channel and endpoints as well.
> This part shouldn't be much of a problem.
> 
> Regards,
> 
> Aaron
> 



--