openvpn-devel Mailing List for OpenVPN

I had someone with a config error, and I asked them what version they were running, but since there was a config error, OpenVPN didn't show the version banner before the config failed to load. Turns out they had version 1.6, but I'm able to reproduce this in 2.0. It would have made it easier to figure out what version they were running and get them into 2.0 land. The config error was the "pull" option which 1.6 didn't have. I added the config option "eeegads" and I got the same non-banner error in 2.0. Thanks, -- -bk 

> James, do you put any preferance in what language/environment a gui for > OpenVPN is developed in, if you would distribute it together with the main > application in the future? These are my current thoughts on this: * Preferably, the language development tools and environment are open source, so there's no impediment to anyone building from source. * The total size of included libraries should be reasonable, so it doesn't excessively push up the size of the Windows self-installing exe. Having said that, I'm certainly going to be pragmatic here -- if someone puts together a great GUI agent that requires Visual C++ to build, I'm not going to belabor the point. On the other hand if it's written in Visual Basic and increases the Windows package size by 10 MB then I'm going to have to think twice about actually bundling it. But if it's up to standard, I'd still link to it from the website in a heartbeat. James 

Mathias Sundman wrote: > ... > No, I'm not used to OO languages, unfortunally. The reasons why I > started to write this in C was: > > 1) I only know how to code in C, VisualBasic and Assembler. Assembler is > out of the question, and I'm tired of VBs dependency for a bunch of > DLLs. I like beeing able to compile just one compact exe file and not > need to create an installation package just to get the application > working on another machine. > Ok, as far as I remember, you need one additional library for wxWindows. MFC, on the other hand, already comes with Windows. The binaries of both approaches will be very compact, while you may create larger programs when hacking all the standard work (messsage processing etc.) on your own. > 2) The egoistic one! I've though of learning to develop windows gui > applications in C for a long time, but never really got to it. Now I saw > an opportunity to write something useful and learn something I've wanted > to learn at the same time. > > 3) OpenVPN is written in traditional C, so if I for any reason would > like to integrate the gui into the openvpn binary, that would be very > easy if the gui itself was written in C. > I personally think that using different languages for different tasks in a project should be no problem, especially as C++ fits better to GUI modules. But I'm not the project manager :). > 4) I like traditional C, and dislike object oriented languages! Don't > ask me why, it's just my personal taste, and I can fully understand that > other prefer OO languages... > I'm also hacking most of my software in C - because it's kernel code or command line tools. But for GUI stuff, OO is definitely better suited and more efficient (due to re-use of components). > I do agree with you though that makeing it portable would have been > prefered, but just like you, I don't got that much spare time, so I'm > not sure that I want to spend it learning yet another development > environment. > Before discouraging you from doing anything at all, I would suggest that you start with a basic GUI tool (and feel a bit of the effort ;) ). If the interface to the OpenVPN core is specified and stable, extending the GUI capabilities can be done later as well - if required. Jan 

On Wed, 30 Jun 2004, Jan Kiszka wrote: >>> PS: Has anyone ever thought about some small GUI (taskbar icon with >>> some dialogs) for Windows, KDE, etc. to make the handling of multiple >>> configurations and the status display easier in a roadwarrior >>> scenario? >> >> I just started working on such an application last night. I'm kinda new >> to C programming in Windows so I ran into a little annoying problem >> right away though! > > While considering a similar interface for some other project, I once > took a closer look at wxWindows (http://www.wxwindows.org). Before you > start hacking your own message handling routines in C or switching over > to the Windows-only MFC library, this project may be worth some thoughts > because > > A) it capsulates most of the annoying GUI work, and > B) it opens to possiblity to port your work later to Linux as well! > > I think not only Windows users would appreciate a simple management > interface for OpenVPN clients very much... > > The only problem so far: You have to consider writing your program > object-oriented, i.e. in C++. Did you ever worked with some OO languages > (Java e.g.)? No, I'm not used to OO languages, unfortunally. The reasons why I started to write this in C was: 1) I only know how to code in C, VisualBasic and Assembler. Assembler is out of the question, and I'm tired of VBs dependency for a bunch of DLLs. I like beeing able to compile just one compact exe file and not need to create an installation package just to get the application working on another machine. 2) The egoistic one! I've though of learning to develop windows gui applications in C for a long time, but never really got to it. Now I saw an opportunity to write something useful and learn something I've wanted to learn at the same time. 3) OpenVPN is written in traditional C, so if I for any reason would like to integrate the gui into the openvpn binary, that would be very easy if the gui itself was written in C. 4) I like traditional C, and dislike object oriented languages! Don't ask me why, it's just my personal taste, and I can fully understand that other prefer OO languages... I do agree with you though that makeing it portable would have been prefered, but just like you, I don't got that much spare time, so I'm not sure that I want to spend it learning yet another development environment. James, do you put any preferance in what language/environment a gui for OpenVPN is developed in, if you would distribute it together with the main application in the future? On Wed, 30 Jun 2004, James Yonan wrote: >> I would furthermore suggest to discuss the required interface between >> the GUI and the OpenVPN daemon on this list. Starting and stopping would >> be possibly by just running the main binary, but I think a more >> sophisticated status and diagnosis interface requires some other >> mechanism (e.g. a local socket). Such an interface could furthermore >> prevent that the actual user who switches some configuration or just >> checks the status must own superuser privileges to start/stop a OpenVPN >> service and - even worse - read the secret key files. > > Yes, I would like to see some kind of interface for control of OpenVPN from > external programs. > > The mechanism of the interface would be a socket on *nix or a named pipe on > Windows. > > The interface would primarily be for interaction with a GUI agent and would > allow for: > > * Stop/Restart control > * Get status (like SIGUSR2) > * Provide authentication info That's great news. That was one of my concerns the other night, how to communicate with OpenVPN to check the status. -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS AB X NO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail 

On Tuesday 29 June 2004 11:06, Jan Kiszka wrote: > Hi all, > > here is a tiny patch to make revoke-crt and make-crl work seamlessly > within the easy-rsa environment. Seems that no one used it before ;) Thanks, I've merged for inclusion in beta8. James 

> I would furthermore suggest to discuss the required interface between > the GUI and the OpenVPN daemon on this list. Starting and stopping would > be possibly by just running the main binary, but I think a more > sophisticated status and diagnosis interface requires some other > mechanism (e.g. a local socket). Such an interface could furthermore > prevent that the actual user who switches some configuration or just > checks the status must own superuser privileges to start/stop a OpenVPN > service and - even worse - read the secret key files. Yes, I would like to see some kind of interface for control of OpenVPN from external programs. The mechanism of the interface would be a socket on *nix or a named pipe on Windows. The interface would primarily be for interaction with a GUI agent and would allow for: * Stop/Restart control * Get status (like SIGUSR2) * Provide authentication info James 

