• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 363
  • Last Modified:

Can't ping beyond the inward facing LAN card

Gentlemen,

I have been asked to solve a network problem with a Windows 2000 Server.

Configuration:
The outward facing Internet access is via a USB attached DirectPC network connection, and provides internet connection sharing for the lan card.
The default gateway is ff.ff.0.0 because the third tuple is different for the IP Addr and DefGw.
The inward facing lan card is made by 3Com, it's IP address is 192.168.0.1, and is connected to a hub.
The windows network icon in the tray indicates the presence of inward and outward facing network connections.
The lights on the hub correspond to the server and the wifi Access Point.
The wifi AP  is made by LinkSys, it's IP address is 192.168.0.2, and is connected to the hub.  There is no encryption.
There are 2 notebook clients with WiFi adapters, either built in or pccard.  Their IP addresses are 0.90 and 0.91.


What I can do from the server:
Ping the loopback adapter.
Ping the outward facing nic.
Ping the inward facing nic.
The server can resolve DNS and surf the internet.
The clients can ping and manage the AP fine.


What I can't do from the server:
I can't ping the AP or anything behind it.
The clients cannot ping the inward facing lan card in the server.
The clients cannot resolve DNS (surprise, surprise).


What I've done so far:
Confirmed the IP addresses are assigned correctly.
Confirmed that static addresses are used, even for the outward facing USB adapter to DirecPC.
Scratched my head and effectively walked in circles many times, to get the above information.


Wierdness:
I got this all to work.  But then I noticed that the ip address of the servers inward facing lan card was 0.1 instead of 1.1.  So I changed it to 1.1, to match the rest of the network.  It was after this, I was suddenly unable to get out of the servers' lan card.


Note: This used to work.  When I arrived at the site, the wireless network of computers was not working.  But I identified and corrected 4 problems, and got things to work swimmingly.  My customer was pleased and impressed, since a reputable someone else had already taken a stab at this and declared the problem unsolvable.  


Any thoughts?

0
ChrisEddy
Asked:
ChrisEddy
  • 7
  • 5
1 Solution
 
Netman66Commented:
OK...

External interface and subnet is not the issue.  DNS empty.  Gateway - ISP provided.

Internal interface - 192.168.0.1/24. DNS itself only. Gateway - none.  RRAS enabled for routing to external interface unless you are running a firewall (the firewall will route).  DNS server - listen only to internal interface and forward to ISP DNS.
AP: 192.168.0.2/24.  DNS your server.

DHCP should come from the server - Scope 192.168.0.1 - 192.168.0.254/24 with exclusions for 192.168.0.1 & 192.168.0.2.  Option 005 & 006 set to your internal DNS server.  Domain name (optional, but I use it).  Router - your server's internal IP (192.168.0.1).

AP should not be blocking anything - turn off any built in firewalls or filters and disable DHCP (the server will handle this).

Your clients should pull an IP from your server through the access point and be given the network card details from it's scope.

Just in case... the /24 after the IP is the subnet mask (24 bit = 255.255.255.0)

0
 
ChrisEddyAuthor Commented:
Thank you for responding quickly!

I think I understand everything you've said so far, and I agree.  Thank you.  However, I can't get that far.

Let me provide some clarification of the problem as I've measured it.  Let me know if you think I'm microscoping in too close, or making unclear assumptions.

Pinging from the Server, which contains the NIC with IP Address 192.168.0.1, I can ping the card, and the loopback, and the USB pseudo-nic, but I can't ping across the 0.1 card to the 0.2 Access Point.  

No firewalling or filtering is enabled on either the AP or on the Server.  

Since this is a locally managed and small LAN, and I just wanted to get the network to function, I chose to use static IP addresses with the plan of configuring DHCP after things are (once again) working swimmingly.

On the outside chance that the drivers within windows needed to be reestablished, I uninstalled and reinstalled both logical network devices from the device manager.  Btw: I've forgotten how to remove drivers on the hidden internal list that Windows keeps.  

Btw: when internet connection sharing was enabled on the outward facing USB pseudo-nic, there is a complaint that the ip address of the inward facing nic will be set to 192.168.0.1.  Even though the rest of the network was 192.168.1.x/24, the wireless clients were browsing the web fine.  Data was being flowed bidirectionally across the server.  

This used to work.  What I did to vary the success was to change the servers inward IP address of the 0.1 card to 1.1, because the rest of the (small) network was 1.x.  I'm really curious what I'm overlooking, or did unintentionally, because there is no magic.  


0
 
Netman66Commented:
I suggest you remove ICS from this equation - ICS uses a "lite" DHCP implementation that is creating some grief.  If you want to use ICS, you're stuck with readressing your internal network to use the 192.168.0.1 network - by default, the "host" computer for ICS uses this IP.

