DNS OK, but can't get to internet?

Some bunch of clowns have been playing around on my bro's server trying to
set up VPN access and now they report that they can't get any internet
traffic to either server or clients.


Here's the setup...

Windows 2003 Server Standard (192.168.100.1)
2x Lan card (1 Disabled)
DNS
DHCP

Machines (192.168.100.x from server)
Default gateway: 192.168.100.250
DNS Server: 192.168.100.1

Router (192.168.100.250)
DHCP server disabled.


Tests I've done:
DHCP allocated (Pass)
Ping Router IP from Client (Pass)
Ping Router IP from Server (Pass)
Ping Server IP from Client (Pass)
Ping Server FQDN from Client (Pass)

Ping Remote site from Server (Resolves IP, 4x Time out)
Tracert Remote site from Server (Resolves IP, All nodes time out)
Ping Router Default Gateway from Client (Fail)
Ping Router Default Gateway from Server (Fail)


Things I tried that haven't worked...

Disabling RRAS via the wizard (+ reboot).
Switching out the router with another and recongifguring from factory
defaults.

I wanted to look at the routing table, but I'm helping them remotely and
have no access to the box / screen and they have no idea what they're looking
at and confuse me even further.

They have reported that when they try to access anything on the net, LAN
traffic slows and the traffic light becomes almost permanently lit. It
sounds like some kind of packet storm, but I have no idea how to diagnose /
fix it...

Any ideas welcome!

* James Snell (Wed, 2 Jan 2008 09:48:00 -0800)
> Some bunch of clowns have been playing around on my bro's server
> trying to set up VPN access and now they report that they can't get
> any internet traffic to either server or clients.
>
> Here's the setup...
>
> Windows 2003 Server Standard (192.168.100.1)
> 2x Lan card (1 Disabled)
> DNS
> DHCP
>
> Machines (192.168.100.x from server)
> Default gateway: 192.168.100.250
> DNS Server: 192.168.100.1
>
> Router (192.168.100.250)
> DHCP server disabled.
>
> Tests I've done:
> DHCP allocated (Pass)
> Ping Router IP from Client (Pass)
> Ping Router IP from Server (Pass)
> Ping Server IP from Client (Pass)
> Ping Server FQDN from Client (Pass)
>
> Ping Remote site from Server (Resolves IP, 4x Time out)
> Tracert Remote site from Server (Resolves IP, All nodes time out)
> Ping Router Default Gateway from Client (Fail)
> Ping Router Default Gateway from Server (Fail)

If you can't ping the router's default Gateway then the router doesn't
route or the router's default Gateway is dead or the Default Gateway
doesn't do ICMP replies. That's the first step to solve.

You have to sniff where the ICMP packets are dropped: either with a
hub or on the switch.

Thorsten

"James Snell" <(E-Mail Removed)> wrote in message
news:7D676361-E4FA-4EFA-97C9-(E-Mail Removed)...
> Some bunch of clowns have been playing around on my bro's server trying to
> set up VPN access and now they report that they can't get any internet
> traffic to either server or clients.
>
>
> Here's the setup...
>
> Windows 2003 Server Standard (192.168.100.1)
> 2x Lan card (1 Disabled)
> DNS
> DHCP

Fine. The disabled nic should also have its TCP/IP Config set to all
Automatic Addressing. If it doesn't,..enable it,...correct it,...disable it
again. Make sure the enabled nic is the first in the binding order.

> Machines (192.168.100.x from server)
> Default gateway: 192.168.100.250
> DNS Server: 192.168.100.1

Fine.

> Router (192.168.100.250)
> DHCP server disabled.

By "router" I take it tht you really mean "NAT based Firewall" since a
"real" Router only routes between LAN Segments and has nothing to do with
the Internet. So I'll assume NAT based Firewall in the rest of the post.

> Tests I've done:
> DHCP allocated (Pass)
> Ping Router IP from Client (Pass)
> Ping Router IP from Server (Pass)
> Ping Server IP from Client (Pass)
> Ping Server FQDN from Client (Pass)

Fine.

> Ping Remote site from Server (Resolves IP, 4x Time out)
> Tracert Remote site from Server (Resolves IP, All nodes time out)
> Ping Router Default Gateway from Client (Fail)
> Ping Router Default Gateway from Server (Fail)

