PCs on same LAN cannot see each other

Can they both ping each other?

Cannot Ping.  To be complete, both PCs are hooked up on different subnets through a Check Point Firewall.  The rule base is very simple and the Firewall logs do not show any blocked packets when I ping.  This was also the setup prior to my scratching the laptop and it worked.

Im not familiar with checkpoint firewalls. Although if it was working before and you havent changed anything on the firewall then it points to something on the laptop that isnt correct. Could you do a IPCONFIG on both pc's and post it here.

Sure.  Is there a better way to do that than a Screen Print?  It will appear pretty small.

Hi,

Windows 7 is using on your lappy, but which OS you are using for your desktop.

You can right click and select all in a cmd window. Just copy and paste it to here.

hi
first check if the 2 computer are in the same segment.
like if the address is 192.168.10.x
the subnet mask should be: 255.255.255.0.

second, see if the computers are in the same workgroup.
you can right click on Computer --> properties.

if that don't show any sign of hope....
in the control panel try to disable the firewall and in network see if the discovery option turned on.

If there is a firewall between the two machines maybe this worked before because the laptop had a specific IP address?

Click the 'start' orb, type in sysdm.cpl and hit Enter.
Click the Change... button to get to the screen where you can set the workgroup to match the other computer's.

Ensure the LMHOSTS file in %windir%\system32\drivers\etc has the IP address of the other computer listed, if you don't have a WINS server on your LAN. There's a lmhosts.sam(ple) file there if LMHOSTS (with no extension) doesn't exist already.

If they're both running Win7 or Win8, join them both to the same homegroup.

Can you provide an IPCONFIG /ALL from the laptop?

If you see nothing in the firewall log I doubt you're using the firewall as the gateway.

It worked before, because you had cached values. Ping the other client by IP address. My hunch is, you are trying to ping a client by HOSTNAME, and that hostname is not shared through a routed network (it's held to the broadcast domain).

Hi nashim khan,

Sorry - I've just gotten home to get back to this.  Both machines are running Windows 7,

Peter

I've checked and both machines are in the same work group.  

I'm not sure what was meant by segment.  The IP addresses are

192.168.3.254 for the laptop and 192.168.4.254 for the desktop and the masks for both are 255.255.255.0.  They are on different subnets, but they were before too.  In fact, as I had a virus loose, I specifically  had to add a rule to keep the two machines from trying to communicate with each other and it blocked packets all the time.

The LMHOSTS file in that directory is a sample.

Sorry to have been remiss on replying.  I just got home,

Peter

Hi,

You said the IP's 192.168.3.254 for the laptop and 192.168.4.254 desktop.

It will not work and not ping with each other. Just change it 192.168.3.254 for lappy and 192.168.3.253 and then apply it.

Once done reboot both the machines and now try to ping it, it will work definitly, and you will solve your problem now. Go ahead with my instruction.

Thanks

I cannot change the IP addresses.  The subnets the machines are on are defined by the firewall and the firewall ports to which they connect.  The actual route between the machines looks like this

192.168.3.254 to 192.168.3.1 to 192.168.4.1 to 192.168.4.254

Plus, I'm using DHCP on the Firewall for each subnet.

Could you provide IPCONFIG /ALL output for each computer please?

> I cannot change the IP addresses.

Do you not have control over the network in question?

ping each other by IP address. Your firewall is blocking certain packets (like ICMP Echo, or NetBIOS).. If you ping by IP address, that rules out netbios port blocks. If it is a netbios problem, NetBIOS is held to the broadcast domain. Tell us if you can ping each machine by IP address and let us go from there.

If you ping by IP address, that rules out netbios port blocks.

Not really... ICMP isn't NetBIOS traffic, so it could be blocked even if ICMP isn't.

The OP said that the PCs are on separate subnets and that it used to work before the PC was wiped - therefore it's likely a local IP address or local firewall issue.

If ping is unsuccessful it could mean anything:

1] The wrong IP based on a firewall rule which specifically allowed an IP to pass
2] The wrong gateway address
3] The wrong subnet mask
4] Failed DNS lookup (must be DNS as on different subnet and no WINS)
5] Blocked ICMP at the Checkpoint firewall
6] Firewall on the local PC blocking outbound ICMP

Let's check the basics first...

@Peter023 - please, provide an IPCONFIG /ALL output from the two PCs so we can see what configuration they both have.

Is it too much to ask to ping the machines by IP ADDRESS, ruling out name resolution between the two subnets? Why is there always an argument when I post on this site.

I do have 35 years of experience and 8 years of school in IT. I have my ways of troubleshooting that are not so invasive. Being on two subnets means that the author could be running into a type of protocol that is held to the broadcast domain and not shared over a routed or VLAN configuration. When the author wiped the machine, he also wiped out CACHED records to include the NetBIOS cached entries. By pinging via IP address, it rules out the fact that NETBIOS is possibly the problem because this did work before and that means ICMP ECHO is allowed through the firewall.

@chief - no one is having an argument.  No one has said that pinging is a bad idea.  All I said was that just because ping returns success doesn't necessarily mean that NetBIOS is also guaranteed to be successful.

But, pinging by IP doesn't necessarily rule out name resolution.  It just proves that a ping is successful, or not.  If the ping is unsuccessful when pinging by IP alone, name resolution doesn't even come into it unless a reverse lookup is requested.  Therefore you haven't proved anything related to name resolution.

This is the output from a ping on my laptop.  The first ping is by IP, with no name resolution, and the second is using rDNS via the -a switch.  The point I'm making here is that a standard ping by IP involves no name lookups at all.

C:\Users\craigbeck>ping 192.168.100.5

Pinging 192.168.100.5 with 32 bytes of data:
Reply from 192.168.100.5: bytes=32 time=23ms TTL=128
Reply from 192.168.100.5: bytes=32 time=9ms TTL=128