Instead, follow this article to use RRAS to get your internet connection going using NAT:

<http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag_rras-ch3_06d.asp>



0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
Netman66Commented:
Please also make sure you have some kind of firewall in place or your open for business (literally!!).

This will set a basic firewall in place using RRAS/NAT:

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/mpr_basicfw_configure.asp

0
 
Netman66Commented:
ahh... your = you're - sorry....
0
 
ChrisEddyAuthor Commented:
Thank you again for responding!

I am very alright with the internal network being 192.168.0.x and the inward facing lan card being 0.1.  There is no customer constraint which prevents this.

I like your thinking about the the possibility that ICS is the culprit which is introducing what appears to be routing confusion.  I will disable that next time I am at the site, and report findings.

However, there does need to be some form or IP forwarding in order for the connection to the internet to be a shared thing.  

I'm reading through the link to the MSFT document on deploying NAT.  The document makes reference to Server 2003.  It makes something of a leap of faith, reminding me of a Far Side cartoon with Albert Einstein writing equations on both sides of a black board then writes in the middle: "and then a miracle happens", in that the enabling of IP Forwarding is not shown to be something other than enabling ICS.  Perhaps I'm missing something, or haven't read down far enough in the white paper to reached it.  

Ack on the FW on the outward facing side!  

Thank you for sending some really good links.  I will read them cover to virtual cover and thoroughly digest the info.  

Btw: dnt wrry bout splling rrors.  ts th idea tht cnts.  ;-)


0
 
Netman66Commented:
The deployment of RRAS on Windows 2000 is virtually the same.  RRAS takes care of the routing (forwarding) when you set it up.

Let me know how you make out.
0
 
ChrisEddyAuthor Commented:
Gentlemen,

I have returned to the site, and disabled ICS.  I am still unable to ping something beyond the inward facing lan card to the access point or anything else on the wireless lan.

Goofy question: Is the access point equivalent to a dual homed bridge or router.  If so, then don't the IP address ranges have to be different on both sides of the access point.  If this is true, then the wireless clients would have ip addresses in the 192.168.1.x range, and the rj45 side of the ap would have ip addresses in the 192.168.0.x range - allowing the default ics ip address to work.  I'm going to try this and report findings.  


0
 
Netman66Commented:
If it is an Access Point, no.  If it's a router, yes.

What is the model # and make of the wireless device?

0
 
ChrisEddyAuthor Commented:
Gentlemen,

I found the problem, and the main problem was that I was doing a couple of things subtly wrong.  The method for solving this problem was to take it all back to networking basics, yet another living reminder that assumptions will kill you every time. The fact that someone else couldn't get this network to work, and I got the network to work then lost it, and I was getting fatiguued and frustrated, all these things were noisy distractions from the true problem.  Sometimes I need to talk a walk away from a problem or get a good nights rest to work smarter rather than harder.  But persistence is an essential element too.

The core solution was to put all interior devices onto one 192.168.0.x network.  Having two networks, wireless at 192.168.1.x and wired ar 192.168.0.x, would not work.  I did define a route across the access point, but I must have done it wrong.  

The second was to adopt a usage convention, which was more of a simplifier than anything else.  Since the clients are notebook computers that have both wired and wireless network adapters, I assigned adjacent pairs of IP addresses to each notebook.  This way, either device can be connected/ enabled, and "the network" just works.  If a network is available to both adapters, the wifi adapter is used because it is faster than the 10 mbps wired network speed.  This is a function of the metric for the lan adapter.

If you're on a 0.x network with a netmask of 255.255.255.0, you can't access a device with an ip address of 1.1, so you can't manage it.  This was a dumb error, plain and simple.  The access point is a Linksys, with a model number like WRT54G.

Another solution was to define the default gateway for all of the the adapters to the interior network to point to the inward facing lan card of the server.  Although all clients did have this defined, the subtlety is that the inward facing lan card of the server also needs to have a default gateway defined, pointing to  itself.

After the inward facing lan card on the server had a default gateway assigned, Internet connection sharing on the server was found to be a non-issue.  But it was ruled out by turning it off and making the interior wired network talk well, then add the wireless devices, then enable the outward facing lan adapter on the server that is the USB device, then enable connection sharing on the server.  

Simple, eh?


0
 
ChrisEddyAuthor Commented:
... and another thing.  The default IP address of the access point is 1.1.  Changing the IP address of the servers inward facing lan card to 1.1 silently created an addressing collision.

0
 
Netman66Commented:
Excellent.  Glad to hear you nailed it down.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now