DNS (TCP 53) outbound is being allowed by the NAT Firewall, hence the name
resolves.
ICMP is being denied outbound access by the NAT Firewall, hence the actual
Ping itself fails.

> Disabling RRAS via the wizard (+ reboot).

RRAS should not even be installed. The NAT Firewall is performing the
task,...not RRAS on the single nic server.

You can't use this box for VPN because that job will *also* fall upon the
NAT Firewall. If the NAT Firewall is not capable, then replace it with one
that is.

> Switching out the router with another and recongifguring from factory
> defaults.

There is no way I would know what the "defaults" are. With Firewall
Products like MS's ISA Server,...the "default" is to deny everything
everywhere in every direction no matter what. It only allows what you
specifically tell it to allow,...which is what any good Firewall product
should do.

> I wanted to look at the routing table, but I'm helping them remotely and
> have no access to the box / screen and they have no idea what they're
> looking
> at and confuse me even further.

The Server (and its routing table) would have nothing to do with any of
this. It is a single-nic server according to your description above and so
it has nothing to do with the Internet. Assuming that the one nic it does
have is correctly configured,...from a command prompt run the command "route
/f" to clear the routing table and then reboot the machine. The table will
rebuild [correctly] based on the machine's TCP/IP Configuration.

> They have reported that when they try to access anything on the net, LAN
> traffic slows and the traffic light becomes almost permanently lit. It
> sounds like some kind of packet storm, but I have no idea how to diagnose
> /
> fix it...

I have no idea what that is. Correct the above issues and this will
probably disappear.

Futher things to consider:

1. If a single-subnet LAN,...all devices on the LAN use the NAT Firewall as
the Default Gateway.

2. If multi-subnet LAN,...all devices on the LAN (except for the NAT
Firewall) will use the LAN Router as the Default Gateway. The LAN Router
then, in turn, will use the NAT Firewall as the Default Gateway. This will
centralize all routing decisions at the LAN Router which is what it is
designed to do and is the way it is supposed to be.

3. With an Active Directory Domain *all* devices on the LAN *must* use
*only* the AD/DNS for DNS resolution and *nothing* else. The ISP's DNS then
must be added to the Forwarders List within the Config of the AD/DNS Service
Properties. The Firewall device must allow the AD/DNS to make outbound DNS
Queries the ISP's DNS. This should be limited to specifically the AD/DNS and
the ISP's DNS in order to "weed out" any machines on the LAN with "rogue"
DNS entries.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 2. If multi-subnet LAN,...all devices on the LAN (except for the NAT
> Firewall) will use the LAN Router as the Default Gateway. The LAN Router
> then, in turn, will use the NAT Firewall as the Default Gateway. This
> will centralize all routing decisions at the LAN Router which is what it
> is designed to do and is the way it is supposed to be.

Additionally the NAT Firewall needs a Static Route entered into it that
tells it to use the LAN Router as the "path" to get to the other subnets on
the LAN aside from the subnet its internal Nic is on. You may be able to
"supernet" all of the subnets into a single route to keep it simple instead
of creating a separate route for each subnet.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

"Phillip Windell" wrote:

> "James Snell" <(E-Mail Removed)> wrote in message
> news:7D676361-E4FA-4EFA-97C9-(E-Mail Removed)...
> > Some bunch of clowns have been playing around on my bro's server trying to
> > set up VPN access and now they report that they can't get any internet
> > traffic to either server or clients.
> >
> >
> > Here's the setup...
> >
> > Windows 2003 Server Standard (192.168.100.1)
> > 2x Lan card (1 Disabled)
> > DNS
> > DHCP
>
> Fine. The disabled nic should also have its TCP/IP Config set to all
> Automatic Addressing. If it doesn't,..enable it,...correct it,...disable it
> again. Make sure the enabled nic is the first in the binding order.

Not sure what difference the settings would make on a disabled card, off
should be off and that's that, but it's not going to hurt so we'll give it a
go and let you know.

