OpenVPN

Jez,

Any messages from OpenVPN in the syslog prior to the "inetd
[nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1" message?

Try adding --verb 8 to generate more debug info?

James

Jez Rogers <jez@...> said:

> Im trying to get openvpn to run from inetd on a RedHat 6.2 2.2.19-6.2.16 
> kernel. 
> 
> I get this error in syslog when attempting to start openvpn from inetd
> 
> inetd[nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1
> 
> /etc/inetd.conf contains:
> 
> openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev tun0 
> --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user nobody 
> --group nobody --inactive 600 --float --secret /root/openvpn/jez
> 
> /etc/services:
> openvpn         5170/udp                        # openvpn
> 
> If I remove the openvpn line from inetd.conf and restart it, then start 
> openvpn by hand using the above command line with the addition of --remote 
> and --daemon (and removing --inactive), I can connect just fine.
> 
> Version at both ends is 1.3.2. One was built with --disable-lzo the other 
> was not.
> 
> When trying to connect, the inetd machine shows this:
> 
> Proto Recv-Q Send-Q Local Address           Foreign Address         State
> udp      800      0 0.0.0.0:5170            0.0.0.0:*
> 
> The Recv-Q increments periodically but nothing gets through.
> 
> Does anyone have an idea why inetd is exiting?
> 
> 
> 
> -- 
> jez
> 
> What is a committee?
> 
> A group of the unwilling, 
> picked from the unfit, 
> to do the unnecessary.
> 
>      -- Richard Harkness
> 
> mailto:jez@...
> 
> http://www.jezndi.org
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



--

On Sat, 30 Nov 2002, James Yonan wrote:

> Jez,
> 
> Any messages from OpenVPN in the syslog prior to the "inetd
> [nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1" message?
> 
> Try adding --verb 8 to generate more debug info?


Hi.

On the inetd end there's nothing. I shut down inetd and added --verb 8:

openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev tun0 
--inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user nobody 
--group nobody --float --secret /root/openvpn/jez --inactive 600 --verb 8

Nov 30 10:22:52 ns0 inet: inetd shutdown succeeded
Nov 30 10:22:53 ns0 inet: inetd startup succeeded
Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16297): 
exit status 1
Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16298): 
exit status 1

And that's it.

At the client end I also turned on --verb 8 and --daemon and then used the 
following config:

dev tun
ifconfig 192.168.42.70 192.168.42.170
remote myhost
port 5170
user nobody
group nobody
float
secret /root/openvpn/ns0

There is quite a lot of debug info in syslog. I can post it if necessary.

> 
> James
> 
> Jez Rogers <jez@...> said:
> 
> > Im trying to get openvpn to run from inetd on a RedHat 6.2 2.2.19-6.2.16 
> > kernel. 
> > 
> > I get this error in syslog when attempting to start openvpn from inetd
> > 
> > inetd[nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1
> > 
> > /etc/inetd.conf contains:
> > 
> > openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev tun0 
> > --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user nobody 
> > --group nobody --inactive 600 --float --secret /root/openvpn/jez
> > 
> > /etc/services:
> > openvpn         5170/udp                        # openvpn
> > 
> > If I remove the openvpn line from inetd.conf and restart it, then start 
> > openvpn by hand using the above command line with the addition of --remote 
> > and --daemon (and removing --inactive), I can connect just fine.
> > 
> > Version at both ends is 1.3.2. One was built with --disable-lzo the other 
> > was not.
> > 
> > When trying to connect, the inetd machine shows this:
> > 
> > Proto Recv-Q Send-Q Local Address           Foreign Address         State
> > udp      800      0 0.0.0.0:5170            0.0.0.0:*
> > 
> > The Recv-Q increments periodically but nothing gets through.
> > 
> > Does anyone have an idea why inetd is exiting?
> > 
> > 
> > 
> > -- 
> > jez
> > 
> > What is a committee?
> > 
> > A group of the unwilling, 
> > picked from the unfit, 
> > to do the unnecessary.
> > 
> >      -- Richard Harkness
> > 
> > mailto:jez@...
> > 
> > http://www.jezndi.org
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Get the new Palm Tungsten T 
> > handheld. Power & Color in a compact size! 
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > _______________________________________________
> > Openvpn-users mailing list
> > Openvpn-users@...
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> > 
> 
> 
> 
> 

-- 
jez

What is a committee?

A group of the unwilling, 
picked from the unfit, 
to do the unnecessary.

     -- Richard Harkness

mailto:jez@...

http://www.jezndi.org

Jez,

It looks to me like OpenVPN might be encountering some sort of error, then 
exiting before it opens the syslog file, causing any error message it 
produces before exiting to be lost (an inet-instantiated daemon doesn't 
really have a working stderr to output error messages to).  Because on the 
one hand, inetd is saying that OpenVPN is exiting with error status 1 which 
usually means some sort of startup error, such as a bad command line, file 
or device open error, etc, but there is no message in the syslog prior to 
the message from inetd.

So I think the thing to do is first figure out why OpenVPN isn't putting an 
error message in the syslog prior to exiting.

Try this:

openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --inetd

This won't really do anything, other than produce an error message in the 
syslog.  On my xinetd system, I did the same with this config file:

service openvpn_1
{
        type            = UNLISTED
        port            = 5000
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /root/openvpn/openvpn
        server_args     = --inetd
        disable         = no
}

And when I try to connect I get a series of errors:

Nov 30 12:10:33 funnybee openvpn[16618]: Options error: You must define 
tun/tap device (--dev)
Nov 30 12:10:33 funnybee openvpn[16618]: Use --help for more information
Nov 30 12:10:33 funnybee xinetd[16585]: openvpn_1 service was deactivated 
because of looping

The important thing here is to make sure that OpenVPN is getting its error 
messages to the syslog.  Then we once we know what the error is, we can take 
it from there.

James

Jez Rogers <jez@...> said:

> On Sat, 30 Nov 2002, James Yonan wrote:
> 
> > Jez,
> > 
> > Any messages from OpenVPN in the syslog prior to the "inetd
> > [nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1" message?
> > 
> > Try adding --verb 8 to generate more debug info?
> 
> 
> Hi.
> 
> On the inetd end there's nothing. I shut down inetd and added --verb 8:
> 
> openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev tun0 
> --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user nobody 
> --group nobody --float --secret /root/openvpn/jez --inactive 600 --verb 8
> 
> Nov 30 10:22:52 ns0 inet: inetd shutdown succeeded
> Nov 30 10:22:53 ns0 inet: inetd startup succeeded
> Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16297): 
> exit status 1
> Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16298): 
> exit status 1
> 
> And that's it.
> 
> At the client end I also turned on --verb 8 and --daemon and then used the 
> following config:
> 
> dev tun
> ifconfig 192.168.42.70 192.168.42.170
> remote myhost
> port 5170
> user nobody
> group nobody
> float
> secret /root/openvpn/ns0
> 
> There is quite a lot of debug info in syslog. I can post it if necessary.
> 
> > 
> > James
> > 
> > Jez Rogers <jez@...> said:
> > 
> > > Im trying to get openvpn to run from inetd on a RedHat 6.2 2.2.19-
6.2.16 
> > > kernel. 
> > > 
> > > I get this error in syslog when attempting to start openvpn from inetd
> > > 
> > > inetd[nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1
> > > 
> > > /etc/inetd.conf contains:
> > > 
> > > openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev 
tun0 
> > > --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user 
nobody 
> > > --group nobody --inactive 600 --float --secret /root/openvpn/jez
> > > 
> > > /etc/services:
> > > openvpn         5170/udp                        # openvpn
> > > 
> > > If I remove the openvpn line from inetd.conf and restart it, then 
start 
> > > openvpn by hand using the above command line with the addition of --
remote 
> > > and --daemon (and removing --inactive), I can connect just fine.
> > > 
> > > Version at both ends is 1.3.2. One was built with --disable-lzo the 
other 
> > > was not.
> > > 
> > > When trying to connect, the inetd machine shows this:
> > > 
> > > Proto Recv-Q Send-Q Local Address           Foreign Address         
State
> > > udp      800      0 0.0.0.0:5170            0.0.0.0:*
> > > 
> > > The Recv-Q increments periodically but nothing gets through.
> > > 
> > > Does anyone have an idea why inetd is exiting?
> > > 
> > > 
> > > 
> > > -- 
> > > jez
> > > 
> > > What is a committee?
> > > 
> > > A group of the unwilling, 
> > > picked from the unfit, 
> > > to do the unnecessary.
> > > 
> > >      -- Richard Harkness
> > > 
> > > mailto:jez@...
> > > 
> > > http://www.jezndi.org
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Get the new Palm Tungsten T 
> > > handheld. Power & Color in a compact size! 
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > > _______________________________________________
> > > Openvpn-users mailing list
> > > Openvpn-users@...
> > > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> > > 
> > 
> > 
> > 
> > 
> 
> -- 
> jez
> 
> What is a committee?
> 
> A group of the unwilling, 
> picked from the unfit, 
> to do the unnecessary.
> 
>      -- Richard Harkness
> 
> mailto:jez@...
> 
> http://www.jezndi.org
> 



--

I find dynamic link problems are are mostly the cause of daemons failing to
start and not saying anything in syslog
try:
 ldd /usr/local/sbin/openvpn
and see if the libraries are present (.i.e you don't get a not found
message).
If you do you might need to add some ld paths to /etc/ld.so.conf and to an
ldconfig
Just a guess.
--
Rob


----- Original Message -----
From: "James Yonan" <jim@...>
To: "Jez Rogers" <jez@...>; "James Yonan" <jim@...>
Cc: <openvpn-users@...>
Sent: Sunday, December 01, 2002 7:37 AM
Subject: Re: [Openvpn-users] inetd[nnnnn]: /usr/local/sbin/openvpn (pid
nnnnn): exit status 1


> Jez,
>
> It looks to me like OpenVPN might be encountering some sort of error, then
> exiting before it opens the syslog file, causing any error message it
> produces before exiting to be lost (an inet-instantiated daemon doesn't
> really have a working stderr to output error messages to).  Because on the
> one hand, inetd is saying that OpenVPN is exiting with error status 1
which
> usually means some sort of startup error, such as a bad command line, file
> or device open error, etc, but there is no message in the syslog prior to
> the message from inetd.
>
> So I think the thing to do is first figure out why OpenVPN isn't putting
an
> error message in the syslog prior to exiting.
>
> Try this:
>
> openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --inetd
>
> This won't really do anything, other than produce an error message in the
> syslog.  On my xinetd system, I did the same with this config file:
>
> service openvpn_1
> {
>         type            = UNLISTED
>         port            = 5000
>         socket_type     = dgram
>         protocol        = udp
>         wait            = yes
>         user            = root
>         server          = /root/openvpn/openvpn
>         server_args     = --inetd
>         disable         = no
> }
>
> And when I try to connect I get a series of errors:
>
> Nov 30 12:10:33 funnybee openvpn[16618]: Options error: You must define
> tun/tap device (--dev)
> Nov 30 12:10:33 funnybee openvpn[16618]: Use --help for more information
> Nov 30 12:10:33 funnybee xinetd[16585]: openvpn_1 service was deactivated
> because of looping
>
> The important thing here is to make sure that OpenVPN is getting its error
> messages to the syslog.  Then we once we know what the error is, we can
take
> it from there.
>
> James
>
> Jez Rogers <jez@...> said:
>
> > On Sat, 30 Nov 2002, James Yonan wrote:
> >
> > > Jez,
> > >
> > > Any messages from OpenVPN in the syslog prior to the "inetd
> > > [nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1" message?
> > >
> > > Try adding --verb 8 to generate more debug info?
> >
> >
> > Hi.
> >
> > On the inetd end there's nothing. I shut down inetd and added --verb 8:
> >
> > openvpn dgram   udp     wait    root    /usr/local/sbin/openvpn --dev
tun0
> > --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user
nobody
> > --group nobody --float --secret /root/openvpn/jez --inactive 600 --verb
8
> >
> > Nov 30 10:22:52 ns0 inet: inetd shutdown succeeded
> > Nov 30 10:22:53 ns0 inet: inetd startup succeeded
> > Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16297):
> > exit status 1
> > Nov 30 10:25:15 ns0 inetd[16269]: /usr/local/sbin/openvpn (pid 16298):
> > exit status 1
> >
> > And that's it.
> >
> > At the client end I also turned on --verb 8 and --daemon and then used
the
> > following config:
> >
> > dev tun
> > ifconfig 192.168.42.70 192.168.42.170
> > remote myhost
> > port 5170
> > user nobody
> > group nobody
> > float
> > secret /root/openvpn/ns0
> >
> > There is quite a lot of debug info in syslog. I can post it if
necessary.
> >
> > >
> > > James
> > >
> > > Jez Rogers <jez@...> said:
> > >
> > > > Im trying to get openvpn to run from inetd on a RedHat 6.2 2.2.19-
> 6.2.16
> > > > kernel.
> > > >
> > > > I get this error in syslog when attempting to start openvpn from
inetd
> > > >
> > > > inetd[nnnnn]: /usr/local/sbin/openvpn (pid nnnnn): exit status 1
> > > >
> > > > /etc/inetd.conf contains:
> > > >
> > > > openvpn dgram   udp     wait    root
   /usr/local/sbin/openvpn --dev
> tun0
> > > > --inetd --ifconfig 192.168.42.170 192.168.42.70 --port 5170 --user
> nobody
> > > > --group nobody --inactive 600 --float --secret /root/openvpn/jez
> > > >
> > > > /etc/services:
> > > > openvpn         5170/udp                        # openvpn
> > > >
> > > > If I remove the openvpn line from inetd.conf and restart it, then
> start
> > > > openvpn by hand using the above command line with the addition of --
> remote
> > > > and --daemon (and removing --inactive), I can connect just fine.
> > > >
> > > > Version at both ends is 1.3.2. One was built with --disable-lzo the
> other
> > > > was not.
> > > >
> > > > When trying to connect, the inetd machine shows this:
> > > >
> > > > Proto Recv-Q Send-Q Local Address           Foreign Address
> State
> > > > udp      800      0 0.0.0.0:5170            0.0.0.0:*
> > > >
> > > > The Recv-Q increments periodically but nothing gets through.
> > > >
> > > > Does anyone have an idea why inetd is exiting?
> > > >
> > > >
> > > >
> > > > --
> > > > jez
> > > >
> > > > What is a committee?
> > > >
> > > > A group of the unwilling,
> > > > picked from the unfit,
> > > > to do the unnecessary.
> > > >
> > > >      -- Richard Harkness
> > > >
> > > > mailto:jez@...
> > > >
> > > > http://www.jezndi.org
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: Get the new Palm Tungsten T
> > > > handheld. Power & Color in a compact size!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> > > > _______________________________________________
> > > > Openvpn-users mailing list
> > > > Openvpn-users@...
> > > > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> > > >
> > >
> > >
> > >
> > >
> >
> > --
> > jez
> >
> > What is a committee?
> >
> > A group of the unwilling,
> > picked from the unfit,
> > to do the unnecessary.
> >
> >      -- Richard Harkness
> >
> > mailto:jez@...
> >
> > http://www.jezndi.org
> >
>
>
>
> --
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>

Forgot to mention:

I see the 'ping' in all three the VPN's :)) It just "doesn't" sends back
ping-replies or so .. 

On Wed, Nov 27, 2002 at 05:17:20PM +0100, Wouter de Jong wrote:
> Hello,
> 
> I've a question that's probably easy to answer, but I couldn't find it
> anywhere...(well, maybe I've looked over it :))
> 
> I want to setup a dedicated OpenVPN server (FreeBSD 4.7), that should link multiple
> clients (FreeBSD 4.7)
> 
> one-to-one OpenVPN works perfectly, with 'ipfw divert' for natd.
> Then I'm able to connect to all the clients on subnet A, from any client
> on subnet B (/24's)
> 
> However, I can't get the forwarding part correct on the dedicated
> server.
> 
> Dedicated server:	10.4.0.1
> 			* OpenVPN port 5002: 10.4.0.1 -> 10.4.0.2
> (openvpn --remote IP_ADDRESS_GATEWAY_A --dev tun1 --ifconfig 10.4.0.1 10.4.0.2
> --verb 8 --port 5002)
> 			* OpenVPN port 5003: 10.4.0.1 -> 10.4.0.3
> (openvpn --remote IP_ADDRESS_GATEWAY_B --dev tun2 --ifconfig 10.4.0.1 10.4.0.3
> --verb 8 --port 5003)
> 			* route 192.168.2.0/24 10.4.0.2
> 			* route 192.168.3.0/24 10.4.0.3
> 
> Gateway A:		10.4.0.2
> 			* OpenVPN port 5002: 10.4.0.2 -> 10.4.0.1
> 			* subnet 192.168.2.0/24
> 			* route 192.168.3.0/24 10.4.0.1
> 
> Gateway B:		10.4.0.3
> 			* OpenVPN port 5003: 10.4.0.3 -> 10.4.0.1
> (openvpn --remote IP_ADDRESS_DEDICATED --dev tun1 --ifconfig 10.4.0.3 10.4.0.1
> --verb 8 --port 5003)
> 			* subnet 192.168.3.0/24
> 			* route 192.168.2.0/24 10.4.0.1
> 			
> On the gateway's, 'xl0' is the external interface, 'xl1' is the internal
> interface. Running 'natd -n xl0' and 'ipfw add 00050 divert 8668 ip from
> any to any via xl0' and 'net.inet.ip.forwarding=1'
> 
> 
> On the dedicated server, 'xl0' is the only interface, having 'ipfw allow
> ip from any to any' and 'net.inet.ip.forwarding=1'
> 
> I can ping 10.4.0.2 and 10.4.0.3 from the dedicated server.
> I can 10.4.0.1 from both gateway's, but NO other 10.4.0.x IP (not even their own)
> (This is also the case with a one-to-one setup)
> 
> I can ping/connect to any 192.168.x.0/24 address from the dedicated
> server. 
> 
> OK, now my problem:
> 
> I can't ping 192.168.3.0/24 address(es) (from gateway B) on gateway A
> AND
> I can't ping 192.168.2.0/24 address(es) (from gateway A) on gateway B
> 
> 
> Anyone an idea of what I'm missing ? (maybe some ipfw forward rule ???)
> 
> Thanks in advance!
> 
> -- 
> Met vriendelijke groet/With kind regards,
> 
> Wouter de Jong
> System-Administrator
> 
> CABLE & WIRELESS
> Delivering the Internet promise(tm)
> URL:    http://www.widexs.nl
> 
> Email:  Wouter.deJong@...
> Tel:    +31 (0) 23 5698070
> Fax:    +31 (0) 23 5698099
> 
> 
> ***************************************************************************************
> This message may contain information which is confidential or privileged.
> If you are not the intended recipient, please advise the sender immediately
> by reply e-mail and delete this message and any attachments without retaining a copy.
> ***************************************************************************************
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users

-- 
Met vriendelijke groet/With kind regards,

Wouter de Jong
System-Administrator

CABLE & WIRELESS
Delivering the Internet promise(tm)
URL:    http://www.widexs.nl

Email:  Wouter.deJong@...
Tel:    +31 (0) 23 5698070
Fax:    +31 (0) 23 5698099


***************************************************************************************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments without retaining a copy.
***************************************************************************************

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

-----Original Message-----
From: James Yonan
To: Zhen Xu; 'openvpn-users@...'
Sent: 11/23/02 2:26 PM
Subject: Re: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD

Zhen Xu <zhen@...> 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

Zhen Xu <zhen@...> 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; 'openvpn-users@...'
> Sent: 11/23/02 2:26 PM
> Subject: Re: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD
> 
> Zhen Xu <zhen@...> 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
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



--

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; ''openvpn-users@...' '
Sent: 11/25/02 1:22 PM
Subject: RE: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD

Zhen Xu <zhen@...> 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; 'openvpn-users@...'
> Sent: 11/23/02 2:26 PM
> Subject: Re: [Openvpn-users] OpenVPN w/ TAP device on Linux/FreeBSD
> 
> Zhen Xu <zhen@...> 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
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



--

Tom Bentley <tbentley@...> said:

> I have two openvpn tunnels set up:
> 
> 1) Main office (static address on partial T1) to home office (static ip on
> ADSL).  RH 7.3, openvpn-1.3.1-1, which is working fine -- ping times in the
> 90-93 ms range, even when doing file transfers, remote management
> (pcanywhere), etc.  Quite zippy.  Using port 5000.
> 
> 2) Main office (as above) to branch office with Adelphia Powerlink with
> Motorola Surfboard modem, RH 7.3, openvpn-1.3.1-1 on port 4500 (have tried
> others).  Ping times start in the 250 ms range, and as soon as I try to do
> anything else (like ssh, or simply another ping) times jump to 2-3000 ms;
> trying to run PCAnywhere I have see ping times jump as far as 60000.

Try pings of different packet sizes (using -s) between both hosts, (a) over a tunnel and (b) using a direct path between public IP addresses (not over a tunnel).  We need to isolate whether the problem is with the link or with OpenVPN.

> 
> I've tried setting different udp-mtu values, but none seems to help.  I'm
> not blocking any icmp packets with firewall.  I've tried using a different
> computer on the remote office, and different nic's, to no avail.  No problem
> starting up the tunnel, so don't think the dynamic address is a factor.
> 
> Any idea what could be wrong, or what I could try?  Is this endemic to the
> cable modem?

I use a cable modem and have had no problems of this sort.

James

> 
> Sure would appreciate any help.  Thanks!
> 
> -----
> Tom Bentley
> tbentley@...
> 802-872-5525

Zhen Xu <zhen@...> 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

Bradley Alexander <storm@...> said:

> I need some advice. I have two laptops with wireless cards, and because
> of the WAP/WEP security issues, I figured I would run a point-to-point
> (ad hoc) connection, set up firewalling on both ends and set up openvpn
> for communication between. I'm just trying to get my brain around the
> networking scheme.
> 
> Consider my normal network on 192.168.1.0/24. I was going to place one
> laptop on the wire, then set up the ad-hoc network on, say,
> 192.168.2.0/30, giving me the two addresses. At this point, I was going
> to set up another /30 for the vpn, say 192.168.2.4, with the two
> addresses. I was planning on setting up firewall on both (an excuse to
> play with fwbuilder), that will block everything except for the port
> range for openvpn. I will let the wired laptop NAT everything.
> 
> Will something like this work? Is there a better way to do it?

Yes, this should work.  As you say, you should have separate subnets for (a) your wired "normal network", (b) your wireless laptop's subnet, and (c) the OpenVPN endpoint addresses.  The firewall entries on the wireless adaptors for both peers should exclude everything except the UDP port you are using for the OpenVPN link.

James

> -- 
> --Brad
> ============================================================================
> Bradley M. Alexander                |
> Debian Developer, Security Engineer |   storm [at] tux.org
> Debian/GNU Linux Developer          |   storm [at] debian.org
> ============================================================================
> Key fingerprints:
> DSA 0x54434E65: 37F6 BCA6 621D 920C E02E  E3C8 73B2 C019 5443 4E65
> RSA 0xC3BCBA91: 3F 0E 26 C1 90 14 AD 0A  C8 9C F0 93 75 A0 01 34
> ============================================================================
> As long as there are tests, there will be prayer in public schools.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



--

Malcolm Sole <Malcolm@...> said:

> Hi
> 
> I have just set up two red-hat 8.0 systems connecting to each other across
> the network, each is behind a firewall. Works very nicely. If I SSH to the
> remote system and ping the server firewall I get a response time of about
> 30ms. Pinging thru the tunnel gives a response time of about 600ms!
> 
> >From what I have read the performance should be pretty good, not 20 times
> worse. Any ideas as to where to look? I am quite new to this.

Yes, while pinging over a tunnel should show a slight performance degradation in relation to a direct ping (due to tunnel overhead), it is usually on the order of a few percent or less, certainly not 20 times.

Could you elaborate a bit more on your OpenVPN configuration and the commands you used to test tunnel and direct pings.

James