Ping statistics for 192.168.100.5:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 23ms, Average = 16ms
Control-C
^C
C:\Users\craigbeck>ping -a 192.168.100.5

Pinging 2K8-DC [192.168.100.5] with 32 bytes of data:
Reply from 192.168.100.5: bytes=32 time=3ms TTL=128
Reply from 192.168.100.5: bytes=32 time=4ms TTL=128

Select allOpen in new window

Being on two subnets means that the author could be running into a type of protocol that is held to the broadcast domain and not shared over a routed or VLAN configuration.

Correct.

When the author wiped the machine, he also wiped out CACHED records to include the NetBIOS cached entries.

This is only true until the PC restarts, then all cached entries are flushed.  This is not the same as adding static entries to the LMHOSTS file, and preloading them using the #PRE keyword.

By pinging via IP address, it rules out the fact that NETBIOS is possibly the problem because this did work before and that means ICMP ECHO is allowed through the firewall.

No it doesn't; it rules out ICMP being blocked at the firewall.

All I am saying is let's go back to basics first before we start pointing the finger at lots of things which might not work anyway if the basics aren't set correctly.  I do this day-in, day-out and it's the basics which are the cause 95% of the time.

Sure, it may be NetBIOS which isn't working, but it also might just be that the gateway is set wrong.  It's best to be sure though and go through all of the steps in a methodical manner.

>>"All I am saying is let's go back to basics first before we start pointing the finger...."

I believe that is what CheifIT is saying.  Start with a basic Ping by IP.
Failure or success determines the next steps; firewalls, routing & default gateways, and protocols.

Failure or success determines the next steps; firewalls, routing & default gateways, and protocols.

But it doesn't.

If the basic IP details aren't configured correctly then the ping could fail for one of a number of reasons.  It might be the firewall.  It might be the gateway configured incorrectly...

Come on, I could blame the fuel pump, the spark-plugs, the battery, the ECU and the chip in the key if my car doesn't start, but if I don't put the right fuel in it it's never going to work!

What's the most fundamental part of client connectivity across an IP network apart from the physical media?  It's IP configuration.  Therefore, check what you're supposed to have first, then expand the search to other areas.

The OP clearly says that this only failed after a wipe of the laptop.  That should tell you that it's something local to the laptop which is causing this.

>>"If the basic IP details aren't configured correctly then the ping could fail for one of a number of reasons"
Exactly, it fails, so you take the next steps.  However, if it succeeds you know the IP configuration is correct, routing, VLAN and default gateway are OK.  Four things you then do not have to review.  

I don't think you will find an IT expert that would not agree an IP ping is the very first, and easiest step to try.

Where these two devices are on different subnets the IP configurations are not going to tell you much without also having route print output, VLAN information, and router configuration.

@ Peter023..
 
1) Can you ping by IP?
1a) If yes, it is a Name resolution problem.
1b)If not, can you go to the wiped/reloaded system and see if Windows firewall is enabled (the host-based firewall). Windows firewall is enabled by default of bringing up a system and both ICMP echo (ping) and Netbios (file and print sharing) are blocked by default. You can make edits to windows firewall by allowing ICMP ECHO (ping) and File and Print Sharing (NetBIOS). With those edits: NOW ping by IP should work again, because the current network configuration worked before. SOOOO, can you ping by IP?
-----------------------------------
Once you can ping by IP:
2) Can you ping by HOSTNAME.
-I doubt it, because your computers are on different subnets. The name resolution records needed to convert your hostname to IP address are populated by BROADCAST. They are held to the broadcast domain and will not go to different subnets.

If you can ping by IP but not HOSTNAME, it means you have a NAME resolution problem.

THEN this answer posted earlier is absolutely correct:
--Darr247 Posted on 2014-01-02 at 05:54:57ID: 39751478
----------------------------------
A couple experts on the exact same path, and all it takes is answering this one quick and simple question: Can you ping by IP?

Ok, so ChiefIT you're absolutely incorrect here...

They are held to the broadcast domain and will not go to different subnets.

If broadcast forwarding is enabled traffic on port 137 which is broadcast across the VLAN can be forwarded to other subnets/VLANs, or to other hosts on other subnets/VLANs.  So, the broadcast MAY go to different subnets/VLANs.

1) Can you ping by IP?
1a) If yes, it is a Name resolution problem.

It MAY be a name resolution problem is more accurate.  As I said, there are other factors which could affect this even if name resolution isn't working now, such as IP configuration.

2) Can you ping by HOSTNAME.
-I doubt it, because your computers are on different subnets.

But it worked before across subnets so how is your logic correct here?  Could it be that it is a name resolution problem because the firewall is blocking NetBIOS traffic?  Does that sound fair?

I'm not trying to poke holes at anyone, but we're supposed to be providing expert help here.  If something isn't correct, let's not say it.  I don't know why you're so against checking the basics?  It's the first rule of troubleshooting.

Let's see...

@Peter023 - can you see the remote PC if you enter \\192.168.4.254 in the address bar in Windows Explorer?  THAT will tell you if it's more likely to be a name resolution problem.  If you can see the remote PC using the IP, it's a name resolution issue.  If you can't it could be anything.

We need to see the IPCONFIG output, and a list of firewall rules if you can't see the remote PC.

"how is your logic correct here?"--It's called CACHE. Do you know what a cache record is? The client PC, before being wiped had a NetBIOS cache record. I have seen this cached record last over a year when helping out probably a couple hundred other people on Experts Exchange with similar problems.
--------------------------
If broadcast forwarding is enabled traffic on port 137 which is broadcast across the VLAN can be forwarded to other subnets,