Mathias Sundman wrote: > On Tue, 29 Jun 2004, Jan Kiszka wrote: > >> PS: Has anyone ever thought about some small GUI (taskbar icon with >> some dialogs) for Windows, KDE, etc. to make the handling of multiple >> configurations and the status display easier in a roadwarrior >> scenario? Just a thought, I'm not saying I have the time for doing it >> - unfortunately. >> >> [If you reply, please add a CC, I'm not on the list] > > > I just started working on such an application last night. I'm kinda new > to C programming in Windows so I ran into a little annoying problem > right away though! > > I don't want to bother this list with basic C programming issues though, > but if someone is used to classic C programming and message handeling in > windows, please contact me offlist if you got a spare minute. A pointer > to a good mailing-list for discussion about classic C programming in > windows would be appreciated too. > While considering a similar interface for some other project, I once took a closer look at wxWindows (http://www.wxwindows.org). Before you start hacking your own message handling routines in C or switching over to the Windows-only MFC library, this project may be worth some thoughts because A) it capsulates most of the annoying GUI work, and B) it opens to possiblity to port your work later to Linux as well! I think not only Windows users would appreciate a simple management interface for OpenVPN clients very much... The only problem so far: You have to consider writing your program object-oriented, i.e. in C++. Did you ever worked with some OO languages (Java e.g.)? I would furthermore suggest to discuss the required interface between the GUI and the OpenVPN daemon on this list. Starting and stopping would be possibly by just running the main binary, but I think a more sophisticated status and diagnosis interface requires some other mechanism (e.g. a local socket). Such an interface could furthermore prevent that the actual user who switches some configuration or just checks the status must own superuser privileges to start/stop a OpenVPN service and - even worse - read the secret key files. Comments are welcome! Jan 

On Tue, 29 Jun 2004, Jan Kiszka wrote: > PS: Has anyone ever thought about some small GUI (taskbar icon with some > dialogs) for Windows, KDE, etc. to make the handling of multiple > configurations and the status display easier in a roadwarrior scenario? Just > a thought, I'm not saying I have the time for doing it - unfortunately. > > [If you reply, please add a CC, I'm not on the list] I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though! I don't want to bother this list with basic C programming issues though, but if someone is used to classic C programming and message handeling in windows, please contact me offlist if you got a spare minute. A pointer to a good mailing-list for discussion about classic C programming in windows would be appreciated too. -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS AB X NO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail 

Hi all, here is a tiny patch to make revoke-crt and make-crl work seamlessly within the easy-rsa environment. Seems that no one used it before ;) Jan PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] 

just FYI, OpenBSD now supports tap devices in -current. ----- Forwarded message from Claudio Jeker <cl...@cv...> ----- Date: Thu, 24 Jun 2004 22:09:03 -0600 (MDT) From: Claudio Jeker <cl...@cv...> Message-Id: <200...@cv...> To: sou...@cv... Subject: CVS: cvs.openbsd.org: src CVSROOT:	/cvs Module name:	src Changes by:	cl...@cv...	2004/06/24 22:09:03 Modified files:	share/man/man4 : tun.4	sys/net : if_tun.c if_tun.h Log message: Add tap aka layer 2 tunneling support to tun(4). It can be enabled by setting the link0 flag via ifconfig(8). OK markus@, canacar@ also tested by ish@ ----- End forwarded message ----- 

On Thursday 24 June 2004 12:04, Ullrich Dittmer wrote: > Hi, > > I would like to use openvpn (1.6) to connect my home pc direkt over the > proxy of my internet service provider (isp). At the server side I start= et > openvpn with > > openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 9 --proto tcp-se= rver > --lport 8080 --comp-lzo --link-mtu 296 > > and on the client: > > openvpn --remote luckyluke.homelinux.org --dev tun1 --ifconfig 10.4.0.2 > 10.4.0.1 --verb 9 --http-proxy 195.182.114.52 8080 --proto tcp-client > --rport 8080 --comp-lzo --link-mtu 296 --redirect-gateway IP minimum MTU are way more than 296. You are violating IP. --=20 vda 

