Questions

Gateway issue on 2003 Server

Tags:
+
0 Votes
Locked

Gateway issue on 2003 Server

Timbrewolf
Our Primary Domain Controller is a Windows 2003 server which also hosts our DNS. Everything was working fine until a week or so ago. We've been doing a few things but nothing that should have affected this server specifically.

The server lost Internet (local area fine) access through the primary gateway (Cisco PIX). nslookup shows the server believes everything is fine, but cannot lookup domain names or ping outside the gateway. CAN ping the gateway fine.

When I add another DNS server as secondary, it will get the domain IP lookup from that system (in the network) but cannot ping it.

When I change the gateway to our backup T1, Internet access works. But of course I don't want to keep it there (VPN and outside resources aren't mapped through the T1).

No changes have been made to this or the PIX gateway, I tried resetting Winsock and restacking TCP/IP for corruption, to no avail. Any ideas?

Thanks!
Brandon
  • +
    0 Votes
    pthompson

    Can a workstation connected to the network access the internet through your primary t-1? If the answer is no, then check the gateway and the firewall to see if the firewall is malfunctioning. Also contact your ISP provider of the T-1. Could be a problem on their end. Also, see if you are experiencing a DOS attact. I had a client with similar problem. When I looked at the Firewall, I see that the incomming LED is blinking a hole lot, but when I look at the switch, network Traffic is normal. I swiched the Static IP or another IP that my client has access to and everything worked.

    +
    0 Votes

    * Don't worry about your windows 2003 , check if you are able to browse through Cisco Pix

    * On the PDC how is your DNS configured ? 127.0.0.1 & the external DNS address ?

    * Check your Cisco pix has a correct external DNS , might be the external DNS is not working ?

    Reply back , will help you if you are not finding any solution .

    +
    0 Votes
    Timbrewolf

    Thanks for both of those great replies!

    Workstations can browse fine through the primary gateway. The PDC is configured 127.0.0.1 and external DNS.
    Pix has correct DNS (as I mentioned, other systems and servers are having no issues, through the same switch).

    Will check for DOS attack - I've been leaning towards the direction of a possible attack or other issue related to this external IP. I'm not as experienced with the security side of things yet, any advice on how to figure out if this could be a SYN or other attack on my server (the server seems to be running slow also but no viruses detected, etc.)

    PIX Firewall is at our parent company across the street and not readily available - I can login but can't see the lights

    Thanks again for all the help!
    Brandon

    +
    0 Votes
    pthompson

    This maybe a long shot, but have you done any updates to the server? The reason why I bring this up, I have experience several machines over the past two weeks either with slow performance or blue-screen-o-death. I traced several failures to system updates. Also, if your server has auto-update enabled, I would go into the services option under Administrator tools and disable the autoupdate feature or just turn off the feature. The SVChost service can cause a lot of issues similar to what you are experiencing (with the slow performance and the inability to connect online. Even though the problems I?m mentioning in this reply now I experienced with workstations (it could happen on a server), the solution was to roll back the drivers and or disable the auto-update for window, these solutions worked 99% of the time either alone or together. Since you said it happened within the past week or so, that about the same time I experienced problems with some systems.

    When it comes to the DOS Attack. Since when you switch it to the backup T1, everything works, that leaves me to believe that the problem maybe related to a DOS Attack.

    Also, in your latest reply, it states that the PDC is configured 127.0.0.1, does that mean you have a static IP address for the PDC as 127.0.0.1? If so, this is a major issue because 127.0.0.1 is reserved for loopback and that can cause major issues. I would go through all Static IP assigned to your servers. I would make sure that all servers have static IP addresses. If the server in question has a dynamic setting that will also keep it from accessing outside the gateway if the gateway is not configured to allow that IP address to pass-through. If the server had dynamic settings for the IP, then it would work for a short while, then after a few days, it would fail, I would review the event log under DNS and System to see what errors are popping up. Please keep me informed of your progress. Also, for the server in question, check the DNS settings 1 and DNS settings 2.

    +
    0 Votes
    yungster

    Hello All,

    I would try the following commands to determine if the problem is with internal dns name resolution or external dns resolution. Depending on the firewall used and the OS of the DNS server, there may be issues resolving domain names of certain sites.

    nslookup www.gmail.com [ISP DNS server]
    nslookup 66.249.83.19 [ISP DNS server]
    nslookup 66.249.83.19 [internal DNS server]
    nslookup www.gmail.com [internal DNS server]
    nslookup -q=mx [your domain name]
    nslookup host.yourdomainname.com
    tracert www.gmail.com
    tracert 66.249.83.19

    If these domain name queries fail, then you might want to restart the DNS service on the domain controller and repeat test.

    Please check out the article below for the specific fix.

    good luck


    DNS query responses do not travel through a firewall in Windows Server 2003

    http://support.microsoft.com/kb/828263

    SYMPTOMS
    A Microsoft Windows Server 2003-based computer may not receive DNS query responses through a firewall.

    Some queries, such as queries for A records, work as expected. Queries for MX records may fail. Domains with this issue include AOL.com, Qwest.net, and EarthLink.net.

    The sender of an e-mail may receive a Non Delivery Reciept (NDR) with the error message that is similar to the following:
    The following recipient(s) could not be reached: user@earthlink.net on (Date Time) There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. <(Domain.com) #5.5.0 smtp;550-EarthLink does not recognize your computer (xx.xx.xxx.xxx) as connecting from an EarthLink connection. If this is in error, please contact technical support.>
    Back to the top

    CAUSE
    This issue may occur if a firewall blocks the transfer of UDP packets that are larger than 512 bytes.

    With Extension Mechanisms for DNS (EDNS0) as defined in RFC 2671, "Extension Mechanisms for DNS (EDNS0)," DNS requestors can advertise UDP packet size and transfer packets larger than 512 bytes. By default, some firewalls have security features turned on that block UDP packets that are larger than 512 bytes. As a result, DNS queries may fail.

    This problem also may occur on some Cisco PIX Firewall models with software that is earlier than PIX Firewall version 6.3(2). The Cisco PIX Firewall drops DNS packets that are sent to User Datagram Protocol (UDP) port 53 that are larger than the configured maximum length. By default, the maximum length for UDP packets is 512 bytes.
    Back to the top

    RESOLUTION
    To resolve this issue, use any one of the following methods.
    Back to the top

    Method 1
    Contact the firewall vendor to determine how to permit UDP packets that are larger than 512 bytes through the firewall.

    For update instruction and for information about how to resolve this problem, visit the following Cisco Systems Web site:
    http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html (http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html)


    For information about how to contact a specific firewall vendor, click the appropriate article number in the following list to view the article in the Microsoft Knowledge Base:
    65416 (http://support.microsoft.com/kb/65416/) Hardware and software vendor contact information, A-K

    60781 (http://support.microsoft.com/kb/60781/) Hardware and software vendor contact information, L-P

    60782 (http://support.microsoft.com/kb/60782/) Hardware and software vendor contact information, Q-Z


    Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
    Back to the top

    Method 2
    Turn off EDNS0 functionality on the Windows Server 2003 server. To do so, at the command prompt, type:
    dnscmd Server Name/Config /EnableEDnsProbes 0
    Back to the top

    WORKAROUND
    To work around this issue, turn off the EDNS0 feature in Windows Server 2003. To do this, follow these steps: 1. Install the Dnscmd.exe program from the Windows Server 2003 Support Tools. To install the Windows Support Tools, right-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD-ROM, and then click Install. Follow the steps in the Windows Support Tools Setup Wizard to complete the installation of the Windows Support Tools.
    2. At a command prompt, type dnscmd /config /enableednsprobes 0 , and then press ENTER.
    Note Type a 0 (zero) and not the letter "O" after "enableednsprobes" in this command.
    Back to the top

    MORE INFORMATION
    The original DNS restriction for UDP packet size is defined in RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION." For more information about RFC 1035, visit the following Internet Engineering Task Force (IETF) Web site:
    http://www.ietf.org/rfc/rfc1035.txt (http://www.ietf.org/rfc/rfc1035.txt)
    For more information about RFC 2671 and EDNS0, visit the following Internet Engineering Task Force (IETF) Web site:
    http://www.ietf.org/rfc/rfc2671.txt (http://www.ietf.org/rfc/rfc2671.txt)
    For more information about EDNS0 support in Windows Server 2003, visit the following Microsoft Web site:
    http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx (http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx)
    The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
    Back to the top


    --------------------------------------------------------------------------------

    APPLIES TO
    ? Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Web Edition
    ? Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
    ? Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems

    Back to the top

    +
    0 Votes
    Timbrewolf

    Thanks for all the detailed help!

    Unfortunately, I'm still encountering the same issues. I'm beginning to believe it may be an issue with the PIX (which is controlled by our parent company).

    I've checked the routing tables, restarted the DNS server, and much more. I enabled the second network card and configured it on an additional IP address on the same gateway and no luck.

    We have two separate gateways - our PIX is on our primary fiber network connection. We also have an active T1.

    Whenever I use the T1 - Everything works fine (on both network cards). Whenever I switch to the PIX Gateway, I can ping the gateway and any internal sites, but no access to the outside.

    The thing that bothers me about this is the running configuration looks fine on the PIX - no issues. Nothing has changed over the past few weeks.

    Anyone had an instance of this happening even though PIX shows no logs or problems? Or could it be some strange MS configuration problem or attack?

    Thanks again! It's just been frustrating.

    +
    0 Votes
    pthompson

    Hey Buddy, sorry this has not worked out so well. If it's an DOS attack, check the incomming port. If you are recieveing a flood of data packets from outside your office, then it's quite possible a DOS attack. I experience that about 3 months ago. I changed the Static IP address and it worked great. Also before that, i reset the Firewall/router then that solved it on another account. But in your case, I would narrow it down to a problem with that Static Ip on the PIX or a firewall change/malfunction. If your parent company controls that channel, i would ask them to reset the system that routes data packets to and from your office. At this point you may be right. I do not think it's a MS configuration if it works on the backup T-1, unless it's been config to the DNS or gateways of that T-1 channel. Please let me know what happens. Thanks,

    +
    0 Votes
    yungster

    Method 2

    Turn off EDNS0 functionality on the Windows Server 2003 server.

    To do so, at the command prompt, type:

    dnscmd Server Name /Config /EnableEDnsProbes 0
    Back to the top

    +
    0 Votes

    * Don't worry about your windows 2003 , check if you are able to browse through Cisco Pix

    * On the PDC how is your DNS configured ? 127.0.0.1 & the external DNS address ?

    * Check your Cisco pix has a correct external DNS , might be the external DNS is not working ?

    Reply back , will help you if you are not finding any solution .

  • +
    0 Votes
    pthompson

    Can a workstation connected to the network access the internet through your primary t-1? If the answer is no, then check the gateway and the firewall to see if the firewall is malfunctioning. Also contact your ISP provider of the T-1. Could be a problem on their end. Also, see if you are experiencing a DOS attact. I had a client with similar problem. When I looked at the Firewall, I see that the incomming LED is blinking a hole lot, but when I look at the switch, network Traffic is normal. I swiched the Static IP or another IP that my client has access to and everything worked.

    +
    0 Votes

    * Don't worry about your windows 2003 , check if you are able to browse through Cisco Pix

    * On the PDC how is your DNS configured ? 127.0.0.1 & the external DNS address ?

    * Check your Cisco pix has a correct external DNS , might be the external DNS is not working ?

    Reply back , will help you if you are not finding any solution .

    +
    0 Votes
    Timbrewolf

    Thanks for both of those great replies!

    Workstations can browse fine through the primary gateway. The PDC is configured 127.0.0.1 and external DNS.
    Pix has correct DNS (as I mentioned, other systems and servers are having no issues, through the same switch).

    Will check for DOS attack - I've been leaning towards the direction of a possible attack or other issue related to this external IP. I'm not as experienced with the security side of things yet, any advice on how to figure out if this could be a SYN or other attack on my server (the server seems to be running slow also but no viruses detected, etc.)

    PIX Firewall is at our parent company across the street and not readily available - I can login but can't see the lights

    Thanks again for all the help!
    Brandon

    +
    0 Votes
    pthompson

    This maybe a long shot, but have you done any updates to the server? The reason why I bring this up, I have experience several machines over the past two weeks either with slow performance or blue-screen-o-death. I traced several failures to system updates. Also, if your server has auto-update enabled, I would go into the services option under Administrator tools and disable the autoupdate feature or just turn off the feature. The SVChost service can cause a lot of issues similar to what you are experiencing (with the slow performance and the inability to connect online. Even though the problems I?m mentioning in this reply now I experienced with workstations (it could happen on a server), the solution was to roll back the drivers and or disable the auto-update for window, these solutions worked 99% of the time either alone or together. Since you said it happened within the past week or so, that about the same time I experienced problems with some systems.

    When it comes to the DOS Attack. Since when you switch it to the backup T1, everything works, that leaves me to believe that the problem maybe related to a DOS Attack.

    Also, in your latest reply, it states that the PDC is configured 127.0.0.1, does that mean you have a static IP address for the PDC as 127.0.0.1? If so, this is a major issue because 127.0.0.1 is reserved for loopback and that can cause major issues. I would go through all Static IP assigned to your servers. I would make sure that all servers have static IP addresses. If the server in question has a dynamic setting that will also keep it from accessing outside the gateway if the gateway is not configured to allow that IP address to pass-through. If the server had dynamic settings for the IP, then it would work for a short while, then after a few days, it would fail, I would review the event log under DNS and System to see what errors are popping up. Please keep me informed of your progress. Also, for the server in question, check the DNS settings 1 and DNS settings 2.

    +
    0 Votes
    yungster

    Hello All,

    I would try the following commands to determine if the problem is with internal dns name resolution or external dns resolution. Depending on the firewall used and the OS of the DNS server, there may be issues resolving domain names of certain sites.

    nslookup www.gmail.com [ISP DNS server]
    nslookup 66.249.83.19 [ISP DNS server]
    nslookup 66.249.83.19 [internal DNS server]
    nslookup www.gmail.com [internal DNS server]
    nslookup -q=mx [your domain name]
    nslookup host.yourdomainname.com
    tracert www.gmail.com
    tracert 66.249.83.19

    If these domain name queries fail, then you might want to restart the DNS service on the domain controller and repeat test.

    Please check out the article below for the specific fix.

    good luck


    DNS query responses do not travel through a firewall in Windows Server 2003

    http://support.microsoft.com/kb/828263

    SYMPTOMS
    A Microsoft Windows Server 2003-based computer may not receive DNS query responses through a firewall.

    Some queries, such as queries for A records, work as expected. Queries for MX records may fail. Domains with this issue include AOL.com, Qwest.net, and EarthLink.net.

    The sender of an e-mail may receive a Non Delivery Reciept (NDR) with the error message that is similar to the following:
    The following recipient(s) could not be reached: user@earthlink.net on (Date Time) There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. <(Domain.com) #5.5.0 smtp;550-EarthLink does not recognize your computer (xx.xx.xxx.xxx) as connecting from an EarthLink connection. If this is in error, please contact technical support.>
    Back to the top

    CAUSE
    This issue may occur if a firewall blocks the transfer of UDP packets that are larger than 512 bytes.

    With Extension Mechanisms for DNS (EDNS0) as defined in RFC 2671, "Extension Mechanisms for DNS (EDNS0)," DNS requestors can advertise UDP packet size and transfer packets larger than 512 bytes. By default, some firewalls have security features turned on that block UDP packets that are larger than 512 bytes. As a result, DNS queries may fail.

    This problem also may occur on some Cisco PIX Firewall models with software that is earlier than PIX Firewall version 6.3(2). The Cisco PIX Firewall drops DNS packets that are sent to User Datagram Protocol (UDP) port 53 that are larger than the configured maximum length. By default, the maximum length for UDP packets is 512 bytes.
    Back to the top

    RESOLUTION
    To resolve this issue, use any one of the following methods.
    Back to the top

    Method 1
    Contact the firewall vendor to determine how to permit UDP packets that are larger than 512 bytes through the firewall.

    For update instruction and for information about how to resolve this problem, visit the following Cisco Systems Web site:
    http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html (http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html)


    For information about how to contact a specific firewall vendor, click the appropriate article number in the following list to view the article in the Microsoft Knowledge Base:
    65416 (http://support.microsoft.com/kb/65416/) Hardware and software vendor contact information, A-K

    60781 (http://support.microsoft.com/kb/60781/) Hardware and software vendor contact information, L-P

    60782 (http://support.microsoft.com/kb/60782/) Hardware and software vendor contact information, Q-Z


    Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
    Back to the top

    Method 2
    Turn off EDNS0 functionality on the Windows Server 2003 server. To do so, at the command prompt, type:
    dnscmd Server Name/Config /EnableEDnsProbes 0
    Back to the top

    WORKAROUND
    To work around this issue, turn off the EDNS0 feature in Windows Server 2003. To do this, follow these steps: 1. Install the Dnscmd.exe program from the Windows Server 2003 Support Tools. To install the Windows Support Tools, right-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD-ROM, and then click Install. Follow the steps in the Windows Support Tools Setup Wizard to complete the installation of the Windows Support Tools.
    2. At a command prompt, type dnscmd /config /enableednsprobes 0 , and then press ENTER.
    Note Type a 0 (zero) and not the letter "O" after "enableednsprobes" in this command.
    Back to the top

    MORE INFORMATION
    The original DNS restriction for UDP packet size is defined in RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION." For more information about RFC 1035, visit the following Internet Engineering Task Force (IETF) Web site:
    http://www.ietf.org/rfc/rfc1035.txt (http://www.ietf.org/rfc/rfc1035.txt)
    For more information about RFC 2671 and EDNS0, visit the following Internet Engineering Task Force (IETF) Web site:
    http://www.ietf.org/rfc/rfc2671.txt (http://www.ietf.org/rfc/rfc2671.txt)
    For more information about EDNS0 support in Windows Server 2003, visit the following Microsoft Web site:
    http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx (http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx)
    The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
    Back to the top


    --------------------------------------------------------------------------------

    APPLIES TO
    ? Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Web Edition
    ? Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    ? Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
    ? Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems

    Back to the top

    +
    0 Votes
    Timbrewolf

    Thanks for all the detailed help!

    Unfortunately, I'm still encountering the same issues. I'm beginning to believe it may be an issue with the PIX (which is controlled by our parent company).

    I've checked the routing tables, restarted the DNS server, and much more. I enabled the second network card and configured it on an additional IP address on the same gateway and no luck.

    We have two separate gateways - our PIX is on our primary fiber network connection. We also have an active T1.

    Whenever I use the T1 - Everything works fine (on both network cards). Whenever I switch to the PIX Gateway, I can ping the gateway and any internal sites, but no access to the outside.

    The thing that bothers me about this is the running configuration looks fine on the PIX - no issues. Nothing has changed over the past few weeks.

    Anyone had an instance of this happening even though PIX shows no logs or problems? Or could it be some strange MS configuration problem or attack?

    Thanks again! It's just been frustrating.

    +
    0 Votes
    pthompson

    Hey Buddy, sorry this has not worked out so well. If it's an DOS attack, check the incomming port. If you are recieveing a flood of data packets from outside your office, then it's quite possible a DOS attack. I experience that about 3 months ago. I changed the Static IP address and it worked great. Also before that, i reset the Firewall/router then that solved it on another account. But in your case, I would narrow it down to a problem with that Static Ip on the PIX or a firewall change/malfunction. If your parent company controls that channel, i would ask them to reset the system that routes data packets to and from your office. At this point you may be right. I do not think it's a MS configuration if it works on the backup T-1, unless it's been config to the DNS or gateways of that T-1 channel. Please let me know what happens. Thanks,

    +
    0 Votes
    yungster

    Method 2

    Turn off EDNS0 functionality on the Windows Server 2003 server.

    To do so, at the command prompt, type:

    dnscmd Server Name /Config /EnableEDnsProbes 0
    Back to the top

    +
    0 Votes

    * Don't worry about your windows 2003 , check if you are able to browse through Cisco Pix

    * On the PDC how is your DNS configured ? 127.0.0.1 & the external DNS address ?

    * Check your Cisco pix has a correct external DNS , might be the external DNS is not working ?

    Reply back , will help you if you are not finding any solution .