>
> By "router" I take it tht you really mean "NAT based Firewall" since a
> "real" Router only routes between LAN Segments and has nothing to do with
> the Internet. So I'll assume NAT based Firewall in the rest of the post.
>
> > Tests I've done:
> > DHCP allocated (Pass)
> > Ping Router IP from Client (Pass)
> > Ping Router IP from Server (Pass)
> > Ping Server IP from Client (Pass)
> > Ping Server FQDN from Client (Pass)
>
> Fine.
>
> > Ping Remote site from Server (Resolves IP, 4x Time out)
> > Tracert Remote site from Server (Resolves IP, All nodes time out)
> > Ping Router Default Gateway from Client (Fail)
> > Ping Router Default Gateway from Server (Fail)
>
> DNS (TCP 53) outbound is being allowed by the NAT Firewall, hence the name
> resolves.
> ICMP is being denied outbound access by the NAT Firewall, hence the actual
> Ping itself fails.

ICMP is not being denied access, nothing is presently blocked beyond the
fact that inbound ports have no endpoint mapped and no machine is mapped into
the DMZ, which is normal for NAT as the connections are all outbound.

>
> > Disabling RRAS via the wizard (+ reboot).
>
> RRAS should not even be installed. The NAT Firewall is performing the
> task,...not RRAS on the single nic server.
>
> You can't use this box for VPN because that job will *also* fall upon the
> NAT Firewall. If the NAT Firewall is not capable, then replace it with one
> that is.

It should be viable to put the server in the DMZ or map ports to route those
requests to the server, in fact, I know it is viable because I've done it in
the past.

>
> > Switching out the router with another and recongifguring from factory
> > defaults.
>
> There is no way I would know what the "defaults" are. With Firewall
> Products like MS's ISA Server,...the "default" is to deny everything
> everywhere in every direction no matter what. It only allows what you
> specifically tell it to allow,...which is what any good Firewall product
> should do.
>
> > I wanted to look at the routing table, but I'm helping them remotely and
> > have no access to the box / screen and they have no idea what they're
> > looking
> > at and confuse me even further.
>
> The Server (and its routing table) would have nothing to do with any of
> this. It is a single-nic server according to your description above and so
> it has nothing to do with the Internet. Assuming that the one nic it does
> have is correctly configured,...from a command prompt run the command "route
> /f" to clear the routing table and then reboot the machine. The table will
> rebuild [correctly] based on the machine's TCP/IP Configuration.

Ahhhah! That'll probably be what I was looking for...

< snip >

> Futher things to consider:
>
> 1. If a single-subnet LAN,...all devices on the LAN use the NAT Firewall as
> the Default Gateway.

It is a single subnet LAN and the machines use the NAT box as their default
gateway - apologies for not including it in the original description.

< snip >

> 3. With an Active Directory Domain *all* devices on the LAN *must* use
> *only* the AD/DNS for DNS resolution and *nothing* else. The ISP's DNS then
> must be added to the Forwarders List within the Config of the AD/DNS Service
> Properties. The Firewall device must allow the AD/DNS to make outbound DNS
> Queries the ISP's DNS. This should be limited to specifically the AD/DNS and
> the ISP's DNS in order to "weed out" any machines on the LAN with "rogue"
> DNS entries.

The DNS forwarder setting on the server uses the NAT box as it's source for
DNS queries, which should be fine I'm not aware of any reason why that would
be likely to fail. I have an intuition that if the routing is dead and we
set the DNS forwarder settings on the server to point straight out to the
ISP's DNS servers then it's DNS will fail too, which in itself would be a
good test.



Thanks for your help so far guys!

"James Snell" <(E-Mail Removed)> wrote in message
news:7B952719-BD08-4687-8098-(E-Mail Removed)...
>> Fine. The disabled nic should also have its TCP/IP Config set to all
>> Automatic Addressing. If it doesn't,..enable it,...correct it,...disable
>> it
>> again. Make sure the enabled nic is the first in the binding order.
>
> Not sure what difference the settings would make on a disabled card, off
> should be off and that's that, but it's not going to hurt so we'll give it
> a
> go and let you know.

If you remove the Nic with static IP settings it creates "orphaned" TCP/IP
Settings that cause it to complain if you ever put a new nic in it and try
to give it the same IP# Specs. It will complain that there is already a nic
in the machine with that address and you are causing an IP conflict,...but
you can't remove them because the old nic is gone which prevents you from
getting to the old Nic Properties to remove the specs. So you either have
to "hack the crap" out of the registry to remove the "ghost" settings or put
the same old nic back in it (exact same nic, same MAC address) and remove
them as I described.