Hi, I would like to use openvpn (1.6) to connect my home pc direkt over the proxy of my internet service provider (isp). At the server side I startet openvpn with openvpn --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 9 --proto tcp-server --lport 8080 --comp-lzo --link-mtu 296 and on the client: openvpn --remote luckyluke.homelinux.org --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --verb 9 --http-proxy 195.182.114.52 8080 --proto tcp-client --rport 8080 --comp-lzo --link-mtu 296 --redirect-gateway Now I have the following problem: Every minute the proxy sends a FIN to server and client and the tun1 interface closes down. After 10 seconds, the task restarted. Here's the log: Wed Jun 23 22:05:43 2004 us=748499 0: Current Parameter Settings: Wed Jun 23 22:05:43 2004 us=749073 1: config = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=749181 2: persist_config = DISABLED Wed Jun 23 22:05:43 2004 us=749277 3: persist_mode = 1 Wed Jun 23 22:05:43 2004 us=749372 4: show_ciphers = DISABLED Wed Jun 23 22:05:43 2004 us=749467 5: show_digests = DISABLED Wed Jun 23 22:05:43 2004 us=749582 6: genkey = DISABLED Wed Jun 23 22:05:43 2004 us=749680 7: askpass = DISABLED Wed Jun 23 22:05:43 2004 us=749775 8: show_tls_ciphers = DISABLED Wed Jun 23 22:05:43 2004 us=749870 9: proto = 2 Wed Jun 23 22:05:43 2004 us=749964 10: local = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=750060 11: remote = 'luckyluke.homelinux.org' Wed Jun 23 22:05:43 2004 us=750155 12: local_port = 5000 Wed Jun 23 22:05:43 2004 us=750250 13: remote_port = 8080 Wed Jun 23 22:05:43 2004 us=750345 14: remote_float = DISABLED Wed Jun 23 22:05:43 2004 us=750439 15: ipchange = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=750534 16: bind_local = ENABLED Wed Jun 23 22:05:43 2004 us=750644 17: dev = 'tun1' Wed Jun 23 22:05:43 2004 us=750739 18: dev_type = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=750833 19: dev_node = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=750928 20: tun_ipv6 = DISABLED Wed Jun 23 22:05:43 2004 us=751023 21: ifconfig_local = '10.4.0.2' Wed Jun 23 22:05:43 2004 us=751119 22: ifconfig_remote_netmask = '10.4.0.1' Wed Jun 23 22:05:43 2004 us=751215 23: ifconfig_noexec = DISABLED Wed Jun 23 22:05:43 2004 us=751309 24: ifconfig_nowarn = DISABLED Wed Jun 23 22:05:43 2004 us=751405 25: shaper = 0 Wed Jun 23 22:05:43 2004 us=751500 26: tun_mtu = 1300 Wed Jun 23 22:05:43 2004 us=751615 27: tun_mtu_defined = DISABLED Wed Jun 23 22:05:43 2004 us=751711 28: link_mtu = 296 Wed Jun 23 22:05:43 2004 us=751805 29: link_mtu_defined = ENABLED Wed Jun 23 22:05:43 2004 us=751900 30: tun_mtu_extra = 0 Wed Jun 23 22:05:43 2004 us=751994 31: tun_mtu_extra_defined = DISABLED Wed Jun 23 22:05:43 2004 us=752103 32: fragment = 0 Wed Jun 23 22:05:43 2004 us=752201 33: mtu_discover_type = -1 Wed Jun 23 22:05:43 2004 us=752297 34: mtu_test = 0 Wed Jun 23 22:05:43 2004 us=752391 35: mlock = DISABLED Wed Jun 23 22:05:43 2004 us=752486 36: inactivity_timeout = 0 Wed Jun 23 22:05:43 2004 us=752751 37: ping_send_timeout = 0 Wed Jun 23 22:05:43 2004 us=752857 38: ping_rec_timeout = 0 Wed Jun 23 22:05:43 2004 us=752953 39: ping_rec_timeout_action = 0 Wed Jun 23 22:05:43 2004 us=753049 40: ping_timer_remote = DISABLED Wed Jun 23 22:05:43 2004 us=753144 41: persist_tun = DISABLED Wed Jun 23 22:05:43 2004 us=753239 42: persist_local_ip = DISABLED Wed Jun 23 22:05:43 2004 us=753334 43: persist_remote_ip = DISABLED Wed Jun 23 22:05:43 2004 us=753429 44: persist_key = DISABLED Wed Jun 23 22:05:43 2004 us=753524 45: mssfix_defined = DISABLED Wed Jun 23 22:05:43 2004 us=753636 46: mssfix = 0 Wed Jun 23 22:05:43 2004 us=753732 47: passtos = DISABLED Wed Jun 23 22:05:43 2004 us=753827 48: resolve_retry_seconds = 0 Wed Jun 23 22:05:43 2004 us=753923 49: connect_retry_seconds = 5 Wed Jun 23 22:05:43 2004 us=754018 50: username = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754113 51: groupname = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754208 52: chroot_dir = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754302 53: cd_dir = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754397 54: writepid = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754491 55: up_script = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754620 56: down_script = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=754774 57: up_restart = DISABLED Wed Jun 23 22:05:43 2004 us=754870 58: daemon = DISABLED Wed Jun 23 22:05:43 2004 us=754965 59: inetd = 0 Wed Jun 23 22:05:43 2004 us=755059 60: log = DISABLED Wed Jun 23 22:05:43 2004 us=755154 61: nice = 0 Wed Jun 23 22:05:43 2004 us=755249 62: verbosity = 9 Wed Jun 23 22:05:43 2004 us=755344 63: mute = 0 Wed Jun 23 22:05:43 2004 us=755438 64: gremlin = DISABLED Wed Jun 23 22:05:43 2004 us=755533 65: occ = ENABLED Wed Jun 23 22:05:43 2004 us=755643 66: http_proxy_server = '195.182.114.52' Wed Jun 23 22:05:43 2004 us=755789 67: http_proxy_port = 8080 Wed Jun 23 22:05:43 2004 us=755886 68: http_proxy_auth_method = 'none' Wed Jun 23 22:05:43 2004 us=755982 69: http_proxy_auth_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=756077 70: http_proxy_retry = DISABLED Wed Jun 23 22:05:43 2004 us=756173 71: socks_proxy_server = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=756268 72: socks_proxy_port = 0 Wed Jun 23 22:05:43 2004 us=756363 73: socks_proxy_retry = DISABLED Wed Jun 23 22:05:43 2004 us=756458 74: comp_lzo = ENABLED Wed Jun 23 22:05:43 2004 us=756553 75: comp_lzo_adaptive = ENABLED Wed Jun 23 22:05:43 2004 us=756880 76: route_script = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=756979 77: route_default_gateway = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=757074 78: route_noexec = DISABLED Wed Jun 23 22:05:43 2004 us=757169 79: route_delay = 0 Wed Jun 23 22:05:43 2004 us=757264 80: route_delay_defined = DISABLED Wed Jun 23 22:05:43 2004 us=757369 81: [redirect_default_gateway] Wed Jun 23 22:05:43 2004 us=757465 82: shared_secret_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=757589 83: key_direction = 0 Wed Jun 23 22:05:43 2004 us=757687 84: ciphername_defined = ENABLED Wed Jun 23 22:05:43 2004 us=757782 85: ciphername = 'BF-CBC' Wed Jun 23 22:05:43 2004 us=757877 86: authname_defined = ENABLED Wed Jun 23 22:05:43 2004 us=757972 87: authname = 'SHA1' Wed Jun 23 22:05:43 2004 us=758067 88: keysize = 0 Wed Jun 23 22:05:43 2004 us=758162 89: replay = ENABLED Wed Jun 23 22:05:43 2004 us=758257 90: replay_window = 0 Wed Jun 23 22:05:43 2004 us=758351 91: replay_time = 0 Wed Jun 23 22:05:43 2004 us=758446 92: packet_id_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=758541 93: use_iv = ENABLED Wed Jun 23 22:05:43 2004 us=758652 94: test_crypto = DISABLED Wed Jun 23 22:05:43 2004 us=758747 95: tls_server = DISABLED Wed Jun 23 22:05:43 2004 us=758842 96: tls_client = DISABLED Wed Jun 23 22:05:43 2004 us=758937 97: key_method = 1 Wed Jun 23 22:05:43 2004 us=759032 98: ca_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759126 99: dh_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759221 100: cert_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759316 101: priv_key_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759411 102: cipher_list = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759506 103: tls_verify = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759618 104: tls_remote = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759714 105: crl_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=759809 106: tls_timeout = 2 Wed Jun 23 22:05:43 2004 us=759904 107: renegotiate_bytes = 0 Wed Jun 23 22:05:43 2004 us=760000 108: renegotiate_packets = 0 Wed Jun 23 22:05:43 2004 us=760095 109: renegotiate_seconds = 3600 Wed Jun 23 22:05:43 2004 us=760191 110: handshake_window = 60 Wed Jun 23 22:05:43 2004 us=760286 111: transition_window = 3600 Wed Jun 23 22:05:43 2004 us=760381 112: single_session = DISABLED Wed Jun 23 22:05:43 2004 us=760476 113: tls_auth_file = '[UNDEF]' Wed Jun 23 22:05:43 2004 us=760664 114: OpenVPN 1.6.0 i686-pc-linux-gnu [SSL] [LZO] built on Jun 15 2004 Wed Jun 23 22:05:43 2004 us=761776 115: ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext Wed Jun 23 22:05:43 2004 us=761968 116: LZO compression initialized Wed Jun 23 22:05:43 2004 us=782190 117: TUN/TAP device tun1 opened Wed Jun 23 22:05:43 2004 us=782487 118: /sbin/ifconfig tun1 10.4.0.2 pointopoint 10.4.0.1 mtu 293 Wed Jun 23 22:05:43 2004 us=792121 119: /sbin/route add -net 195.182.114.52 netmask 255.255.255.255 gw 10.34.140.117 Wed Jun 23 22:05:43 2004 us=800131 120: /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Wed Jun 23 22:05:43 2004 us=808380 121: /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.4.0.1 Wed Jun 23 22:05:43 2004 us=816059 122: Data Channel MTU parms [ L:296 D:296 EF:3 EB:19 ET:0 EL:0 ] Wed Jun 23 22:05:43 2004 us=816373 123: Local Options String: 'V3,dev-type tun,link-mtu 296,tun-mtu 293,proto TCPv4_CLIENT,ifconfig 10.4.0.1 10.4.0.2,comp-lzo' Wed Jun 23 22:05:43 2004 us=816510 124: Expected Remote Options String: 'V3,dev-type tun,link-mtu 296,tun-mtu 293,proto TCPv4_SERVER,ifconfig 10.4.0.2 10.4.0.1,comp-lzo' Wed Jun 23 22:05:43 2004 us=816979 125: Local Options hash (VER=V3): 'b41b7739' Wed Jun 23 22:05:43 2004 us=817125 126: Expected Remote Options hash (VER=V3): '58f586bf' Wed Jun 23 22:05:43 2004 us=817244 127: STREAM: RESET Wed Jun 23 22:05:43 2004 us=817343 128: STREAM: INIT maxlen=296 Wed Jun 23 22:05:43 2004 us=817452 129: Attempting to establish TCP connection with 195.182.114.52:8080 Wed Jun 23 22:05:45 2004 us=331755 130: TCP connection established with 195.182.114.52:8080 Wed Jun 23 22:05:45 2004 us=331869 131: Send to HTTP proxy: 'CONNECT luckyluke.homelinux.org:8080 HTTP/1.1 Host: luckyluke.homelinux.org User-Agent: Mozilla/4.1 (compatible; MSIE 5.0; Symbian OS; Nokia 6600;423) Opera 6.10 [de]' Wed Jun 23 22:05:47 2004 us=614502 132: HTTP proxy returned: 'HTTP/1.1 200 Connected' Wed Jun 23 22:05:49 2004 us=613771 133: TCPv4_CLIENT link local: [undef] Wed Jun 23 22:05:49 2004 us=613863 134: TCPv4_CLIENT link remote: 195.182.114.52:8080 Wed Jun 23 22:05:49 2004 us=613971 135: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:49 2004 us=614010 136: SELECT TR|tw|SR|sw 5/0 Wed Jun 23 22:05:54 2004 us=612959 137: select returned 0 Wed Jun 23 22:05:54 2004 us=613058 138: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:54 2004 us=613095 139: SELECT TR|tw|SR|sw 5/0 Wed Jun 23 22:05:58 2004 us=926460 140: select returned 1 Wed Jun 23 22:05:58 2004 us=926555 141: STREAM: GET NEXT len=296 Wed Jun 23 22:05:58 2004 us=926611 142: STREAM: ADD length_added=20 Wed Jun 23 22:05:58 2004 us=926649 143: STREAM: ADD returned TRUE, buf_len=18, residual_len=0 Wed Jun 23 22:05:58 2004 us=926681 144: STREAM: GET FINAL len=18 Wed Jun 23 22:05:58 2004 us=926713 145: STREAM: RESET Wed Jun 23 22:05:58 2004 us=926747 146: TCPv4_CLIENT read returned 18 Wed Jun 23 22:05:58 2004 us=926833 147: TCPv4_CLIENT READ [18] from 195.182.114.52:8080: DATA fa287f34 6bd4ef7a 812d56b8 d3afc545 9c00 Wed Jun 23 22:05:58 2004 us=926876 148: IP Address OK from 195.182.114.52:8080 Wed Jun 23 22:05:58 2004 us=926976 149: Peer Connection Initiated with 195.182.114.52:8080 Wed Jun 23 22:05:58 2004 us=927012 150: RECEIVED OCC_REQUEST Wed Jun 23 22:05:58 2004 us=927051 151: SENT OCC_REPLY Wed Jun 23 22:05:58 2004 us=927087 152: lzo_adaptive_compress_test: comp=0 total=0 Wed Jun 23 22:05:58 2004 us=927800 153: compress 113 -> 110 Wed Jun 23 22:05:58 2004 us=927901 154: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:58 2004 us=927939 155: SELECT tr|tw|SR|SW 1/0 Wed Jun 23 22:05:58 2004 us=927990 156: select returned 1 Wed Jun 23 22:05:58 2004 us=928313 157: TCPv4_CLIENT WRITE [111] to 195.182.114.52:8080: DATA 66001f28 7f346bd4 ef7a812d 56b8d3af c5459c01 56332c64 65762d74 7970652[more...] Wed Jun 23 22:05:58 2004 us=928352 158: STREAM: WRITE 111 offset=21 Wed Jun 23 22:05:58 2004 us=928579 159: TCPv4_CLIENT write returned 113 Wed Jun 23 22:05:58 2004 us=928638 160: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:58 2004 us=928675 161: SELECT TR|tw|SR|sw 1/0 Wed Jun 23 22:05:59 2004 us=928150 162: select returned 0 Wed Jun 23 22:05:59 2004 us=928241 163: SENT OCC_REQUEST Wed Jun 23 22:05:59 2004 us=928288 164: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:59 2004 us=928325 165: SELECT tr|tw|SR|SW 5/0 Wed Jun 23 22:05:59 2004 us=928365 166: select returned 1 Wed Jun 23 22:05:59 2004 us=928455 167: TCPv4_CLIENT WRITE [18] to 195.182.114.52:8080: DATA fa287f34 6bd4ef7a 812d56b8 d3afc545 9c00 Wed Jun 23 22:05:59 2004 us=928491 168: STREAM: WRITE 18 offset=21 Wed Jun 23 22:05:59 2004 us=928544 169: TCPv4_CLIENT write returned 20 Wed Jun 23 22:05:59 2004 us=928587 170: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:05:59 2004 us=928623 171: SELECT TR|tw|SR|sw 10/0 Wed Jun 23 22:06:01 2004 us=655905 172: select returned 1 Wed Jun 23 22:06:01 2004 us=656000 173: STREAM: GET NEXT len=296 Wed Jun 23 22:06:01 2004 us=656053 174: STREAM: ADD length_added=113 Wed Jun 23 22:06:01 2004 us=656091 175: STREAM: ADD returned TRUE, buf_len=111, residual_len=0 Wed Jun 23 22:06:01 2004 us=656125 176: STREAM: GET FINAL len=111 Wed Jun 23 22:06:01 2004 us=656156 177: STREAM: RESET Wed Jun 23 22:06:01 2004 us=656190 178: TCPv4_CLIENT read returned 111 Wed Jun 23 22:06:01 2004 us=656451 179: TCPv4_CLIENT READ [111] from 195.182.114.52:8080: DATA 66001f28 7f346bd4 ef7a812d 56b8d3af c5459c01 56332c64 65762d74 7970652[more...] Wed Jun 23 22:06:01 2004 us=656495 180: IP Address OK from 195.182.114.52:8080 Wed Jun 23 22:06:01 2004 us=656568 181: decompress 110 -> 113 Wed Jun 23 22:06:01 2004 us=656606 182: RECEIVED OCC_REPLY Wed Jun 23 22:06:01 2004 us=656662 183: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:01 2004 us=656698 184: SELECT TR|tw|SR|sw 31536000/0 Wed Jun 23 22:06:17 2004 us=884200 185: select returned 1 Wed Jun 23 22:06:17 2004 us=884295 186: STREAM: GET NEXT len=296 Wed Jun 23 22:06:17 2004 us=884345 187: Connection reset, restarting [0] Wed Jun 23 22:06:17 2004 us=884508 188: PID packet_id_free Wed Jun 23 22:06:17 2004 us=884551 189: Closing TCP/UDP socket Wed Jun 23 22:06:17 2004 us=884762 190: /sbin/route del -net 195.182.114.52 netmask 255.255.255.255 Wed Jun 23 22:06:17 2004 us=892877 191: /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Wed Jun 23 22:06:17 2004 us=901185 192: /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.34.140.117 Wed Jun 23 22:06:17 2004 us=909363 193: Closing TUN/TAP device Wed Jun 23 22:06:18 2004 us=14129 194: Restart pause, 10 second(s) Wed Jun 23 22:06:28 2004 us=15952 195: ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext Wed Jun 23 22:06:28 2004 us=16087 196: LZO compression initialized Wed Jun 23 22:06:28 2004 us=79514 197: TUN/TAP device tun1 opened Wed Jun 23 22:06:28 2004 us=79706 198: /sbin/ifconfig tun1 10.4.0.2 pointopoint 10.4.0.1 mtu 293 Wed Jun 23 22:06:28 2004 us=88885 199: /sbin/route add -net 195.182.114.52 netmask 255.255.255.255 gw 10.34.140.117 Wed Jun 23 22:06:28 2004 us=96560 200: /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Wed Jun 23 22:06:28 2004 us=104189 201: /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.4.0.1 Wed Jun 23 22:06:28 2004 us=112408 202: Data Channel MTU parms [ L:296 D:296 EF:3 EB:19 ET:0 EL:0 ] Wed Jun 23 22:06:28 2004 us=112719 203: Local Options String: 'V3,dev-type tun,link-mtu 296,tun-mtu 293,proto TCPv4_CLIENT,ifconfig 10.4.0.1 10.4.0.2,comp-lzo' Wed Jun 23 22:06:28 2004 us=112845 204: Expected Remote Options String: 'V3,dev-type tun,link-mtu 296,tun-mtu 293,proto TCPv4_SERVER,ifconfig 10.4.0.2 10.4.0.1,comp-lzo' Wed Jun 23 22:06:28 2004 us=113005 205: Local Options hash (VER=V3): 'b41b7739' Wed Jun 23 22:06:28 2004 us=113141 206: Expected Remote Options hash (VER=V3): '58f586bf' Wed Jun 23 22:06:28 2004 us=113256 207: STREAM: RESET Wed Jun 23 22:06:28 2004 us=113353 208: STREAM: INIT maxlen=296 Wed Jun 23 22:06:28 2004 us=113463 209: Attempting to establish TCP connection with 195.182.114.52:8080 Wed Jun 23 22:06:29 2004 us=476368 210: TCP connection established with 195.182.114.52:8080 Wed Jun 23 22:06:29 2004 us=476462 211: Send to HTTP proxy: 'CONNECT luckyluke.homelinux.org:8080 HTTP/1.1 Host: luckyluke.homelinux.org User-Agent: Mozilla/4.1 (compatible; MSIE 5.0; Symbian OS; Nokia 6600;423) Opera 6.10 [de]' Wed Jun 23 22:06:32 2004 us=13060 212: HTTP proxy returned: 'HTTP/1.1 200 Connected' Wed Jun 23 22:06:34 2004 us=11987 213: TCPv4_CLIENT link local: [undef] Wed Jun 23 22:06:34 2004 us=12083 214: TCPv4_CLIENT link remote: 195.182.114.52:8080 Wed Jun 23 22:06:34 2004 us=12150 215: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:34 2004 us=12187 216: SELECT TR|tw|SR|sw 5/0 Wed Jun 23 22:06:39 2004 us=11210 217: select returned 0 Wed Jun 23 22:06:39 2004 us=11313 218: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:39 2004 us=11400 219: SELECT TR|tw|SR|sw 5/0 Wed Jun 23 22:06:42 2004 us=242211 220: select returned 1 Wed Jun 23 22:06:42 2004 us=242303 221: STREAM: GET NEXT len=296 Wed Jun 23 22:06:42 2004 us=242356 222: STREAM: ADD length_added=20 Wed Jun 23 22:06:42 2004 us=242395 223: STREAM: ADD returned TRUE, buf_len=18, residual_len=0 Wed Jun 23 22:06:42 2004 us=242428 224: STREAM: GET FINAL len=18 Wed Jun 23 22:06:42 2004 us=242459 225: STREAM: RESET Wed Jun 23 22:06:42 2004 us=242493 226: TCPv4_CLIENT read returned 18 Wed Jun 23 22:06:42 2004 us=242579 227: TCPv4_CLIENT READ [18] from 195.182.114.52:8080: DATA fa287f34 6bd4ef7a 812d56b8 d3afc545 9c00 Wed Jun 23 22:06:42 2004 us=242623 228: IP Address OK from 195.182.114.52:8080 Wed Jun 23 22:06:42 2004 us=242728 229: Peer Connection Initiated with 195.182.114.52:8080 Wed Jun 23 22:06:42 2004 us=242764 230: RECEIVED OCC_REQUEST Wed Jun 23 22:06:42 2004 us=242804 231: SENT OCC_REPLY Wed Jun 23 22:06:42 2004 us=242840 232: lzo_adaptive_compress_test: comp=0 total=0 Wed Jun 23 22:06:42 2004 us=243311 233: compress 113 -> 110 Wed Jun 23 22:06:42 2004 us=243387 234: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:42 2004 us=243426 235: SELECT tr|tw|SR|SW 2/0 Wed Jun 23 22:06:42 2004 us=243479 236: select returned 1 Wed Jun 23 22:06:42 2004 us=243769 237: TCPv4_CLIENT WRITE [111] to 195.182.114.52:8080: DATA 66001f28 7f346bd4 ef7a812d 56b8d3af c5459c01 56332c64 65762d74 7970652[more...] Wed Jun 23 22:06:42 2004 us=243808 238: STREAM: WRITE 111 offset=21 Wed Jun 23 22:06:42 2004 us=244041 239: TCPv4_CLIENT write returned 113 Wed Jun 23 22:06:42 2004 us=244099 240: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:42 2004 us=244135 241: SELECT TR|tw|SR|sw 2/0 Wed Jun 23 22:06:44 2004 us=243415 242: select returned 0 Wed Jun 23 22:06:44 2004 us=243508 243: SENT OCC_REQUEST Wed Jun 23 22:06:44 2004 us=243557 244: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:44 2004 us=243594 245: SELECT tr|tw|SR|SW 5/0 Wed Jun 23 22:06:44 2004 us=243634 246: select returned 1 Wed Jun 23 22:06:44 2004 us=243724 247: TCPv4_CLIENT WRITE [18] to 195.182.114.52:8080: DATA fa287f34 6bd4ef7a 812d56b8 d3afc545 9c00 Wed Jun 23 22:06:44 2004 us=243760 248: STREAM: WRITE 18 offset=21 Wed Jun 23 22:06:44 2004 us=243946 249: TCPv4_CLIENT write returned 20 Wed Jun 23 22:06:44 2004 us=243994 250: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:44 2004 us=244030 251: SELECT TR|tw|SR|sw 10/0 Wed Jun 23 22:06:45 2004 us=389558 252: select returned 1 Wed Jun 23 22:06:45 2004 us=389652 253: STREAM: GET NEXT len=296 Wed Jun 23 22:06:45 2004 us=389704 254: STREAM: ADD length_added=113 Wed Jun 23 22:06:45 2004 us=389743 255: STREAM: ADD returned TRUE, buf_len=111, residual_len=0 Wed Jun 23 22:06:45 2004 us=389775 256: STREAM: GET FINAL len=111 Wed Jun 23 22:06:45 2004 us=389806 257: STREAM: RESET Wed Jun 23 22:06:45 2004 us=389841 258: TCPv4_CLIENT read returned 111 Wed Jun 23 22:06:45 2004 us=390102 259: TCPv4_CLIENT READ [111] from 195.182.114.52:8080: DATA 66001f28 7f346bd4 ef7a812d 56b8d3af c5459c01 56332c64 65762d74 7970652[more...] Wed Jun 23 22:06:45 2004 us=390145 260: IP Address OK from 195.182.114.52:8080 Wed Jun 23 22:06:45 2004 us=390188 261: decompress 110 -> 113 Wed Jun 23 22:06:45 2004 us=390248 262: RECEIVED OCC_REPLY Wed Jun 23 22:06:45 2004 us=390305 263: STREAM: SET NEXT, buf=[22,0] next=[22,296] len=-1 maxlen=296 Wed Jun 23 22:06:45 2004 us=390341 264: SELECT TR|tw|SR|sw 31536000/0 Wed Jun 23 22:07:00 2004 us=962029 265: select returned 1 Wed Jun 23 22:07:00 2004 us=962127 266: STREAM: GET NEXT len=296 Wed Jun 23 22:07:00 2004 us=962175 267: Connection reset, restarting [0] Wed Jun 23 22:07:00 2004 us=962284 268: PID packet_id_free Wed Jun 23 22:07:00 2004 us=962325 269: Closing TCP/UDP socket Wed Jun 23 22:07:00 2004 us=962528 270: /sbin/route del -net 195.182.114.52 netmask 255.255.255.255 Wed Jun 23 22:07:00 2004 us=970466 271: /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Wed Jun 23 22:07:00 2004 us=978219 272: /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.34.140.117 Wed Jun 23 22:07:00 2004 us=985924 273: Closing TUN/TAP device Wed Jun 23 22:07:01 2004 us=88914 274: Restart pause, 10 second(s) If I ping during the tun1 device, I sniffed a RST and then the connection breaks. Have you got any ideas, why and how I can solve the problem? Is it because of the "CONNECT" Request in the sources? Greetings Ullrich ____________________________________________________ Aufnehmen, abschicken, nah sein - So einfach ist WEB.DE Video-Mail: http://freemail.web.de/?mc=021200 