(ONLY IF IT IS CONFIGURED. WHAT MAKES YOU BELIEVE IT WAS EVER CONFIGURED).
---------------------------
can you see the remote PC if you enter \\192.168.4.254 in the address bar in Windows Explorer?

Or, you can ping the IP address. Not seeing those clients there, will NOT tell you if OSI L1 and L2 and L3 are working correctly. Successfully pinging by IP address does, and THAT'S WHY I TROUBLESHOOT BY PINGING IP ADDRESS, FIRST. -You see, that's "providing expert help here".

Hi Guys,

Pinging by IP was one of the first things we tried.  See first posts.  They cannot ping each other.

I do have control over the network, however I am unwilling to rewire the subnets to fix this problem.  It was working fine with this setup prior to reinstallation of the OS.

I'm attaching the IPCONFIG/ALL for both machines.

Thank you all for your attention and assistance with this,

Peter
Desktop-IPCONFIG.txt
Laptop-IPCONFIG.txt

I cannot see either machine by trying to browse to their IP addresses.

I'm sorry, but I did not understand how to edit Windows Firewall.  I took a quick look at the options, but did not see anything that would enable or disable ICMP.  I was surprised to learn that ping was blocked by default.

I am attaching a screen shot of the firewall rules.
Firewall-Rules.png

This is starting to look like some sort of quiz or test.

In the initial question you fail to mention they are on different subnets, and a Checkpoint firewall.  Now you reveal multiple physical and virtual NICs on numerous subnets, with multiple default gateways on the same device, which is not supported.

We really need to have a better understanding of the entire network.  Also when you say a CheckPoint firewall are you reefing to a proper Checkpoint hardware or a Checkpoint software addon such as with ZoneAlarm.

I apologize for having been incomplete in my description.  I thought this would be a simple PC configuration issue.  I'm not sure what else to tell you regarding the network setup.  There are 2 PCs, a desktop and a laptop, and the firewall, which is a Check Point 2200 running R75.40.   Please let me know what other information would be useful and I will try and supply it.

Peter

To confirm it was the laptop that was rebuilt, and it's computer name is "Bedroom"?
Also the only change was it being rebuilt?
Presumably it must be a configuration change on it.

Firstly it has 2 NIC's each with it's own default gateway.  Windows will not support multiple default gateways.

What are 192.168.3.1 (wired) and 192.168.2.1 (wireless) gateways?  
I assume one is the Checkpoint, and the other?

In order for the laptop to ping the desktop on the other subnet it needs to know the route.
If you remove the second gateway from the second NIC, it should default (default gateway ) to the router which should know the route or you may also need to add to the laptop a static route such as:
route -p add 192.168.4.0 mask 255.255.255.0 192.168.3.1

The desktop also needs the return route, but presumably that is still OK.

Hi RobWill,

Yes, you are correct.  

I believe you have found the issue, but it will take me a bit of time to verify.

Both adapters are going to the Checkpoint, the wireless one via a wireless router on another subnet on the firewall.  I believe what has probably happened is that I had disabled the wireless adapter in the previous incarnation and forgot to disable it after rebuild.  I've disabled it now and will give the network some discovery time.  No immediate change occurred and I can't reboot just at the moment.

Changes to the routing table, such as disabling an adapter may require a reboot to clean up.  
I would again test by pinging the IP, at least first.

Even if pinging from laptop to desktop works, you may still have to tweak the firewall on the laptop to allow access from the desktop.  Many firewall rules are automatic, such as file and print sharing, as soon as you enable the feature.  However they often only allow access from the local subnet.  You may have to add the remote subnet or all, but start with pin, by IP, from laptop to desktop.

I had hoped that would have done it, but I've rebooted both machines now and cannot ping either.  I pinged each hop in the route and was able to successfully ping the NIC of the laptop's subnet (192.168.3.1) from the desktop, but not the laptop itself.  Any ideas?

Peter

If the laptop doesn't have the return route via default gateway, or local static route, it will fail, as will the other direction.

Peter: I think you misunderstood a previous post. When you install an OS fresh, Windows Firewall on the machine is automatically enabled. By default Windows Firewall blocks ICMP Echo. This might be as simple as Windows Firewall.

How to fix:
http://technet.microsoft.com/en-us/library/cc749323%28v=ws.10%29.aspx

Thanks RobWill.  I don't think I'm understanding.   I disabled one of the two adapters, but the direct line to the Firewall is still up and running and has a default Gateway.  I thought that would have fixed the issue.

That looks like a really good article.  Thanks.  I'll give it a go and come back to you, but it will take a day or so.

I agree windows firewall will be enabled on rebuilt machine ( laptop) which is why I suggested pinging desktop from laptop.

Could you provide results from route print on laptop.

3am here, will jump back in tomorrow.

Rob: I agree with everything step you are taking.

I saw the two computers couldn't ping each other. Since the desktop worked before, I think it's safe to assume its firewall settings are most likely right (still need to ensure the laptop firewall is right or ping tests will be inconclusive).  

The root cause is probably bad entries in the ARP Cache of the dual-default gateway computer. So, I see where you are going with the route print as well.

You are concise as usual, Rob.

So, it wasn't a name resolution issue then??

Just to be clear...

by: Peter023Posted on 2014-01-04 at 02:55:32ID: 39755492

Hi Guys,

Pinging by IP was one of the first things we tried.  See first posts.  They cannot ping each other.

Also, please refer to "http://filedb.experts-exchange.com/incoming/2014/01_w01/826383/Laptop-IPCONFIG.txt" in the same post, which provides all of the information which is required to assist in solving this problem.

Now,

"how is your logic correct here?"--It's called CACHE. Do you know what a cache record is? The client PC, before being wiped had a NetBIOS cache record. I have seen this cached record last over a year when helping out probably a couple hundred other people on Experts Exchange with similar problems.

