localhost very slow response when connected to another network

1

When connected to a network (wia wifi), the webserver (IIS 7.5 on Windows7) on localhost takes up to 30sec to respond. Same for 127.0.0.1 or the internal ip (10.10.1.22). When disconnected - I get a the website from localhost loaded within 1sec. WTF?

As I modified routes for a VPN yesterday, I suppose I destroyed something in the routing table. But to me it all looks fine...Any ideas? I also tried adding "127.0.01 localhost" to the hosts file and disabling IPv6 without avail...Here is the routing table when connected:

Interface List

    11...88 53 2e 00 8d 4a ......Intel(R) Centrino(R) Advanced-N 6230
    1...........................Software Loopback Interface 1
    15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface

IPv4 Route Table

Active Routes: Network Destination Netmask Gateway Interface Metric

    0.0.0.0          0.0.0.0        10.10.1.1       10.10.1.22    286
    10.10.1.0    255.255.255.0         On-link        10.10.1.22    286
    10.10.1.22  255.255.255.255         On-link        10.10.1.22    286
    10.10.1.255  255.255.255.255         On-link        10.10.1.22    286
    127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
    127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
    127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
    224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
    255.255.255.255  255.255.255.255         On-link         127.0.0.1    306

Persistent Routes:

Network Address Netmask Gateway Address Metric

    0.0.0.0          0.0.0.0        10.10.1.1  Default

IPv6 Route Table

Active Routes: If Metric Network Destination Gateway

    15     58 ::/0                     On-link
    1    306 ::1/128                  On-link
    15     58 2001::/32                On-link
    15    306 2001:0:5ef5:79fd:3cb9:3333:a488:5e63/128 On-link
    15    306 fe80::/64                On-link
    15    306 fe80::3cb9:3333:a488:5e63/128 On-link
    1    306 ff00::/8                 On-link
    15    306 ff00::/8                 On-link

Persistent Routes: None

Elementenfresser

Posted 2013-09-04T12:54:23.953

Reputation: 21

127.0.0.1 is defined as localhost in every version of Windows by default. What do you mean you defined it exactly? Try changing the routes on the VPN back to what they were. – Ramhound – 2013-09-04T14:03:55.557

I found some suggestions to redundantly add the host name "localhost" pointing to the loopback IP 127.0.0.1 in the Windows\System32\drivers\etc\hosts file. But as the issue exists with browsing the IP 127.0.0.1 directly this can't be related... – Elementenfresser – 2013-09-04T15:28:56.700

I don't understand what 2 entries for the same ip address is suppose to do. The entry you describe already exists by default out of the box. – Ramhound – 2013-09-04T15:47:09.757

by default localhost is commented out in the hosts file in Windows7. And some users with issues like mine porposed to uncomment it there...but it didn't help anyway. But i'm quite sure it must be an IP issue, not a NS issue... – Elementenfresser – 2013-09-04T17:35:48.040

My personal experience using a default installation is that 127.0.0.1 is defined as localhost and not commented. Besides there are many programs that assume localhost is defined – Ramhound – 2013-09-04T17:40:06.653

of course, nobody is saying that "localhost" is not pointing to the loopback adapter when it's not explicitly defined in the hosts file. I think this is handled by the NS client automatically... – Elementenfresser – 2013-09-04T17:52:26.000

Actually Its not. If it was handled by the NS client automatically it wouldn't be in the /ect/hosts file. – Ramhound – 2013-09-04T17:55:06.313

The hosts file on windows 7 even states "# localhost name resolution is handled within DNS itself." and here's what I found on that: http://serverfault.com/a/9665/188520. However this is academic and won't help me with my problem :-)

– Elementenfresser – 2013-09-04T19:48:49.850

Answers

1

Well actually the issue was not related to the routing table. The web application itself tried to query the Active Directory server in the Role Provider's GetRolesForUser(string username). Since the AD was not there when not connected via VPN - every request timed out and failed resulting in overall response times of about 30 sec. Interstingly, the AD request did not happen at all when the server was disconnected from ALL networks and therefore responded fast.

Elementenfresser

Posted 2013-09-04T12:54:23.953

Reputation: 21