> Pavlin, > > Thanks for the patch. Is there any reason why someone might not want to have > multicast turned on by default, i.e. is there any chance this could break > something? Should it be controllable by an option? James, I consider the IFF_MULTICAST flag as a capability flag of an interface. E.g., if an interface is capable of supporting multicast, then it should have this flag set. For example, it appears that on FreeBSD the flag is always set for the tun interfaces created by openvpn, so doing the same thing with OpenBSD would make things more consistent. In addition, the flag cannot be turned off on physical interfaces by programs like "ifconfig". Of course, given the flexibility you have with openvpn you can always add the option to explicitly turn the flag off. However, off the top of my head I cannot think of any good reasons why someone may want to do that. Also, I don't think enabling the flag will break anything. Nevertheless,I am neutral to adding such option and it is up to the openvpn developers :) Though, I'd recommend that it is ON by default. Thanks, Pavlin > > James > > Pavlin Radoslavov <pa...@ic...> said: > > > Hi! > > > > [OS: OpenBSD-3.5] > > [openvpn: 2.0_beta5, 1.5] > > > > It appears that openvpn doesn't enable the multicast flag for the > > tun interface on OpenBSD (on FreeBSD for example, the flag is always > > set). E.g., if I use: > > > > openvpn --local <...> --remote <...> --ifconfig <...> <...> --dev tun0 > > > > Then the interface doesn't have the MULTICAST flag set: > > > > tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500 > > inet ... > > > > I believe the following simple patch (against 2.0_beta5) fixes the > > problem. > > > > Thanks, > > Pavlin > > > > --- tun.c.orgSun Jun 13 00:34:28 2004 > > +++ tun.c	Tue Jun 15 23:24:58 2004 > > @@ -1274,6 +1274,24 @@ > > open_tun (const char *dev, const char *dev_type, const char *dev_node, bool > ipv6, struct tuntap *tt) > > { > > open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt); > > + > > + /* Enable multicast on the interface */ > > + if (tt->fd >= 0) > > + { > > + struct tuninfo info; > > + > > + if (ioctl (tt->fd, TUNGIFINFO, &info) < 0) { > > +	msg (M_WARN | M_ERRNO, "Can't get interface info: %s", > > + strerror(errno)); > > + } > > + > > + info.flags |= IFF_MULTICAST; > > + > > + if (ioctl (tt->fd, TUNSIFINFO, &info) < 0) { > > +	msg (M_WARN | M_ERRNO, "Can't set interface info: %s", > > + strerror(errno)); > > + } > > + } > > } > > > > void > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > > _______________________________________________ > > Openvpn-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > > > > -- > > > 