I know exactly what a CACHE record is.  Unfortunately it appears you don't.  If a CACHE record remains in the cache for over a year it will be simply because the record is preloaded from the LMHOSTS file.  Therefore it isn't actually CACHED - but SAVED.

If broadcast forwarding is enabled traffic on port 137 which is broadcast across the VLAN can be forwarded to other subnets,

(ONLY IF IT IS CONFIGURED. WHAT MAKES YOU BELIEVE IT WAS EVER CONFIGURED).

I didn't say it was.  I said IF.  I was considering all possible solutions as we didn't know for sure how it was configured.

Or, you can ping the IP address. Not seeing those clients there, will NOT tell you if OSI L1 and L2 and L3 are working correctly. Successfully pinging by IP address does,

Unfortunately, a failed ping (as the author already said was the case at this point  incidentally) would not tell you anything either.  So, your statement is exactly the same as mine and would only help IF the result was successful.  Therefore there is no benefit to using ping against UNC path.

The root cause is probably bad entries in the ARP Cache of the dual-default gateway computer. So, I see where you are going with the route print as well.

Assumption again - and also complete rubbish.

Changes to the routing table, such as disabling an adapter may require a reboot to clean up.  
I would again test by pinging the IP, at least first.

No, not in Windows 7.  A simple disconnect of the NIC, or a disable/enable will do.

Even if pinging from laptop to desktop works, you may still have to tweak the firewall on the laptop to allow access from the desktop.

EXACTLY my point.  Thanks for confirming!

Firstly it has 2 NIC's each with it's own default gateway.  Windows will not support multiple default gateways.

Yes it does, by using dead-gateway detection for example.  It is not recommended but it is definitely supported.  Default gateways which are configured on separate NICs are easily manipulated using interface metrics.


Reading the provided detail and obtaining as much extra information as possible is the number one priority when trying to troubleshoot issues.  If you only have half the story you'll end up saying "It's definitely name resolution", when in fact it is the wrong gateway (as I said I'm sure).

Oh just saw this too...

I saw the two computers couldn't ping each other. Since the desktop worked before, I think it's safe to assume its firewall settings are most likely right (still need to ensure the laptop firewall is right or ping tests will be inconclusive).

Need I say more??

@ craigbeck I am not sure all of that is helping Peter.  It sounds more like a defense because I/we have offended you.  I apologize if we have done so.
--Rob

@ Peter, I agree the firewall will have to be edited as CheifIT stated, before the desktop can ping the laptop, but if nothing has changed on the desktop and laptop to desktop is still not working the route print from the laptop may help help.

You can run from a command line:
route print  >C:\Temp\RoutPrintResult.txt
Then copy the text file results.  (Assumes C:\Temp exists)

@RobWill - I'm not particularly defending myself as I don't really need to.  And no, you haven't offended me at all.

To cut a long story short, some of the information provided to Peter is incorrect - that's what's not helping.

As an expert and someone who gets paid to work in this field (even though I contribute here for free) I feel compelled to comment when incorrect information is given to someone who is asking for help, especially when someone who is also supposed to be an expert and fellow professional practically jumps down my throat for suggesting something different to their opinion. (This was not you BTW).

I am sure you would agree, if someone told you that your boiler was defective and needed replacing you'd be a bit annoyed if the problem was simply that the water was turned off.  Similarly, if the problem was resolved after spending hundreds of pounds paying someone for their time, only to find that the issue was resolved by 'turning it on' first, I'd not be impressed.  You get what I mean...?

I wasn't ever suggesting that a ping was pointless, or that it wasn't the first port of call for a quick check.  I was saying (a) that it wouldn't prove conclusive, and (b) that it had already been done.  If you look back over this thread you'll see that nothing I said ever contradicts this.

Anyhow, if I have offended anyone here I too apologise.

Any progress Peter?

I am curious, your question tile was "PCs on same LAN cannot see each other" but these devices are not really on the same LAN, but rather each on its own network segment or subnet.   Using different subnets is usually done to isolate traffic yet you want to be able to access devices on the other subnet/s.  Is there a reason you do not want them all on the same subnet?  That would be normal, especially in a small network of less than 100 devices.  It also simplifies routing, name resolution, and firewalls.  I appreciate there may be reasons you wanted to do so, but just a suggestion.

Hi RobWill,

Was that a DOS command?  It wasn't recognized.  Did you want a Tracert?

This is more of a testing environment.  You would never put a 2200 into an environment with just 2 PCs.  I agree it's way more complicated than it needs to be, but it should theoretically work.

Peter

Yes a DOS command.
You could also just run    route print     and copy and paste the results.

No problem as I said if you have reasons to have the multiple subnets, such as a test environment.  Just wondered if it was necessary.

No problem.  I appreciate the advice.  Here's the data:

===========================================================================
Interface List
 20...30 85 a9 9a 26 7e ......Realtek PCIe GBE Family Controller #2
 18...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
 19...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.4.1    192.168.4.254     20
        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
      192.168.4.0    255.255.255.0         On-link     192.168.4.254    276
    192.168.4.254  255.255.255.255         On-link     192.168.4.254    276
    192.168.4.255  255.255.255.255         On-link     192.168.4.254    276
     192.168.13.0    255.255.255.0         On-link      192.168.13.1    276
     192.168.13.1  255.255.255.255         On-link      192.168.13.1    276
   192.168.13.255  255.255.255.255         On-link      192.168.13.1    276
    192.168.116.0    255.255.255.0         On-link     192.168.116.1    276
    192.168.116.1  255.255.255.255         On-link     192.168.116.1    276
  192.168.116.255  255.255.255.255         On-link     192.168.116.1    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.4.254    276
        224.0.0.0        240.0.0.0         On-link      192.168.13.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.116.1    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.4.254    276
  255.255.255.255  255.255.255.255         On-link      192.168.13.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.116.1    276
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    306 ::1/128                  On-link
 20    276 fe80::/64                On-link
 18    276 fe80::/64                On-link
 19    276 fe80::/64                On-link
 19    276 fe80::1017:e30b:e624:b3a7/128
                                    On-link
 18    276 fe80::192c:e05:10b9:6936/128
                                    On-link
 20    276 fe80::f9ed:ec09:292e:84d4/128
                                    On-link
  1    306 ff00::/8                 On-link
 20    276 ff00::/8                 On-link
 18    276 ff00::/8                 On-link
 19    276 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Though that may prove to be helpful it was the route print from the laptop I was looking for.