>> DNS (TCP 53) outbound is being allowed by the NAT Firewall, hence the
>> name
>> resolves.
>> ICMP is being denied outbound access by the NAT Firewall, hence the
>> actual
>> Ping itself fails.
>
> ICMP is not being denied access, nothing is presently blocked beyond the
> fact that inbound ports have no endpoint mapped and no machine is mapped
> into
> the DMZ, which is normal for NAT as the connections are all outbound.

I can only call it by what I see described.

>> RRAS should not even be installed. The NAT Firewall is performing the
>> task,...not RRAS on the single nic server.
>>
>> You can't use this box for VPN because that job will *also* fall upon the
>> NAT Firewall. If the NAT Firewall is not capable, then replace it with
>> one
>> that is.
>
> It should be viable to put the server in the DMZ or map ports to route
> those
> requests to the server, in fact, I know it is viable because I've done it
> in
> the past.

No.
A VPN Server is a type of "router" which means two Nics with one being
Internal and one being External (like a firewall),....not a single-nic
server. There is a convoluted hack-job way to run RRAS as a single-nic VPN
Server, but there is no valid point or purpose in doing that,...you're on
your own if you insist on that,...I'm not going there. I'm here to tell you
to "correct" and most straightforward way to do this.

>> 3. With an Active Directory Domain *all* devices on the LAN *must* use
>> *only* the AD/DNS for DNS resolution and *nothing* else. The ISP's DNS
>> then
>> must be added to the Forwarders List within the Config of the AD/DNS
>> Service
>> Properties. The Firewall device must allow the AD/DNS to make outbound
>> DNS
>> Queries the ISP's DNS. This should be limited to specifically the AD/DNS
>> and
>> the ISP's DNS in order to "weed out" any machines on the LAN with "rogue"
>> DNS entries.
>
> The DNS forwarder setting on the server uses the NAT box as it's source
> for
> DNS queries, which should be fine I'm not aware of any reason why that
> would
> be likely to fail. I have an intuition that if the routing is dead and we
> set the DNS forwarder settings on the server to point straight out to the
> ISP's DNS servers then it's DNS will fail too, which in itself would be a
> good test.

Get the NAT Device out of the "DNS business". There is no good reason to
involve it at all. Just make sure the Device allows the DC/DNS to make the
outbound DNS queries and that the ISP's DNS is listed as a Forwarder in the
DNS Config of the DC/DNS. There is no reason to create an additional
"middleman" [the NAT Device] just to create an additional point a failure
and another thing to go wrong.

For that matter it should not be involved in DHCP either (if it is). You
should run that on the DC. The MS's DHCP Service is 200% more capable than
it is on these NAT Boxes.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/e...epartners.mspx
-----------------------------------------------------

"Phillip Windell" wrote:

>
> "James Snell" <(E-Mail Removed)> wrote in message
> news:7B952719-BD08-4687-8098-(E-Mail Removed)...
> >> Fine. The disabled nic should also have its TCP/IP Config set to all
> >> Automatic Addressing. If it doesn't,..enable it,...correct it,...disable
> >> it
> >> again. Make sure the enabled nic is the first in the binding order.
> >
> > Not sure what difference the settings would make on a disabled card, off
> > should be off and that's that, but it's not going to hurt so we'll give it
> > a
> > go and let you know.
>
> If you remove the Nic with static IP settings it creates "orphaned" TCP/IP
> Settings that cause it to complain if you ever put a new nic in it and try
> to give it the same IP# Specs. It will complain that there is already a nic
> in the machine with that address and you are causing an IP conflict,...but
> you can't remove them because the old nic is gone which prevents you from
> getting to the old Nic Properties to remove the specs. So you either have
> to "hack the crap" out of the registry to remove the "ghost" settings or put
> the same old nic back in it (exact same nic, same MAC address) and remove
> them as I described.
>

OK - That makes sense. Unfortunately my bro hit that exact situation after
speaking to some idiot at the place they got it from...