Pavlin, Thanks for the patch. Is there any reason why someone might not want to have multicast turned on by default, i.e. is there any chance this could break something? Should it be controllable by an option? James Pavlin Radoslavov <pa...@ic...> said: > Hi! > > [OS: OpenBSD-3.5] > [openvpn: 2.0_beta5, 1.5] > > It appears that openvpn doesn't enable the multicast flag for the > tun interface on OpenBSD (on FreeBSD for example, the flag is always > set). E.g., if I use: > > openvpn --local <...> --remote <...> --ifconfig <...> <...> --dev tun0 > > Then the interface doesn't have the MULTICAST flag set: > > tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500 > inet ... > > I believe the following simple patch (against 2.0_beta5) fixes the > problem. > > Thanks, > Pavlin > > --- tun.c.orgSun Jun 13 00:34:28 2004 > +++ tun.c	Tue Jun 15 23:24:58 2004 > @@ -1274,6 +1274,24 @@ > open_tun (const char *dev, const char *dev_type, const char *dev_node, bool ipv6, struct tuntap *tt) > { > open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt); > + > + /* Enable multicast on the interface */ > + if (tt->fd >= 0) > + { > + struct tuninfo info; > + > + if (ioctl (tt->fd, TUNGIFINFO, &info) < 0) { > +	msg (M_WARN | M_ERRNO, "Can't get interface info: %s", > + strerror(errno)); > + } > + > + info.flags |= IFF_MULTICAST; > + > + if (ioctl (tt->fd, TUNSIFINFO, &info) < 0) { > +	msg (M_WARN | M_ERRNO, "Can't set interface info: %s", > + strerror(errno)); > + } > + } > } > > void > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > -- 