However, looking at the desktop (on 192.168.4.0/24), there is no defined route as to how to reach the 192.168.3.0/24 network, the laptop.  Thus it will use the default gateway, the router 192.168.4.1

Presumably then the Laptop will be configured in the same way, so both are dependent on defined routes in the Checkpoint firewall.  I am not familiar with Checkpoints so I am of no help there.

Isn't it significant that the two subnets can ping each other?  I can ping 192.168.3.1 from 192.168.4.254.

@ Rob:
I also see the firewall (CheckPoint firewall this time) has an intrusion prevention system (IPS). It's just one other possibility, not yet explored.

>>"Isn't it significant that the two subnets can ping each other?  I can ping 192.168.3.1 from 192.168.4.254. "
That would depend on the Checkpoint rules as to whether they are based on subnets or IP's.   Also 192.168.3.1  is not an external device, it is the router itself.

It may be difficult for us to diagnose routing, or IPS issues as CheifIT pointed out, with the router.

Please can you post the Checkpoint firewall rules, either by screenshotting or by exporting the rules to a HTML file.

Sure.  Here you go.  Please note that Rule 4 is disabled.
Firewall-Rules.png

Sorry - my bad.  Rule 3 is disabled.

Ok thanks.  Can you tell us what Rule2 is for?

I had a friend who was helping me with another issue remotely and we added that rule to make sure that he could have access.  I've been meaning to take it out.

I'm wondering why there are no hits on any of those rules.  I would expect to see at least something on rule 4.

Can you confirm that both the laptop and the desktop get to the internet via the Checkpoint?

I am not familiar with the required configurations of CheckPoint Firewalls, but there do not appear to be any rules between subnets.  Are trusted interfaces allowed all communication by default?

You know, I was wondering that myself, but I hadn't had a chance to explore it.  I've attached a screen shot from SmartView Tracker which is definitely showing current, rule-based activity.

Yes, they both get to the internet via the firewall.  There are four devices connected to the firewall, each on its own subnet.  In addition to the 2 PCs there is a wireless router which is connected to nothing and there is an ADSL2+ modem.
SmartView-Tracker.png

@RobWill - the rule 4 configuration allows network objects in the source field to access anywhere as designated in the destination field.  Each line in the Rule 4 'source' field is a separate network object, so that rule allows eth2_Subnet to get to any destination, as well as eth3_subnet, etc.

This rule base is trivial and I have really haven't started work on it.  It has a bare minimum of stuff, but  rule 4 is the important one.  It allows all traffic originating on 5 of the subnets, the ones behind the firewall, to any destination.  That would allow all the subnets to reach each other.

Ok Peter, can you filter the firewall log and use just the IP of the laptop (or the subnet) in the origin field so we can see what the firewall is doing with the traffic?

I don't see anything in the firewall rules that would appear to block you and it is a significant fact that the two subnets can communicate except the transaction between two clients. Yet Craig is right. The firewall logs would hint of any blocks based on the firewall rules.

Intrusion Prevention System and Intrusion Detection Systems terms are often used interchangeably. But, there is a difference. IPS will dynamically block (actively) anything it deems as a threat or creates an event. IDS will notify (passively) anything it deems as a threat.

It is a significant fact that your two subnets can communicate. It is a significant fact that the one that can not communicate is the one that had viruses and was reformatted/reinstalled. My point is, I don't think this is a firewall block between subnets, as much as an dynamically created IPS block on one or both of the machines you are trying to communicate with.  

IPS's can be host based, or network based (your checkpoint fireall is a network based IPS). Host based can also exist on the computer via third-party software (like a McAfee HIPS add on to your antivirus console).  

The block will be separate block from firewall rules. In addition to checking the firewall logs (and I am not familiar with Checkpoint) check your IPS logs on the IPS tab of the web page interface.

Since IP addresses can change, IPS's usually block by MAC address. That would explain the inability to communicate with the virus, and the inability to communicate AFTER reformatting and bring up the system fresh. The MAC block may still exist. That doesn't explain how you got a dynamic IP address from the DHCP server, though.

That's a great analysis.  I will turn off the IPS today and test it.  However, I still haven't successfully edited the Windows Firewall settings to allow ICMP Echo.  I just haven't had a chance yet, but will try and get both of these tested today.

Don't take this the wrong way but the MAC address is still the same, so if IPS is blocking by MAC address, why wasn't it prior to the format and reinstall?

IPS is usually IP-based due to the fact that intrusion prevention is required from hosts on remote networks.  The source MAC addresses of the remote host isn't in the packet's header when it arrives via a router - it is actually substituted with the sending router's MAC address at each hop.

I would either disable IPS completely to test, as ChiefIT suggests, or set it to detect-only.

Also, turn off the Windows firewall to see what happens.

For info the R75.40 manual is here...

http://dl3.checkpoint.com/paid/2a/CP_R75.40VS_IPS_AdminGuide.pdf?HashKey=1389049370_f38aad7dc8e1cc772b14dcd43cb0ced6&xtn=.pdf

