Problems accessing shares through OpenVPN
Hello!If one installs OpenVPN client to Windows XP (regardless of SP-level) and connects it to OpenVPN server then (sometimes after a reboot, sometimes straight away) the other machine on the other end can not access Windows XP shares if the connecting machine has NetBIOS over TCP/IP (port 139) disabled. The error message is "No network provider accepted the given network path."Pinging works and all firewalls are off. Sniffing the OpenVPN adapter reveals that XP responds to port 445 with an RST packet (also known as connection refused).Unchecking OpenVPN adapter's File and Printer Server service and rechecking it makes it work (i.e. XP starts to respond normally on port 445 on OpenVPN adapter too). Print Spooler service has to be restarted too. But all this only lasts until next computer restart.This would imply that File and Printer Sharing service is not bound to OpenVPN adapter but netstat -aon | find ":445" shows 0.0.0.0:445 is correctly bound to System 4 process.Gert Döring from the openvpn-devel mailing list commented on the subject: 2010/6/26 Gert Doering <Email removed for privacy>Hi,On Wed, Jun 23, 2010 at 10:50:45PM +0300, Henno Täht wrote:> On Wed, Jun 23, 2010 at 22:48, Gert Doering <Email removed for privacy> wrote:> > On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:> > > assigns a 169.254 address. If this works for you as well then maybe the> > > tap-win32 developers can dive deeper into this and find out why windows> > > treats the 'always connected' adapter differently from an 'application> > > controlled' adapter .> >> > I'd assume that windows services are not "bound" to "dynamic" interfaces...>> By dynamic interface you mean an interface which has "Obtain IP address> automatically" set?No, I was thinking about interfaces that sort of "are not always there".But that was a misconception, the TAP interface *is* always there - what'sapplication controlled is whether it's "connected to an ethernet cable"(virtual, of course) all the time, or only if openvpn tells it so.But in that my idea doesn't really make sense - it's as if windows wouldn'tstart windows sharing if the ethernet cable is not plugged in at boot time.gert(this post never made it to public archives for some reason, even though Gert cc'd openvpn-users and openvpn-devel) Also Jan Just Keijser from openvpn-users list said this:2010/6/22 Jan Just Keijser <Email removed for privacy>Henno Täht wrote:The only thing I can think of is that Windows XP explicitly forbids access to port 445 as a countersecurity measure unless it's coming from an "official" network card.That is exactly how it feels. But why would Windows XP (and only Windows XP) block OpenVPN TAP adapter's (and only this particular adapter) File and Printer Sharing service (port 445, a.k.a. microsoft-ds a.k.a. DirectSMB) and only when OpenVPN adapter's IP is configured with DHCP (if one sets the IP manually, no problems).Is there some soft of security mechanism built into XP kernel which blocks incoming connections to port 445 (controlled by process "System" with PID 4) if the adapter is "virtual", even though the controlling process binds to 0.0.0.0? Hoping someone at Microsoft reads this,Henno Täht2 people need an answerI do too
July 2nd, 2010 5:30pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics