Domain Controller answering Web Requests meant for separate Web Server

OK.  This is a bit of a weird problem...  And I need to elaborate...

I originally had our network setup, as depicted in the attached file (1.jpg).  EVERYTHING was working great.

Well, unfortunately, the Netgear ProSafe firewall had a complete hardware failure, and I ended up having to remove it from the picture.  (and now the network is as it's depicted in the 2nd file (2.jpg).

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

Here's the problem:  Web requests are sent to the Web Server (192.168.1.254), and I've got DNS on the Domain Controller that all of the hosted sites are referred to the internal address.

But, since I've lost the firewall and had to move the domain controller into the 192.168.1.254 network, it's begun answering for web requests that are supposed to be destined to the web server.

The DC has two nics, one for the "external" lan, and one for the "internal" one.  At (what looks like very random) intervals, the DC starts answering requests for all web traffic (coming from the router) that's supposed to be heading to the webserver.

Now, the really weird part, is that this is ONLY for traffic that's inbound from the router.  Anything originating on the internal 90.0.0.0/24 network still works like it should, and the web server answers traffic.

When the DC takes over for answering web requests, the only way to fix it - is to restart the DC - and everything automatically falls into line again, and external users are sent correctly to the web server.

I'm just trying to wrap my head around why it could be doing this.  It will all go away shortly, as I've ordered another firewall some time ago, and just waiting for it to get here in the mail.  With the new firewall, I'll be able to put the DC in a completely separate network again, and this problem really will be a thing of the past.

Anybody have any ideas why something like this would happen?  In IIS on the DC, it's only answering requests on the internal NIC.
1.jpg
2.jpg
LVL 5
usslindstromAsked:
Who is Participating?
 
debuggerauConnect With a Mentor Commented:
I think it might have something to do with the nat translation on your router (unknown) that translates the address from the internet and is suppose to be directed to the webserver IP addess, but somehow gets answered by the DC.
I suppose it would depend on how your nat is setup, if its a static nat for only the webserver, or a dymamic nat servicing all clients on 192.168.1.x subnet..
with the router config inhand I'd be more definite but I use a setup called pnat and only direct the ports I choose to a particular IP addresses...
0
 
usslindstromAuthor Commented:
It's a smaller Corega Home/Business router, and you might be on to something in the NAT reference.

It's NATng (that's an official word now :) ) for the entire 192.168.1.0/24 network...  And the problem might be inside that.

But I'm not 100% certain that's the issue....  As, here's the stage of everything working in sequence.

1.  Everything working like normal.
2.  DC starts answering web requests that are supposed to go to the Web Server
3.  Restart the DC.  Everything goes back to normal.
4.  Wait a random period of time, and then go back to #1.

When this happens, there's absolutely NOTHING in the event logs of either PC.  So I'm not sure what the catalyst is, in this whole ordeal.
0
 
debuggerauCommented:
you said previously that the DC houses the DNS requests...
Does it have a web server on the DC also?

senario:
so clients connect, their client does a phishing check rDNS or something which gets redirected to DNS server, which happens to be NAT'ed to your subnet..
Then the nat believes that the client connection is meant to go to the DC and forgets about the DNS.
This could happen because of a lack of resources in your NAT translation tables router or times out etc...
Could be because you are under DDoS getting DNS poisoned or are get getting exploited in the DNS or IIS area...

I would need a closer look at why, but a packet trace would tell us why..
Are you able to get wireshark or ethereal on a hub and monitor the traffic for sometime?
I'd really like to see whats setting it off too..

Are you pages SSL? TLSV1?, do you have CA auth?
how many clients does it happen too? IE clients only?
how often does it happen? and how many concurrent connections do you get?






0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
Amit BhatnagarTechnology Consultant - SecurityCommented:
debuggerau is already doing a great job while answering but if it is OK with you, can you please post the IPconfig /all of your DC here. Take out the information which you dont want exposed. I somehow feel, we should start with the basics here. By any chance, do you have DG specified on both the NICs?
0
 
usslindstromAuthor Commented:
Well, I've got great news, and horrible news - all at the same time.

The great news, is that the firewall replacement made it in today, and I've already got it in place, - so now the network is back to the first image (1.jpg) - and working very nicely I might add.  ;)

The bad news, is that it basically terminates the troubleshooting opportunity to figure out what was happening.

Before I put the firewall in, I went ahead and grabed an ipconfig /all output like Bamit suggested:

-------------------------
Z:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : XXXXXXX
   Primary Dns Suffix  . . . . . . . : XXXXXXXX.com
   Node Type . . . . . . . . . . . . : Unknown
   IP Routing Enabled. . . . . . . . : Yes
   WINS Proxy Enabled. . . . . . . . : Yes
   DNS Suffix Search List. . . . . . : XXXXXXXX.com

Ethernet adapter Internal LAN:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigab
it Ethernet Controller
   Physical Address. . . . . . . . . : 00-40-F4-D8-69-17
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 90.0.0.1
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 127.0.0.1
   Primary WINS Server . . . . . . . : 90.0.0.1

Ethernet adapter External LAN:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigab
it Ethernet Controller #2
   Physical Address. . . . . . . . . : 00-40-F4-D8-69-F3
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.1.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   Primary WINS Server . . . . . . . : 90.0.0.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

PPP adapter RAS Server (Dial In) Interface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
   Physical Address. . . . . . . . . : 00-53-45-00-00-00
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 90.0.0.17
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Disabled

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

Now that everything's back to the first picture, it's all working like it should.  It woulda' been nice to find out why it was happening, but here's to hoping it doesn't happen again.
0
 
usslindstromAuthor Commented:
Oh - and to answer the questions:

Are you pages SSL? TLSV1?, do you have CA auth?
  My DC is SBS2K3, and it's a CA.  All other computers, including the web server get their certificates from it.

how many clients does it happen too? IE clients only?
  All external requests would be answered by the DC.  It wasn't browser specific.

how often does it happen? and how many concurrent connections do you get?
  Never checked....   Sorry I missed it.

As far as DNS, the DC is a DNS server, but it only supplies internal clients with name resolution.  The router is simply port forwarding all of port 80 and 443 to the web server.  So, a DOS attack targeting DNS wasn't happening.

We had been under a brute force attack a short while ago, with somebody trying to gain access via FTP, but it was all coming from the same IP - so I went ahead and blocked the IP.   Hadn't been under attack since.
0
 
Amit BhatnagarTechnology Consultant - SecurityCommented:
hmmm...Then I guess  (and like debuggerau earlier said) that a trace could have been very helpful. We need to know how the Network sees the packet when it is coming through the router. The issue gets fixed if you reboot the DC so I doubt the router is a problem here. Although, I have seen a lot of cases where due to a feature in certain Router called as Proxy Arp, Arp cache of Windows gets corrupted and hence the issue. Again, this is an assumption here since everything is fixed now. Great that everything is back now !! Good job debuggerau ..:)
0
All Courses

From novice to tech pro — start learning today.