Inability to reach Microsoft sites from behind NAT firewall (updated)

[Christopher Neufeld]

Hello,

I've been trying to get my girlfriend's Windows XP Home laptop working
from behind my firewall computer, a Linux box which performs NATting
for all computers behind it. I've never operated a Windows computer,
and have no idea what has to be done, plus this version of Windows is
in Chinese only, and it takes me an impractically long time to walk
through menus labelled in Chinese.

It appears that she can reach all websites except those belonging to
Microsoft, and one Yahoo! site. Everything else works fine. Here are
my observations:

- she cannot reach hotmail, a message appears asking her to check her
Internet connection
- she could, for a while, see her hotmail messages through MSN
explorer, a program which seems to be included in the OS, but that
has stopped working also
- she cannot reach a "Windows update" server, it again claims that the
Internet connection is down
- she cannot reach the yahoo Taiwan site tw.yahoo.com, but can reach other
yahoo sites such as yahoo Japan.
- she can, from Windows, reach every other site attempted, painlessly
- she can reach hotmail, yahoo, etc. from the Linux desktops behind
the firewall, it is only the Windows machine which has trouble
- the problem is not with IE, she has the same difficulties using Mozilla
for Win32.

The troubles with hotmail are not occasional, they happen without
fail, every time an attempt is made to access from Windows XP. If she
directs Internet Explorer window at the yahoo Taiwan site, then goes
off to work on something else, she sometimes receives an incomplete
page after 7 or 8 hours.

These problems did not manifest when the laptop was in Taiwan, sharing
an Internet connection with another desktop machine there.

Since arriving in Canada and being configured (incorrectly?) for the
local network here, the laptop has never successfully connected to
those websites it cannot reach, so this isn't some progressive bitrot.

The Linux box is NATting a static IP number, cneufeld.ca. Surely it
is not an unusual setup to have a Windows machine hiding behind a
stateful NAT firewall.

I've done TCP dumps of good connections from Linux and broken
connections from Windows XP, both to login.passport.net, to try to see
what's going wrong.

Here's a sequence from the failed connection to http://login.passport.net
from the Windows XP laptop. Along the way, it picked up a redirection
in the URL, which appears to have been trying to set her specific
login details.