Hi! [OS: OpenBSD-3.5] [openvpn: 2.0_beta5, 1.5] It appears that openvpn doesn't enable the multicast flag for the tun interface on OpenBSD (on FreeBSD for example, the flag is always set). E.g., if I use: openvpn --local <...> --remote <...> --ifconfig <...> <...> --dev tun0 Then the interface doesn't have the MULTICAST flag set: tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500 inet ... I believe the following simple patch (against 2.0_beta5) fixes the problem. Thanks, Pavlin --- tun.c.orgSun Jun 13 00:34:28 2004 +++ tun.c	Tue Jun 15 23:24:58 2004 @@ -1274,6 +1274,24 @@ open_tun (const char *dev, const char *dev_type, const char *dev_node, bool ipv6, struct tuntap *tt) { open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt); + + /* Enable multicast on the interface */ + if (tt->fd >= 0) + { + struct tuninfo info; + + if (ioctl (tt->fd, TUNGIFINFO, &info) < 0) { +	msg (M_WARN | M_ERRNO, "Can't get interface info: %s", + strerror(errno)); + } + + info.flags |= IFF_MULTICAST; + + if (ioctl (tt->fd, TUNSIFINFO, &info) < 0) { +	msg (M_WARN | M_ERRNO, "Can't set interface info: %s", + strerror(errno)); + } + } } void 

