I'm not sure if this will be of any help, but at least the Firefox issue sounds like FF is able to connect, but never receives any return traffic. I've had that with misconfigured netmasks I believe. Does Vista use some sort of net group or certificate based access scheme (e.g. "if it's not a Vista box talking to me, I won't talk back")? May sound stupid, but you never know. Who on earth knows what MS does with network traffic?
Bill On Sun, 2006-11-26 at 21:19 -0600, Reverend Deuce wrote: > (This is very long email because it's a very complicated problem... > I've included some tcpdump logs below to assist...) > > The last week and days I've been working with the RTM version of Vista > obtained through my MSDN license. This is the "gold" version of > Windows Vista, BTW. It's done. It's been shipped to manufacturing > (hence RTM, "release to manufacturing"). > > Okay, so I've installed this thing and am testing out all the bells > and whistles. > > I install Firefox, OpenVPN, putty, the Java JRE from Sun, etc. > > I start to tool around and I notice that none of our company's web > sites will load in Firefox any longer. Firefox's status bar says > "Waiting for www.site.tld..." and eventually will time out. It does > this for every single web site we host. > > I fire up IE 7. No problems with any site. > > I go back to Firefox and it's still having issues -- but *only* with > sites hosted behind our OpenBSD firewalls. > > I fire up "telnet" (after enabling it through the control panel -- no > idea why MS did this). I can telnet to our web servers via port 80, > issue "GET" requests, receive responses. No trouble with Telnet.exe. > > Putty however, has trouble. Wont work period. Port 80 telnet, ssh port > 22, etc. None of them. > > So now I am thinking that it might just be a Firefox problem... but > it's not. Microsoft's own Remote Desktop Connection (terminal services > client, rdp client, etc) wont connect to our datacenter servers -- and > they are accessed via an openvpn point to point VPN that terminates on > the OpenBSD firewall which acts strictly as a routed tunnel between > our two networks. > > I turn off as much of the Vista "security" features as I can. This does > nothing. > > Since our OBSD firewalls were of the older variety (3.6), I figured I > might try an upgrade to 4.0 to see what happens. No dice. > > To summarize: > > This **only** is affecting Windows Vista (have not tried the latest > betas of Longhorn Server). Windows XP, Windows 2000, Free/OpenBSD, > CentOS, and our four Mac users with OSX have zero trouble. None. Nada. > They work flawlessly. > > Okay, so we can blame Vista -- that would be fine with me, but let's > face it -- this going to be big come January. I have a month to fix > this damn thing and I am really out of ideas. > > Our network: > > 100mbit dedicated inet connection through AT&T, terminates to a big > Cisco setup owned by our datacenter. > > Firewalls are now OBSD 4.0, single-proc Xeon 2.4gHz, 1GB RAM, etc. -- > they are decent systems with six gigabit NICs each. > > They are all configured with CARP and pfsync. This has worked very, > very well since day 1 in 2004! CARP rocks! > > They connect to an HP ProCurve 5400ZL modular switch, configured with > various port VLANs, etc. Everything is gigabit, 'cept for a few > databases using 10-gigabit CX4. > > Here are some tcpdumps from the master FW during connection attempts > with a browser: > > > > Opera 9: > > 20:40:45.824144 my.workstation.ip.49370 > remote.server.ip.80: S > 1215871830:1215871830(0) win 8192 <mss 1380,nop,wscale > 8,nop,nop,sackOK> (DF) > 20:40:45.824646 207.218.64.33.80 > my.workstation.ip.49370: S > 2582857930:2582857930(0) ack 1215871831 win 64240 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > 20:40:45.878361 my.workstation.ip.49370 > 207.218.64.33.80: . ack 1 win 260 > (DF) > 20:40:45.904597 my.workstation.ip.49370 > 207.218.64.33.80: P > 1:384(383) ack 1 win 260 (DF) > 20:40:46.058234 207.218.64.33.80 > my.workstation.ip.49370: . ack 384 > win 63857 (DF) > 20:40:46.061253 my.workstation.ip.49370 > 207.218.64.33.80: P > 1:384(383) ack 1 win 260 (DF) > 20:40:46.061726 207.218.64.33.80 > my.workstation.ip.49370: . ack 384 > win 63857 (DF) > (at this point, the connection is hung -- the Vista workstation > receives no further communcations -- it's like it just drops the > replies) > > > > Firefox: > > 20:38:25.197691 my.workstation.ip.49357 > remote.server.ip.80: S > 643900711:643900711(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> > (DF) > 20:38:25.198320 remote.server.ip.80 > my.workstation.ip.49357: S > 852828096:852828096(0) ack 643900712 win 64240 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > 20:38:25.244540 my.workstation.ip.49357 > remote.server.ip.80: . ack 1 > win 260 (DF) > 20:38:25.251037 my.workstation.ip.49357 > remote.server.ip.80: P > 1:403(402) ack 1 win 260 (DF) > 20:38:25.567602 my.workstation.ip.49357 > remote.server.ip.80: P > 1:403(402) ack 1 win 260 (DF) > 20:38:25.568042 remote.server.ip.80 > my.workstation.ip.49357: . ack > 403 win 63838 (DF) > (same deal -- it just seems to die right here) > > > > IE 7: > > 20:39:08.834465 my.workstation.ip.49358 > remote.server.ip.80: S > 4155969795:4155969795(0) win 8192 <mss 1380,nop,wscale > 2,nop,nop,sackOK> (DF) > 20:39:08.835095 remote.server.ip.80 > my.workstation.ip.49358: S > 3294485308:3294485308(0) ack 4155969796 win 64240 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > 20:39:08.892057 my.workstation.ip.49358 > remote.server.ip.80: . ack 1 > win 16685 (DF) > 20:39:08.904548 my.workstation.ip.49358 > remote.server.ip.80: P > 1:472(471) ack 1 win 16685 (DF) > 20:39:08.907010 remote.server.ip.80 > my.workstation.ip.49358: . > 1:1381(1380) ack 472 win 63769 (DF) > 20:39:08.907135 remote.server.ip.80 > my.workstation.ip.49358: . > 1381:2761(1380) ack 472 win 63769 (DF) > 20:39:08.959016 my.workstation.ip.49358 > remote.server.ip.80: . ack > 2761 win 16685 (DF) > 20:39:08.959740 remote.server.ip.80 > my.workstation.ip.49358: . > 2761:4141(1380) ack 472 win 63769 (DF) > 20:39:08.959750 remote.server.ip.80 > my.workstation.ip.49358: . > 4141:5521(1380) ack 472 win 63769 (DF) > 20:39:08.959911 remote.server.ip.80 > my.workstation.ip.49358: . > 5521:6901(1380) ack 472 win 63769 (DF) > 20:39:09.010614 my.workstation.ip.49358 > remote.server.ip.80: . ack > 6901 win 16685 (DF) > 20:39:09.011323 remote.server.ip.80 > my.workstation.ip.49358: . > 6901:8281(1380) ack 472 win 63769 (DF) > 20:39:09.011333 remote.server.ip.80 > my.workstation.ip.49358: . > 8281:9661(1380) ack 472 win 63769 (DF) > 20:39:09.011447 remote.server.ip.80 > my.workstation.ip.49358: . > 9661:11041(1380) ack 472 win 63769 (DF) > 20:39:09.011571 remote.server.ip.80 > my.workstation.ip.49358: . > 11041:12421(1380) ack 472 win 63769 (DF) > 20:39:09.058459 my.workstation.ip.49358 > remote.server.ip.80: . ack > 9661 win 16685 (DF) > 20:39:09.059165 remote.server.ip.80 > my.workstation.ip.49358: . > 12421:13801(1380) ack 472 win 63769 (DF) > 20:39:09.059289 remote.server.ip.80 > my.workstation.ip.49358: P > 13801:15131(1330) ack 472 win 63769 (DF) > 20:39:09.064831 my.workstation.ip.49358 > remote.server.ip.80: . ack > 12421 win 16685 (DF) > 20:39:09.097561 my.workstation.ip.49359 > remote.server.ip.80: S > 3924198291:3924198291(0) win 8192 <mss 1380,nop,wscale > 2,nop,nop,sackOK> (DF) > 20:39:09.098564 remote.server.ip.80 > my.workstation.ip.49359: S > 4022470982:4022470982(0) ack 3924198292 win 64240 <mss 1460,nop,wscale > 0,nop,nop,sackOK> > (But IE 7 is just dandy! It loads the whole page and just keeps on > tickin, goddamnit!) > > > I should note that the only connections that seem to have trouble are > TCP connections. It seems that OpenVPN clients can traverse the > firewall without issue (our OpenVPN server sites behind the firewall). > Inbound DNS queries have no issues either. ICMP is good also, for the > hosts that have permission to ping. > > Again, I need to stress this -- I've NOT overlooked the obvious here. > Remember, the problem **only** happens in Vista. It has happened on > several desktops/workstations, both off-site from our office, inside a > VM, directly on hardware, etc. I've tried about a dozen configs so > far. This is not a "try swapping the RAM" situation. > > There are no strange VPNs, static routes, oddball topologies, etc. > It's very straightforward and a very predictable problem. It's driving > me up the wall! > > Can anybody help out? > > -- Rev