"Don't take this the wrong way but the MAC address is still the same, so if IPS is blocking by MAC address, why wasn't it prior to the format and reinstall?"

I am not sure it wasn't blocking prior to format/reinstall. Maybe it worked a couple days prior to the infection/virus. I am making an assumption the format/reinstall came from not being able to communicate and the author assumed there was still problems coming from the infection of the computer. Since he couldn't communicate, why not "format/reinstall"?

-------
You also make a VERY GOOD point that kind of had me wondering, prior to posting (when blocked by MAC on a network IPS). Also when blocked by MAC, he should not have any comms to anything (including DHCP). The IPS's that I have worked on block DHCP req and everything because the host computer is blocked by MAC. However, I use Host-Based IPS's so I don't knock down an entire network with dynamic IPS blocks.

One thought on my mind was, the amounts of pings going across could red flag the IPS to a possible Denial of Service attack or ping sweep and then the IPS would take action to block the suspected host's ICMP traffic in and out.

When messing with IPS's that dynamically create its own rules, they are fickle as heck. This is why I like host-based IPS's with centralized management, because you have more granular control per system.

Pinging is now working between both machines.  Although I've also disabled the IPS (as well as the AV and anti-bot and anti-spam), I'm reasonably certain it was the Windows Firewall rule change that did it.  However, I am still unable to see either machine from the other in Windows Explorer.

I'm attaching another screen print from SmartView Tracker. This is after the other blades have been turned off and the firewall edits were made to all ICMP Echo Requests.  I've filtered the origin on the laptop as requested and did a ping from the laptop to the desktop just before taking this shot.
SmartView-Tracker.png

Windows firewall is a system-state firewall. In other words, if there is a block rule, it will only block unsolicited traffic to that machine. It means if the client has the rule, it will block traffic it did not initiate.

Examples:

1) If you ping FROM the computer with Windows firewall ON, it should get a response back because that computer initiated the traffic.

2) If you ping TO a computer with Windows firewall ON, it will drop the traffic because it was unsolicited from the host pinging that computer.

The point is: If this worked before the reinstall of the OS, Windows Firewall should have only prevented ping traffic one way (FROM any computer to Laptop) unless both computers had Windows Firewall ON, to block ICMP Echo. Since both computers were unable to ping each other, either both had Windows firewall blocking incoming ICMP, OR there was probably an IPS rule (dynamically created) that prevented ICMP between them.

Hi ChiefIT,

I'm not sure I understand:  I understand your explanation of the Windows Firewall blocking, but Windows Firewall was turned off completely prior to my scratching the laptop.  That would have allowed the desktop to ping the laptop successfully, which I remember doing often.  I'm not sure that I explicitly pinged from the laptop to the desktop.  It's possible that I never did.

In either case though, IPS is now turned off as is AV and the other blades.  Both machines can now ping each other, but neither can see each other via Windows Explorer, so I believe the problem still exists - whatever it is.

Now that they can ping each other, does that open up any other areas for exploration?

Thanks

Peter

Have a look here, Peter...

http://homeworksblog.wordpress.com/2010/06/12/unable-to-use-unc-share-win7/

"Both machines can now ping each other, but neither can see each other via Windows Explorer, so I believe the problem still exists - whatever it is."

NO, we are making progress. There was more than one problem. Now that we can ping by IP, we have to solve name resolution. Remember back when I asked if you could ping by IP, but not hostname. Well, you can now ping by IP, but the host name does not resolve to IP. Your problem now is, NetBIOS resolution.

You will probably be able to ping by fully qualified domain name..
Ping laptop.mydomain.com

You will probably be able to ping by IP address.
Ping 192.168.3.5

But, you can't ping by hostname.
Ping laptop

Nor will you see them in the computer browser.

The hostname to IP records are populated by true broadcasts and held to the broadcast domain. They are also blocked by windows firewall (as a file and print sharing rule).

To fix this, those broadcasts need help either reaching the other subnets, or shared over a TCP/IP connection between a designated computer called a NetBIOS name server.

There are many ways to approach this, but first we have to ask a couple questions:

1) Can other computers on your Desktop subnet see each other?
2) Can computers on your Desktop subnet see others on other subnets?
3) Can computers on the laptop subnet see each other?
4) Can computers on the laptop subnet see other subnets?

Have you tried opening \\192.168.4.254 since you disabled the firewall, etc?

If you can't open the desktop in explorer by using \\192.168.4.254 (or whatever its IP address actually is), forget name resolution.  The fact that you can't open the remote computer by IP is probably a lot of the reason why you can't resolve the name.

There are no other computers running in this environment.  Just one computer on each of two subnets, so I can't answer the visibility question.

I was unable to browse to \\192.168.4.254 from a couple of different browsers - Page Not Found

I checked for hidden network cards and adapters in the Device Manager and couldn't find any.

Try browsing that address in Windows Explorer, or straight from the Search box in the Start menu.

No luck.

There is no hosted web page on that machine, hence "page not found error". You can try by mapping a network drive.

Try this instead: \\192.168.4.254\c$

That tells the browser you are trying to access the default admin share of the computer. It should ask for credentials for access.

No luck again.  Just to be complete, I use Chrome and initially when I typed the string in from your post I got Page Not Found.  However, I'm on the desktop and trying to reach the laptop so I probably should have keyed in 192.168.3.254.  When I did that, the message in Chrome changed to Oops! Could Not Connect.  I tried it with your new string and the 3.0 subnet and got the same behavior.  I then went and tried the same thing on IE entering ": \\192.168.3.254\c$" in the address field and got a dialog box pop up "Windows cannot find : \\192.168.3.254\c$.  Check the spelling and try again.