On Monday 14 June 2004 20:49, James Yonan wrote: > Torge Szczepanek <ope...@sz...> said: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi! > > > > I am currently trying out OpenVPN 2.0 beta 4 using server mode. > > > > My config on the server looks like this: > > > > dev tun > > mode server > > ifconfig 192.168.100.1 192.168.100.2 > > ifconfig-pool 192.168.100.4 192.168.100.254 > > push "route 192.168.100.1 255.255.255.255" > > route 192.168.100.0 255.255.255.0 > > [...] > > > > Everything works fine as expected. (Which is really great. I appreciate > > the good work done here) > > > > I am wondering why there is a subnet of size /30 assigned to the client. > > I would expect a Point-to-Point device to receive only one ip adress and > > not a /30 subnet. > > This is done for the benefit of OSes (such as Windows) which don't support > true point-to-point tun interfaces. > > The Windows TAP-Win32 driver supports tun interface emulation only. What > that means is that the driver can talk to tun interfaces on other OSes, but > from the perspective of Windows, it sees the tun interface as a virtual > ethernet interface having a subnet mask of 255.255.255.254, containing the > two point-to-point interfaces, a network address, and a broadcast address. 255.255.255.252 (252 == 0xFC == 11111100 binary) -- vda 

On Monday 14 June 2004 19:49, you wrote: > This is done for the benefit of OSes (such as Windows) which don't support > true point-to-point tun interfaces. Ok. You said enough. :-) > any OS can transparently connect to an OpenVPN server which is also running > on any OS, and the /30 subnet standardization was necessary to accomplish > that. I see. > For one, you don't need to use --ifconfig-pool, you could use DHCP for > example. Or you could use --dev tap. I'll try this out. > This maximum can be trivially increased, though I don't think most users > will be connecting 65536 clients to a single OpenVPN server instance :) I asked since I put much work into getting pptp to work with more than 100 or 255 authenticated users. But pptp is using a different model, where a ppp device is created for every logged in user. There you get quite some difficulties running with more than 100 users (or devices) and then later on with more than 255 users. > Some people might claim that using /30 subnets wastes IPv4 addresses, > though I don't think this argument holds much water because these addresses > are mostly (but not always) taken from private address blocks such as > 10.x.x.x where millions of free addresses are always available. I am using PPTP (and maybe later on openvpn) for authentication of users in a lan for internet access. I assign official IPs to all these users. Therefore I really have to limit official IP usage to 1 adress per authenticated user. Otherwise RIPE would kill me. :-) Thanks for your answer! Torge 

Torge Szczepanek <ope...@sz...> said: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I am currently trying out OpenVPN 2.0 beta 4 using server mode. > > My config on the server looks like this: > > dev tun > mode server > ifconfig 192.168.100.1 192.168.100.2 > ifconfig-pool 192.168.100.4 192.168.100.254 > push "route 192.168.100.1 255.255.255.255" > route 192.168.100.0 255.255.255.0 > [...] > > Everything works fine as expected. (Which is really great. I appreciate the > good work done here) > > I am wondering why there is a subnet of size /30 assigned to the client. I > would expect a Point-to-Point device to receive only one ip adress and not > a /30 subnet. This is done for the benefit of OSes (such as Windows) which don't support true point-to-point tun interfaces. The Windows TAP-Win32 driver supports tun interface emulation only. What that means is that the driver can talk to tun interfaces on other OSes, but from the perspective of Windows, it sees the tun interface as a virtual ethernet interface having a subnet mask of 255.255.255.254, containing the two point-to-point interfaces, a network address, and a broadcast address. One of the goals of --mode server in OpenVPN 2.0 is that clients running any OS can transparently connect to an OpenVPN server which is also running on any OS, and the /30 subnet standardization was necessary to accomplish that. > tun0 Protokoll:Punkt-zu-Punkt Verbindung > inet Adresse:192.168.100.6 P-z-P:192.168.100.5 > Maske:255.255.255.255 > > The netmask is also not which one would expect for a /30 network. The server side tun netmask will be 255.255.255.255 except on Windows where it will be 255.255.255.252 > I have some servers running with lots of ppp devices. I am assigning also > adresses out of a pool. The two addresses do not lie within the same subnet. > > ppp138 Link encap:Point-to-Point Protocol > inet addr:192.168.1.31 P-t-P:10.3.14.223 Mask:255.255.255.255 > > Is there any good reason for this /30 assignment? > Is there a config option to change this behaviour (I didn't find one)? For one, you don't need to use --ifconfig-pool, you could use DHCP for example. Or you could use --dev tap. You could also change the code by passing IFCONFIG_POOL_INDIV instead of IFCONFIG_POOL_30NET to ifconfig_pool_init in multi.c -- but at that point you'll be on your own. Windows compatibility will certainly break as well as possibly other things. > How many IPs can be assigned within a pool? > > I found: > > #define IFCONFIG_POOL_MAX 65536 > > in pool.h > > Has anyone tested this beyond a class-C network? This maximum can be trivially increased, though I don't think most users will be connecting 65536 clients to a single OpenVPN server instance :) Some people might claim that using /30 subnets wastes IPv4 addresses, though I don't think this argument holds much water because these addresses are mostly (but not always) taken from private address blocks such as 10.x.x.x where millions of free addresses are always available. James 