>
> >> DNS (TCP 53) outbound is being allowed by the NAT Firewall, hence the
> >> name
> >> resolves.
> >> ICMP is being denied outbound access by the NAT Firewall, hence the
> >> actual
> >> Ping itself fails.
> >
> > ICMP is not being denied access, nothing is presently blocked beyond the
> > fact that inbound ports have no endpoint mapped and no machine is mapped
> > into
> > the DMZ, which is normal for NAT as the connections are all outbound.
>
> I can only call it by what I see described.

Understood my friend.

>
> >> RRAS should not even be installed. The NAT Firewall is performing the
> >> task,...not RRAS on the single nic server.
> >>
> >> You can't use this box for VPN because that job will *also* fall upon the
> >> NAT Firewall. If the NAT Firewall is not capable, then replace it with
> >> one
> >> that is.
> >
> > It should be viable to put the server in the DMZ or map ports to route
> > those
> > requests to the server, in fact, I know it is viable because I've done it
> > in
> > the past.
>
> No.
> A VPN Server is a type of "router" which means two Nics with one being
> Internal and one being External (like a firewall),....not a single-nic
> server. There is a convoluted hack-job way to run RRAS as a single-nic VPN
> Server, but there is no valid point or purpose in doing that,...you're on
> your own if you insist on that,...I'm not going there. I'm here to tell you
> to "correct" and most straightforward way to do this.

They wanted to do that in the first place, have an internal and external
nic. They only reverted back to a single-nic configuration when some numpty
told them it couldn't be done that way (even though it's the way you're meant
to do it...)

> >> 3. With an Active Directory Domain *all* devices on the LAN *must* use
> >> *only* the AD/DNS for DNS resolution and *nothing* else. The ISP's DNS
> >> then
> >> must be added to the Forwarders List within the Config of the AD/DNS
> >> Service
> >> Properties. The Firewall device must allow the AD/DNS to make outbound
> >> DNS
> >> Queries the ISP's DNS. This should be limited to specifically the AD/DNS
> >> and
> >> the ISP's DNS in order to "weed out" any machines on the LAN with "rogue"
> >> DNS entries.
> >
> > The DNS forwarder setting on the server uses the NAT box as it's source
> > for
> > DNS queries, which should be fine I'm not aware of any reason why that
> > would
> > be likely to fail. I have an intuition that if the routing is dead and we
> > set the DNS forwarder settings on the server to point straight out to the
> > ISP's DNS servers then it's DNS will fail too, which in itself would be a
> > good test.
>
> Get the NAT Device out of the "DNS business". There is no good reason to
> involve it at all. Just make sure the Device allows the DC/DNS to make the
> outbound DNS queries and that the ISP's DNS is listed as a Forwarder in the
> DNS Config of the DC/DNS. There is no reason to create an additional
> "middleman" [the NAT Device] just to create an additional point a failure
> and another thing to go wrong.

I figured that knowing my bro and the muppets that his boss brings in to
"help with the IT stuff" the more info we can get direct from the ISP without
having to copy into the server, the better. But I see where you're going
with it being an additional point of failure.

>
> For that matter it should not be involved in DHCP either (if it is). You
> should run that on the DC. The MS's DHCP Service is 200% more capable than
> it is on these NAT Boxes.

Don't worry - no DHCP fights going on here.

"James Snell" <(E-Mail Removed)> wrote in message
news:514547D5-4A5C-4CFC-AA27-(E-Mail Removed)...
> A VPN Server is a type of "router" which means two Nics with one being
> Internal and one being External (like a firewall),....not a single-nic
> server. There is a convoluted hack-job way to run RRAS as a single-nic
> VPN
> Server, but there is no valid point or purpose in doing that,...you're on
> your own if you insist on that,...I'm not going there. I'm here to tell
> you
> to "correct" and most straightforward way to do this.

> They wanted to do that in the first place, have an internal and external
> nic. They only reverted back to a single-nic configuration when some
> numpty
> told them it couldn't be done that way (even though it's the way you're
> meant
> to do it...)

It can still be done. If this RRAS server is dedicated to doing only that
one job and doesn't haven aything "valuble" on it,...and is properly
hardened,...you can give it a second Nic and position it "side-by-side" with
the existing NAT Device. This requires and additional Public IP# for the
machine and a cooperative ISP that has designed their technology to handle
this properly.

Of course once this is done you could also just as easily configure the RRAS
box to also double as a NAT Server at the same time as being the VPN Server
and just totally eliminate the "home user" NAT Device.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------