Just try it without the \c$ bit on the end. Windows may not be administratively sharing the C drive by default...

So just \\192.168.3.254 in the search box in the Start menu.

No results.

I know you said it's just a couple systems on different subnets. Is there a domain controller anywhere? Kind of an elaborate setup for a small work group of computers. That's why I ask.

Also, Craig is right these systems may not be sharing out. On the NIC adapter settings is "Client for Microsoft Networks" and "File and Print Sharing" services installed for all your machines?

The system is overly complicated for a production environment.  It's more like a lab.  There are 5 pieces of hardware:  modem, firewall and connected to different subnets on the firewall are a laptop, a desktop and a wireless router.

I was going back to the lack of hits on the rules in firewall log.  Is it possible that I might need to explicitly prevent NATing from one subnet to the other with a rule?

It could be due to NAT, but that wouldn't explain why it worked before. It would make me wonder 'how' it ever worked more than anything.

Maybe try to put these systems on the same subnet and see if they communicate for a moment. Then, put it back and see if they communicate with cached records. If so, that would confirm the hunch this is a name resolution problem between the subnets. Right now you can ping between them. So, IP and Natting, should be OK, I would think.

As I said that wouldn't prove name resolution is the issue. It might prove name resolution is not working, but it could just be broadcast traffic which is blocked.  Name resolution is reliant on broadcast traffic being allowed though, but we already know it doesn't work via IP either, so name resolution is just one issue and not the cause.

Your plan is good though. Eliminate routing and firewalls and try on the same broadcast domain.

I have put them both on the same subnet and they can see each other in Windows Explorer.  I've put them back where they were and they cannot.

So if you can't see the remote PC on the separate subnet by trying to get to \\192.168.4.254 you likely have an issue with ports 135-139 not being able to cross the router/firewall.

Can you see if the Checkpoint lets you forward broadcast traffic on those ports?

Sorry, I'm don't know how to check that.  

In general, the rules that I have set up will allow all traffic originating within my network to go anywhere, so my understanding would be that unless I explicitly blocked the traffic, it would be allowed through.  

FYI, the pings are working as well.

Broadcast forwarding is a bit different to firewalling.

Have a look at the Advanced Routing Guide (p37)...

http://dl3.checkpoint.com/paid/be/CP_R75.40_Gaia_Advanced_Routing_AdminGuide.pdf?HashKey=1389617791_6065cf4501e74bb00574daa95102b520&xtn=.pdf

OK, after the subnet tetst, I opened up an SR with CheckPoint.  They've looked at the issue for a few hours and (wait for it) have blamed Microsoft.  The hit count being turned off was a reasonably easy fix and is now working.  That was only a toggle that had to be flipped.  The other issue, of the attempts to browse from one to the other not showing up in the Checkpoint logs (which led me to believe that the firewall was blocking the attempts) turned out to be a CheckPoint bug and I've opened up an SR on it.  Although SmartTracker does not see any attempts by either PC to reach the other, when we put a TCPDUMP on both ends, the traffic (from attempts to browse to each other) are in fact there.  We see many attempts from the desktop to reach the laptop which make it past the Firewall, but the two PCs are unable/unwilling to connect.  The connection attempts from the desktop go unrequited, but are getting through.

Checkpoint felt that this may have been some Windows settings preventing PCs on different subnets from talking to each other.  For example, both PCs had the networks defined as "Home" and they initially thought that Windows may have assumed no home would have more than one subnet and therefore would have blocked the connection attempts.  There is also the possibility of some homegroup/domain in compatibilities.  I'm pursing the SmartTracker issue with them, but they've discounted the Firewall in this issue.

I will still try and get through the manual regarding broadcast forwarding, but I thought I'd report this development first.

By the way, just a few more notes.  I've re-enabled the wireless adapter on the laptop which now has two default gateways, one on each adapter, and it seems to be working fine.

Also, I inserted the NAT rule to make sure that NATting was not done between subnets and it made not difference.  I've removed the rule now.

Two default gateways will not work with Windows and is not supported.  In theory you define metrics which sets the priority.  The higher priority will only be used unless it fails then the secondary will take over.  However in windows it doesn't work properly and the primary will never be reinstated unless you do a reboot.