=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I am currently trying out OpenVPN 2.0 beta 4 using server mode. My config on the server looks like this: dev tun mode server ifconfig 192.168.100.1 192.168.100.2 ifconfig-pool 192.168.100.4 192.168.100.254 push "route 192.168.100.1 255.255.255.255" route 192.168.100.0 255.255.255.0 [...] Everything works fine as expected. (Which is really great. I appreciate the= =20 good work done here) I am wondering why there is a subnet of size /30 assigned to the client. I= =20 would expect a Point-to-Point device to receive only one ip adress and not= =20 a /30 subnet. tun0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:192.168.100.6 P-z-P:192.168.100.5 =20 Maske:255.255.255.255 The netmask is also not which one would expect for a /30 network. I have some servers running with lots of ppp devices. I am assigning also=20 adresses out of a pool. The two addresses do not lie within the same subnet. ppp138 Link encap:Point-to-Point Protocol inet addr:192.168.1.31 P-t-P:10.3.14.223 Mask:255.255.255.255 Is there any good reason for this /30 assignment? Is there a config option to change this behaviour (I didn't find one)? How many IPs can be assigned within a pool?=20 I found: #define IFCONFIG_POOL_MAX 65536 in pool.h Has anyone tested this beyond a class-C network? Torge =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAyKSYosmtDiD9dbIRAq95AKCL7mem4ivtrcbLbP7tFs1GdHodmgCfeQJV O4ZsPqwgie/iAkry/8G8tvg=3D =3D7uEu =2D----END PGP SIGNATURE----- 

> >> I had a few of my users ask why the Windows OpenVPN connection was in a > >> Command Prompt window and not just a Systray Icon with a status window. > I think it would be cleanest if such a gui could be created as a > standalone application that just calls the openvpn binary. What I'm not > clear about with such a setup is how the gui should be able to communicate > with openvpn to check it's status, and recieve error messages? I'm actually considering a very simple SysTray icon which would print all the STDOUT messages to a little textbox rather than a cmd prompt window. I don't think it would be terrible difficult, and adding in a little "Close Session" button which mimics the F4 (SIGTERM?) action would ne simple. You'd still get all the messages and such, but it would minimize to the systray rather than a cmd prompt. Any thoughts out there? Developers? Should I waste my time? -- -bk 

Quoting Denis Vlasenko <vd...@po...>: >> I had a few of my users ask why the Windows OpenVPN connection was in a >> Command Prompt window and not just a Systray Icon with a status window. > > It can be run as a service. It is documented. I think implementing a systray icon to controll OpenVPN would be a great feature. Running OpenVPN as a service does not make it much easier or more userfriendly than the normal way, except that you don't have to see the console window. As a technician I love the way OpenVPN is designed and operate today, but my users also ask for a gui to controll OpenVPN as the console window just scares them! I think it would be cleanest if such a gui could be created as a standalone application that just calls the openvpn binary. What I'm not clear about with such a setup is how the gui should be able to communicate with openvpn to check it's status, and recieve error messages? -- _____________________________________________________________ Mathias Sundman (^) ASCII Ribbon Campaign NILINGS AB X NO HTML/RTF in e-mail Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail 

Quoting Denis Vlasenko <vd...@po...>: > > I had a few of my users ask why the Windows OpenVPN connection was in a > > Command Prompt window and not just a Systray Icon with a status window. > It can be run as a service. It is documented. I guess this makes sense for the server/gateway side, but I don't think I want to force my users to have to start and stop a service each time they want to connect to the office VPN, right-clicking is a pretty cool option for starting the VPN. Furthermore, since they still have to enter their password to the client certificate, I'm not sure how they would be prompted for such as a service is not really designed to interact with the desktop in such a way. I can't find the documentation on the service setup, I'll keep searching, but I'm pretty sure that the service setup is intended for the server/gateway side of things. Thanks, bk 

On Saturday 12 June 2004 08:16, Brandon Knitter wrote: > I had a few of my users ask why the Windows OpenVPN connection was in a > Command Prompt window and not just a Systray Icon with a status window. > > You know, that's a great question. I was going to look into the code and > see what it would take, but of course I do that I figured I'd ask if anyone > looked into that yet. > > I'm sure it's not a high priority, so if I did it, would you like me to > diff against HEAD or a specific version/tag? 2.0b4? > > Thanks for the insight! It can be run as a service. It is documented. -- vda 

I had a few of my users ask why the Windows OpenVPN connection was in a Command Prompt window and not just a Systray Icon with a status window. You know, that's a great question. I was going to look into the code and see what it would take, but of course I do that I figured I'd ask if anyone looked into that yet. I'm sure it's not a high priority, so if I did it, would you like me to diff against HEAD or a specific version/tag? 2.0b4? Thanks for the insight! -- -bk 

I'm not on this list, so if you want to talk to me, include my email or catch me on the users list. I found something i consider a bug, and i can reproduce it every time i try. I have only tried with openvpn 2.0 beta4 for windows. The problem only arrives when i force the closure of the client. If it is allowed to time out, it works as it should. I run a script like this: aragorn:/etc/openvpn/windows# cat start-vpn-tunnel.bat openvpn.exe --askpass --config laerdal.vpn pause aragorn:/etc/openvpn/windows# cat laerdal.vpn ######################################### # Sample client-side OpenVPN config file # for connecting to multi-client server. # # The server can be pinged at 10.8.0.1. # # This configuration can be used by multiple # clients, however each client should have # its own cert and key files. # # tun-style tunnel port 5000 dev tun remote <server address> # TLS parms tls-client ca ca.crt cert _-USER-_.crt key _-USER-_.key # This parm is required for connecting # to a multi-client server. It tells # the client to accept options which # the server pushes to us. pull verb 1 When i use the x button in the top right corner of the start-vpn-tunnel.bat window, windows no longer have a default route, leaving the computer unuseable :( aragorn:/etc/openvpn# cat remotevpn.conf ######################################## # Sample OpenVPN config file for # multi-client udp server # # tun-style tunnel # # modified by Jon Bendtsen to fit Laerdal's case of remote windows users # and local wifi windows users. # bind to the "public" interface local 192.168.1.2 port 5000 dev tun # TLS parms tls-server ca /etc/openvpn/ca.crt cert /etc/openvpn/aragorn_remotevpn.crt key /etc/openvpn/aragorn_remotevpn.key dh /etc/openvpn/dh1024.pem crl-verify /etc/openvpn/bad-certificates-crl.pem # Tell OpenVPN to be a multi-client udp server mode server # openvpn data are not swapped to disk mlock # allow clients to connect to each other faster client-to-client # The server's virtual endpoints ifconfig 10.8.0.1 10.8.0.2 # Pool of /30 subnets to be allocated to clients. # When a client connects, an --ifconfig command # will be automatically generated and pushed back to # the client. ifconfig-pool 10.8.0.4 10.8.0.255 # Push route to client to bind it to our local # virtual endpoint. push "route 10.8.0.1 255.255.255.255" # Delete client instances after some period of inactivity. inactive 600 # ping once every minute when there is no trafic ping 60 # Route the --ifconfig pool range into the OpenVPN server. route 10.8.0.0 255.255.255.0 # The server doesn't need privileges user nobody group nogroup # options pushed to the windows clients. push "ping 60" push "inactive 600" push "redirect-gateway local" #push "redirect-gateway" push "ip-win32 dynamic" push "tap-sleep 4" push "dhcp-option DNS 192.168.119.131" push "dhcp-option WINS 192.168.119.131" push "dhcp-option NTP 192.168.119.131" push "dhcp-option NBT 2" push "dhcp-option DOMAIN laerdal.global" # Set NetBIOS over TCP/IP Node type. 2 = p-node (point-to-point name queries to a WINS server ################################################# i have tried if this problem also arrives with	push "redirect-gateway" and it does. If i close the window, the old default gateway is never restored. JonB