laptop opens a connection (#1) to login.passport.net, SYN, SYN-ACK, ACK
laptop pushes seq 425
login.passport.net pushes seq 424, ACKs the 425
login.passport.net pushes seq 438
login.passport.net sends FIN
laptop ACKs the 438
laptop ACKs the 439 (the FIN)
laptop sends FIN
laptop looks up login.passport.com
laptop opens a connection (#2) to login.passport.com, SYN, SYN-ACK, ACK
login.passport.net (connection #1) ACKs the laptop's FIN
laptop pushes seq 489 (INCLUDES get for /login.srf?lc=...")
login.passport.com pushes seq 366, ACKs the 489
login.passport.com pushes seq 1278
login.passport.com sends FIN
laptop ACKs the 1278
laptop ACKs the 1279 (the FIN)
laptop sends FIN
laptop opens a connection (#3) to login.passport.net, SYN, SYN-ACK, ACK
login.passport.com (connection #2) ACKs the laptop's FIN
laptop pushes seq 788 (INCLUDES redirector /uilogin.srf?id=...")
login.passport.net pushes seq 284, ACKs the 788
laptop ACKs the 284
--- Pause of 11 seconds
laptop sends a 77 byte UDP packet to port 3544 of baym-td1.msgr.hotmail.com
A 109 byte response from baum-td1.msgr.hotmail.com is delivered
--- Pause of 33 seconds
laptop sends a 77 byte UDP packet to port 3544 of baym-td1.msgr.hotmail.com
A 109 byte response from baum-td1.msgr.hotmail.com is delivered
--- Pause of 3 seconds
login.passport.net sends a RST to connection #3, sequence number 4664,
with ACK on 788

Total end-to-end time, 48 seconds. The firewall logged no blocked packets
during this interval.

The UDP packets appear to be periodic on the network, I don't think
they're part of the passport login sequence.


So, the sequence number on that RST packet shows that we lost almost 4
kilobytes of TCP data somewhere out in the world. It didn't bounce
off the firewall, that data never arrived back at the NAT box.

The successful authentication from Linux involves no UDP packets
(naturally), and no mysteriously vanished data.


I thought it might be some bad proxying setup, that some packets are
trying to go through the Taiwanese ISP, but the proxying settings
appear all to be blank, and proxying should hurt all sites equally,
not just those controlled by Microsoft.

It doesn't appear to be a fragmentation issue, I have seen an
oversized packet go through the network, saw the NAT box send back the
ICMP must-fragment error, and saw the laptop then reissue the data in
smaller packets.


My best theory right now, based on the never-delivered packets, is
that something in the TCP data exchanged is telling the passport
server on the third connection to route packets back to the NAT-ted IP
number through a specific Taiwanese ISP gateway machine, and the ISP
is discarding those packets because they don't live on its network.
No data is being sent from the laptop to any other Internet hosts
during this interval, so it is not establishing any sort of tunnelling
proxy with a remote ISP.


If somebody can offer me some suggestions, I would really appreciate
it, I've searched through a pile of microsoft.com help pages without
seeing anything which appears to explain or fix this problem. If you
can suggest menus to view in the configuration, please mention the
alphabetic shortcut key which invokes the button (the letter between
parentheses), since all of the buttons are labelled in Chinese
characters and the translation might not be exact, but I assume the
shortcut keys are consistent across locales.

 

[Ken Wickes [MSFT]]

Sounds like an MTU problem. Are you using PPPoE?

http://support.microsoft.com/?kbid=319661

 

[Haggis]

Sounds like an MTU problem. Are you using PPPoE?

http://support.microsoft.com/?kbid=319661

--

Ken Wickes [MSFT]
This posting is provided "AS IS" with no warranties, and confers no
rights.

Hello,

I've been trying to get my girlfriend's Windows XP Home laptop working
from behind my firewall computer, a Linux box which performs NATting
for all computers behind it. I've never operated a Windows computer,
and have no idea what has to be done, plus this version of Windows is
in Chinese only, and it takes me an impractically long time to walk
through menus labelled in Chinese.

It appears that she can reach all websites except those belonging to
Microsoft, and one Yahoo! site. Everything else works fine. Here are
my observations:

- she cannot reach hotmail, a message appears asking her to check her
Internet connection
- she could, for a while, see her hotmail messages through MSN
explorer, a program which seems to be included in the OS, but that
has stopped working also
- she cannot reach a "Windows update" server, it again claims that the
Internet connection is down
- she cannot reach the yahoo Taiwan site tw.yahoo.com, but can reach
other
yahoo sites such as yahoo Japan.
- she can, from Windows, reach every other site attempted, painlessly
- she can reach hotmail, yahoo, etc. from the Linux desktops behind
the firewall, it is only the Windows machine which has trouble
- the problem is not with IE, she has the same difficulties using Mozilla
for Win32.

The troubles with hotmail are not occasional, they happen without
fail, every time an attempt is made to access from Windows XP. If she
directs Internet Explorer window at the yahoo Taiwan site, then goes
off to work on something else, she sometimes receives an incomplete
page after 7 or 8 hours.

These problems did not manifest when the laptop was in Taiwan, sharing
an Internet connection with another desktop machine there.

Since arriving in Canada and being configured (incorrectly?) for the
local network here, the laptop has never successfully connected to
those websites it cannot reach, so this isn't some progressive bitrot.

The Linux box is NATting a static IP number, cneufeld.ca. Surely it
is not an unusual setup to have a Windows machine hiding behind a
stateful NAT firewall.

I've done TCP dumps of good connections from Linux and broken
connections from Windows XP, both to login.passport.net, to try to see
what's going wrong.

Here's a sequence from the failed connection to http://login.passport.net
from the Windows XP laptop. Along the way, it picked up a redirection
in the URL, which appears to have been trying to set her specific
login details.


laptop opens a connection (#1) to login.passport.net, SYN, SYN-ACK, ACK
laptop pushes seq 425
login.passport.net pushes seq 424, ACKs the 425
login.passport.net pushes seq 438
login.passport.net sends FIN
laptop ACKs the 438
laptop ACKs the 439 (the FIN)
laptop sends FIN
laptop looks up login.passport.com
laptop opens a connection (#2) to login.passport.com, SYN, SYN-ACK, ACK
login.passport.net (connection #1) ACKs the laptop's FIN
laptop pushes seq 489 (INCLUDES get for /login.srf?lc=...")
login.passport.com pushes seq 366, ACKs the 489
login.passport.com pushes seq 1278
login.passport.com sends FIN
laptop ACKs the 1278
laptop ACKs the 1279 (the FIN)
laptop sends FIN
laptop opens a connection (#3) to login.passport.net, SYN, SYN-ACK, ACK
login.passport.com (connection #2) ACKs the laptop's FIN
laptop pushes seq 788 (INCLUDES redirector /uilogin.srf?id=...")
login.passport.net pushes seq 284, ACKs the 788
laptop ACKs the 284
--- Pause of 11 seconds
laptop sends a 77 byte UDP packet to port 3544 of
baym-td1.msgr.hotmail.com
A 109 byte response from baum-td1.msgr.hotmail.com is delivered
--- Pause of 33 seconds
laptop sends a 77 byte UDP packet to port 3544 of
baym-td1.msgr.hotmail.com
A 109 byte response from baum-td1.msgr.hotmail.com is delivered
--- Pause of 3 seconds
login.passport.net sends a RST to connection #3, sequence number 4664,
with ACK on 788

Total end-to-end time, 48 seconds. The firewall logged no blocked
packets
during this interval.

The UDP packets appear to be periodic on the network, I don't think
they're part of the passport login sequence.


So, the sequence number on that RST packet shows that we lost almost 4
kilobytes of TCP data somewhere out in the world. It didn't bounce
off the firewall, that data never arrived back at the NAT box.

The successful authentication from Linux involves no UDP packets
(naturally), and no mysteriously vanished data.


I thought it might be some bad proxying setup, that some packets are
trying to go through the Taiwanese ISP, but the proxying settings
appear all to be blank, and proxying should hurt all sites equally,
not just those controlled by Microsoft.

It doesn't appear to be a fragmentation issue, I have seen an
oversized packet go through the network, saw the NAT box send back the
ICMP must-fragment error, and saw the laptop then reissue the data in
smaller packets.


My best theory right now, based on the never-delivered packets, is
that something in the TCP data exchanged is telling the passport
server on the third connection to route packets back to the NAT-ted IP
number through a specific Taiwanese ISP gateway machine, and the ISP
is discarding those packets because they don't live on its network.
No data is being sent from the laptop to any other Internet hosts
during this interval, so it is not establishing any sort of tunnelling
proxy with a remote ISP.


If somebody can offer me some suggestions, I would really appreciate
it, I've searched through a pile of microsoft.com help pages without
seeing anything which appears to explain or fix this problem. If you
can suggest menus to view in the configuration, please mention the
alphabetic shortcut key which invokes the button (the letter between
parentheses), since all of the buttons are labelled in Chinese
characters and the translation might not be exact, but I assume the
shortcut keys are consistent across locales.

have you checked for entries in your "hosts" file ?

 

[Christopher Neufeld]

Sounds like an MTU problem. Are you using PPPoE?

http://support.microsoft.com/?kbid=319661

Thank you for the suggestion, dropping the MTU to 1400 solved the problem,
although I still find it quite mysterious that:
- only a very few websites were affected
- path MTUd appears not to have worked, though I saw ICMP_MUST_FRAGMENTs on
the network when talking to some sites, and the Linux firewall's
internal interface itself has an MTU of 1400.
- the procedure for adjusting the MTU requires such unusual actions

Any way, my girlfriend's computer can now reach hotmail and Yahoo Taiwan
again, so she can start moving back to Windows from Linux, at least for
some activities.

 

[Christopher Neufeld]

have you checked for entries in your "hosts" file ?

Yes, I looked in the "hosts" file, nothing unexpected appeared there, or in
the other files in that directory.

Thank you for the suggestion, it gave me a chance to learn a bit more about
Windows. Ken Wickes' suggestion to drop the MTU was a good one, that
restored connectivity to the handful of sites formerly unreachable.

 

[Ken Wickes [MSFT]]

Sometimes various routers or firewalls drop the must fragment message as it
returns to the server. So only those websites would be affected. It is the
response that is too big.

 

[Hans-Georg Michna]

the Linux firewall's internal interface itself has an MTU of 1400.

Christopher,

why is that? The figure looks suspiciously low.

I suspect that only the Linux firewall is the problem.

Why don't you remove it for a test? Not before activating the
Windows firewall, of course.

A good web test tool can be found at www.speedguide.net,
Broadband Tools, TCP/IP Analyzer.

Hans-Georg

 

[Christopher Neufeld]

Hans-Georg,

why is that? The figure looks suspiciously low.

Sorry, I didn't make this clear. It's set there because I set it there
manually. The internal interface is responsible for forwarding not only to
the PPPoE interface, but also UDP-encapsulating some packets from other
machines on my network before tossing them over PPPoE as part of the VPN
setup with my remote office. That adds 28 bytes of packet overhead to the
46 bytes already on the PPPoE interface, so I truncated at 1400 just to be
conservative, and to choose a nice round number.

I suspect that only the Linux firewall is the problem.

If that were the case, we would likely have experienced the same problem
from all computers on the network. Only the Windows computer failed to
reach this small set of remote sites, the Linux computers behind the
firewall all went to hotmail and Yahoo Taiwan without difficulty.

Why don't you remove it for a test? Not before activating the
Windows firewall, of course.

At the time, that was not a good idea. Recall that the Windows computer
couldn't reach the Windows update site, so it did not have service pack 2
installed, or any of several other recent updates. Downloading the service
pack from a Linux box then copying it to the Windows machine would be
possible, but I have no experience with Windows computers, and wouldn't
know how to initiate a manual update on a computer when I could only read
the menus and instructions very slowly.

It's not really easy to remove the Linux firewall. It's not a little
firewall appliance, it's my primary desktop computer, web server, mail
host, VPN box, NAT end-point, and so on. I'd have to disconnect all that,
find a wired PCMCIA card for the Windows box, plug that into my DSL modem,
and configure it for PPPoE.


Anyway, the problem has gone away, and I thank everybody for their help.