Dead gateway detection will allow the primary ISP link to come back but only when the backup ISP link fails, unless you either reboot the PC as RobWill said, or disable/enable the NIC (or unplug it, or do a DHCP release/renew.

The issue RobWill mentioned with not failing back properly was only an issue pre-SP1 in Windows XP.

What 'exactly' do you have two NICs with different gateways configured for anyway?

I have a wireless and a wired adapter on the laptop.  The wireless router is on 192.168.2.0 and the wired adapter is on 192.168.3.0.  Because I am not using the LAN port on the wireless router to connect it to the firewall, the only way to reach the router from a configuration point of view is through a device connected to it wirelessly.  But obviously, the wired connection is faster, so I tend to leave them both enabled and connected.  I don't actually need them both, but as I occasionally need to reach the router, I leave it enabled.  If you feel it's a problem, I can leave it disabled until I need it.

Let's keep it simple for now :-)

Think logically.  The connection between the two machines works fine on the same VLAN, but not when a firewall is in the way.  It's fair to say then that the firewall device DOES cause an issue, regardless of what Checkpoint tech say (maybe not the firewall feature, but something on that box).

If broadcast forwarding for UDP/135,137-139 isn't working I'd say this is probably the issue.  You also need to ensure that ALL of these ports are allowed between each PC in order to ensure that the firewall isn't blocking anything which may be required...

TCP/UDP 135
TCP/UDP 137
TCP/UDP 138
TCP/UDP 139
TCP 445

I'm not so sure.  When the firewall was taken out of the loop, the two PCs were then on the same subnet.  Then they could see each other.  I do not have the equipment to test the PCs with a different router, other than the firewall, who can connect the subnets.  I cannot conclude that it is the firewall actively interfering with the traffic as opposed to a problem being caused by the PCs being on the different subnets and we've now seen the traffic successfully exiting the firewall with the correct destination addresses via TCPDUMP.

Well if you think about it, Windows file sharing is designed to work on any subnet, regardless of what's in-between.  It would be pretty pointless if there was a compatibility list of devices that it would and wouldn't work through.  Vendors just wouldn't be able to sell kit if that was the case.

I'm completely sure that if you only separate the two machines with a standard router you'll get it working instantly.  In fact, I'm doing it at home right now.

My wireless laptop is on a 192.168.1.0/24 range, while my media server is on the 192.168.0.0/24 range.  A Cisco 1841 separates the two subnets.  I can go to \\192.168.0.100 (my media server's IP address) and see all of the shares on it.

...just because you can see the traffic leave the firewall doesn't mean it's getting to the PC.  There could be a hundred reasons why traffic might not get to the PC.  Until it gets to the PC and you see it at the PC (denied or otherwise), consider it anything else but the PC's fault.

I'd get wireshark going on each PC if I were you.  That will tell you if the PC is seeing anything coming from the PC on the other subnet.

OK.  I'm not dismissing your broadcast forwarding theory, I just haven't had the time to do the reading to test it.   As I said, I'd also be happy to try two different subnets with a different router, but I don't have one.

Additionally, I made an error in that it was not TCPDUMP but FW Monitor that we used that showed the traffic heading out of the port to the laptop.  I think that it is absolutely clear that the traffic is able to hop successfully from one subnet to the other inside the firewall and I can't imagine anything after that point in the firewall that would cause this behavior.  I agree that a Wireshark read on the laptop side would be conclusive and I will also try and do that, although again it will take me some time.

With all of that being said though, no one has tried to find something wrong in Windows and I swear that this configuration was working with this firewall prior to basically introducing a new laptop.  It does not seem unreasonable that some sort of configuration in Windows could prevent a connection from a computer on a different subnet and we seemed to really be committed to finding a problem with the firewall.

I will keep at it.

With all of that being said though, no one has tried to find something wrong in Windows and I swear that this configuration was working with this firewall prior to basically introducing a new laptop.  It does not seem unreasonable that some sort of configuration in Windows could prevent a connection from a computer on a different subnet and we seemed to really be committed to finding a problem with the firewall.

Well, that's because the only thing that would stop a Windows machine from working in this scenario is what's in-between.  You've already said that the Windows firewall is disabled, and we've proven that file-sharing works on the same subnet, so there is nothing else that could be the issue on the Windows PC other than the default gateway setting, which we know is correct because we can now ping each PC on each subnet.

So, there really is no need to pick at the Windows configuration - it's correct as far as we can determine.

Just for the record, Windows Firewall has not been disabled on either machine.  The only modification I've made there is the enabling of the ICMP Echo Request.

So get it disabled, like we asked a long time ago in post ID: 39760495.  If it works when you disable the Windows firewall you know what the issue is.

I tried it at the time and also disabled the IPS.  They made no difference, so I turned them both back on.  I've disabled it again and it again made no difference.

So as I said then, there is nothing on the Windows machines which would cause this behaviour, so the most likely culprit is the Checkpoint firewall.

You can prove this further by putting the two machines on the same VLAN and trying it with the Windows firewall turned on.  Allow NetBIOS through the firewall (Windows File Sharing) and see if it works.  If it does you know it's not Windows.

Hi Craig,

I appreciate all your time and attention to this and wanted to let you know that I'm still working on it, but have become overcome by events on other issues.  I'll be back on it next week, but I'm not ignoring it,

Peter

It's no problem, Peter.  We'll still be here when you're ready to try again :-)

Hi Craig,

After much hard work, I've worked the whole thing out.  Before I explain that, let me apologize for this having been more difficult than it should have been in 2 ways:  First, when something didn't work, I reset it so as to keep the number of variables to a minimum.  In this case, it worked against us as there were multiple things wrong and any one of them would have stopped things from working.  Second, I am unable to explain how this configuration was working prior to my scratching the laptop.  I can only conclude that there was some persistent information allowing it to function which went away with the reinstall as well as a few variables being reset.  That having been said, here's what needed to happen:

1) ICMP Echo Requests were disabled by default in Windows Firewall and had to be enabled.
2) A NAT rule needed to be added to the Firewall to prevent NATting (NAT to original source and destination)
3) Explicitly enable NetBIOS over TCP - also not the default.
4) Disable Windows Firewall (or more accurately allow certain things through, but I'm still working on the details).  However, stopping the Windows Firewall service will also cause it to not work as it appears to be required for File Sharing to work properly, so it must be disabled but running.
5) Populate the LMHOSTS file with the names and address of both PCs

At this point, it was possible to browse by IP Address and map a network drive so that I could browse between the machines.  However, the machines could not see each other in Windows explorer.  The final bit was to find away to forward/relay the NetBIOS name across the subnets.  Apparently, this name does not make it out of the broadcast domain.

6) Explicitly allow IP Broadcast Forwarding for ports 137, 138 and 445 on the firewall and everything magically appeared.  In Checkpoint, this was under IP Broadcast Helper and needed to be specified for each subnet.

Thanks again for helping with this very complicated problem.  It was all of your work that allowed me to work it out.

Good to hear but I thought this worked before and nothing had changed from the previous configuration except rebuilding 1 PC ?

I am unable to explain it.  There were only two issues with the firewall - most were in Windows.  I can imagine a scenario where the NetBIOS name might have cached somewhere, but not sure how it would have gotten around the NATting rule.  However, they were in fact talking.