<div>
Can they both ping each other?
</div>


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


<div>
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.
</div>


<div>
Sure. &nbsp;Is there a better way to do that than a Screen Print? &nbsp;It will appear pretty small.
</div>


<div>
Hi,<br />
<br />
Windows 7 is using on your lappy, but which OS you are using for your desktop.
</div>


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


<div>
hi<br />
first check if the 2 computer are in the same segment.<br />
like if the address is 192.168.10.x<br />
the subnet mask should be: 255.255.255.0.<br />
<br />
second, see if the computers are in the same workgroup.<br />
you can right click on Computer --&gt; properties.<br />
<br />
if that don't show any sign of hope.... <br />
in the control panel try to disable the firewall and in network see if the discovery option turned on.
</div>


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


<div>
Click the 'start' orb, type in <b>sysdm.cpl</b> and hit <b>Enter</b>.<br />
Click the <b>Change...</b> button to get to the screen where you can set the workgroup to match the other computer's. <br />
<br />
Ensure the LMHOSTS file in %windir%\system32\drivers\<wbr />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.<br />
<br />
If they're both running Win7 or Win8, join them both to the same homegroup.
</div>


<div>
Can you provide an <b>IPCONFIG /ALL</b> from the laptop?<br />
<br />
If you see nothing in the firewall log I doubt you're using the firewall as the gateway.
</div>


<div>
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).
</div>


<div>
Hi nashim khan,<br />
<br />
Sorry - I've just gotten home to get back to this. &nbsp;Both machines are running Windows 7,<br />
<br />
Peter
</div>


<div>
I've checked and both machines are in the same work group. &nbsp;<br />
<br />
I'm not sure what was meant by segment. &nbsp;The IP addresses are<br />
<br />
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. &nbsp;They are on different subnets, but they were before too. &nbsp;In fact, as I had a virus loose, I specifically &nbsp;had to add a rule to keep the two machines from trying to communicate with each other and it blocked packets all the time.<br />
<br />
The LMHOSTS file in that directory is a sample.<br />
<br />
Sorry to have been remiss on replying. &nbsp;I just got home,<br />
<br />
Peter
</div>


<div>
Hi,<br />
<br />
You said the IP's 192.168.3.254 for the laptop and 192.168.4.254 desktop.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Thanks
</div>


<div>
I cannot change the IP addresses. &nbsp;The subnets the machines are on are defined by the firewall and the firewall ports to which they connect. &nbsp;The actual route between the machines looks like this<br />
<br />
192.168.3.254 to 192.168.3.1 to 192.168.4.1 to 192.168.4.254<br />
<br />
Plus, I'm using DHCP on the Firewall for each subnet.
</div>


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


<div>
<blockquote>
&gt; <i>I cannot change the IP addresses.</i>
</blockquote>
Do you not have control over the network in question?
</div>


<div>
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.
</div>


<div>
<blockquote>
If you ping by IP address, that rules out netbios port blocks.
</blockquote>
Not really... ICMP isn't NetBIOS traffic, so it could be blocked even if ICMP isn't.<br />
<br />
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.<br />
<br />
If ping is unsuccessful it could mean anything:<br />
<br />
1] The wrong IP based on a firewall rule which specifically allowed an IP to pass<br />
2] The wrong gateway address<br />
3] The wrong subnet mask<br />
4] Failed DNS lookup (must be DNS as on different subnet and no WINS)<br />
5] Blocked ICMP at the Checkpoint firewall<br />
6] Firewall on the local PC blocking outbound ICMP<br />
<br />
Let's check the basics first...<br />
<br />
@Peter023 - please, provide an <b>IPCONFIG /ALL</b> output from the two PCs so we can see what configuration they both have.
</div>


<div>
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. <br />
<br />
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.
</div>


<div>
@chief - no one is having an argument. &nbsp;No one has said that pinging is a bad idea. &nbsp;All I said was that just because ping returns success doesn't necessarily mean that NetBIOS is also guaranteed to be successful.<br />
<br />
But, pinging by IP doesn't necessarily rule out name resolution. &nbsp;It just proves that a ping is successful, or not. &nbsp;If the ping is unsuccessful when pinging by IP alone, name resolution doesn't even come into it unless a reverse lookup is requested. &nbsp;Therefore you haven't proved anything related to name resolution.<br />
<br />
This is the output from a ping on my laptop. &nbsp;The first ping is by IP, with no name resolution, and the second is using rDNS via the -a switch. &nbsp;The point I'm making here is that a standard ping by IP involves no name lookups at all.
<pre><code class="code-10 nolinks" id="code-20-39754403-1"><span>C:\Users\craigbeck&gt;ping 192.168.100.5</span>
<span></span>
<span>Pinging 192.168.100.5 with 32 bytes of data:</span>
<span>Reply from 192.168.100.5: bytes=32 time=23ms TTL=128</span>
<span>Reply from 192.168.100.5: bytes=32 time=9ms TTL=128</span>
<span></span>
<span>Ping statistics for 192.168.100.5:</span>
<span>    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),</span>
<span>Approximate round trip times in milli-seconds:</span>
<span>    Minimum = 9ms, Maximum = 23ms, Average = 16ms</span>
<span>Control-C</span>
<span>^C</span>
<span>C:\Users\craigbeck&gt;ping -a 192.168.100.5</span>
<span></span>
<span>Pinging 2K8-DC [192.168.100.5] with 32 bytes of data:</span>
<span>Reply from 192.168.100.5: bytes=32 time=3ms TTL=128</span>
<span>Reply from 192.168.100.5: bytes=32 time=4ms TTL=128</span>
</code></pre>
<br />

<blockquote>
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. 
</blockquote>
Correct.<br />
<br />

<blockquote>
When the author wiped the machine, he also wiped out CACHED records to include the NetBIOS cached entries.
</blockquote>
This is only true until the PC restarts, then all cached entries are flushed. &nbsp;This is not the same as adding static entries to the LMHOSTS file, and preloading them using the #PRE keyword.<br />
<br />

<blockquote>
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.
</blockquote>
No it doesn't; it rules out ICMP being blocked at the firewall.<br />
<br />
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. &nbsp;I do this day-in, day-out and it's the basics which are the cause 95% of the time.<br />
<br />
Sure, it may be NetBIOS which isn't working, but it also might just be that the gateway is set wrong. &nbsp;It's best to be sure though and go through all of the steps in a methodical manner.
</div>


<div>
&gt;&gt;&quot;All I am saying is let's go back to basics first before we start pointing the finger....&quot;<br />
<br />
I believe that is what CheifIT is saying. &nbsp;Start with a basic Ping by IP.<br />
Failure or success determines the next steps; firewalls, routing &amp;&nbsp;default gateways, and protocols.
</div>


<div>
<blockquote>
Failure or success determines the next steps; firewalls, routing &amp;&nbsp;default gateways, and protocols.
</blockquote>
But it doesn't.<br />
<br />
If the basic IP details aren't configured correctly then the ping could fail for one of a number of reasons. &nbsp;It might be the firewall. &nbsp;It might be the gateway configured incorrectly...<br />
<br />
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!<br />
<br />
What's the most fundamental part of client connectivity across an IP network apart from the physical media? &nbsp;It's IP configuration. &nbsp;Therefore, check what you're <i><u>supposed</u></i> to have first, then expand the search to other areas.<br />
<br />
The OP clearly says that this only failed after a wipe of the laptop. &nbsp;That should tell you that it's something local to the laptop which is causing this.
</div>


<div>
&gt;&gt;&quot;If the basic IP details aren't configured correctly then the ping could fail for one of a number of reasons&quot;<br />
Exactly, it fails, so you take the next steps. &nbsp;However, if it succeeds you know the IP configuration is correct, routing, VLAN and default gateway are OK. &nbsp;Four things you then do not have to review. &nbsp;<br />
<br />
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.<br />
<br />
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.
</div>


<div>
@ Peter023..<br />
&nbsp;<br />
1) Can you ping by IP? <br />
1a) If yes, it is a Name resolution problem.<br />
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? <br />
--------------------------<wbr />---------<br />
Once you can ping by IP:<br />
2) Can you ping by HOSTNAME. <br />
-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.<br />
<br />
If you can ping by IP but not HOSTNAME, it means you have a NAME resolution problem. <br />
<br />
THEN this answer posted earlier is absolutely correct: <br />
--Darr247 Posted on 2014-01-02 at 05:54:57ID: 39751478<br />
--------------------------<wbr />--------<br />
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?
</div>


<div>
Ok, so ChiefIT you're absolutely incorrect here...
<blockquote>
They are held to the broadcast domain and will not go to different subnets.
</blockquote>
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. &nbsp;So, the broadcast MAY go to different subnets/VLANs.<br />

<blockquote>
1) Can you ping by IP? <br />
1a) If yes, it is a Name resolution problem.
</blockquote>
It MAY be a name resolution problem is more accurate. &nbsp;As I said, there are other factors which could affect this even if name resolution isn't working now, such as IP configuration.
<blockquote>
2) Can you ping by HOSTNAME. <br />
-I doubt it, because your computers are on different subnets.
</blockquote>
But it worked before across subnets so how is your logic correct here? &nbsp;Could it be that it is a name resolution problem because the firewall is blocking NetBIOS traffic? &nbsp;Does that sound fair?<br />
<br />
I'm not trying to poke holes at anyone, but we're supposed to be providing expert help here. &nbsp;If something isn't correct, let's not say it. &nbsp;I don't know why you're so against checking the basics? &nbsp;It's the first rule of troubleshooting.<br />
<br />
Let's see...<br />
<br />
@Peter023 - can you see the remote PC if you enter <b>\\192.168.4.254</b> in the address bar in Windows Explorer? &nbsp;THAT will tell you if it's more likely to be a name resolution problem. &nbsp;If you can see the remote PC using the IP, it's a name resolution issue. &nbsp;If you can't it could be anything.<br />
<br />
We need to see the IPCONFIG output, and a list of firewall rules if you can't see the remote PC.
</div>


<div>
&quot;how is your logic correct here?&quot;--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.<br />
--------------------------<wbr /><br />
If broadcast forwarding is enabled traffic on port 137 which is broadcast across the VLAN can be forwarded to other subnets, <br />
<br />
(ONLY IF IT IS CONFIGURED. WHAT MAKES YOU BELIEVE IT WAS EVER CONFIGURED).<br />
--------------------------<wbr />-<br />
can you see the remote PC if you enter \\192.168.4.254 in the address bar in Windows Explorer? <br />
<br />
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 &quot;providing expert help here&quot;.
</div>


<div>
Hi Guys,<br />
<br />
Pinging by IP was one of the first things we tried. &nbsp;See first posts. &nbsp;They cannot ping each other.<br />
<br />
I do have control over the network, however I am unwilling to rewire the subnets to fix this problem. &nbsp;It was working fine with this setup prior to reinstallation of the OS.<br />
<br />
I'm attaching the IPCONFIG/ALL for both machines.<br />
<br />
Thank you all for your attention and assistance with this,<br />
<br />
Peter<br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w01/826382/Desktop-IPCONFIG.txt" target="_blank" class="file-inline" title="Desktop IPCONFIG/ALL (4 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>Desktop-IPCONFIG.txt</a><br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w01/826383/Laptop-IPCONFIG.txt" target="_blank" class="file-inline" title="Laptop IPCONFIG/ALL (3 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>Laptop-IPCONFIG.txt</a>
</div>


Laptop-IPCONFIG.txt

Desktop-IPCONFIG.txt

<div>
I cannot see either machine by trying to browse to their IP addresses.<br />
<br />
I'm sorry, but I did not understand how to edit Windows Firewall. &nbsp;I took a quick look at the options, but did not see anything that would enable or disable ICMP. &nbsp;I was surprised to learn that ping was blocked by default.<br />
<br />
I am attaching a screen shot of the firewall rules.<br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w01/826384/Firewall-Rules.png" target="_blank" class="file-inline" title="screen shot of the firewall rules (132 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>Firewall-Rules.png</a>
</div>


Firewall-Rules.png

<div>
This is starting to look like some sort of quiz or test.<br />
<br />
In the initial question you fail to mention they are on different subnets, and a Checkpoint firewall. &nbsp;Now you reveal multiple physical and virtual NICs on numerous subnets, with multiple default gateways on the same device, which is not supported.<br />
<br />
We really need to have a better understanding of the entire network. &nbsp;Also when you say a CheckPoint firewall are you reefing to a proper Checkpoint hardware or a Checkpoint software addon such as with ZoneAlarm.
</div>


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


<div>
To confirm it was the laptop that was rebuilt, and it's computer name is &quot;Bedroom&quot;?<br />
Also the only change was it being rebuilt?<br />
Presumably it must be a configuration change on it.<br />
<br />
Firstly it has 2 NIC's each with it's own default gateway. &nbsp;Windows will not support multiple default gateways.<br />
<br />
What are 192.168.3.1 (wired) and 192.168.2.1 (wireless) gateways? &nbsp;<br />
I assume one is the Checkpoint, and the other?<br />
<br />
In order for the laptop to ping the desktop on the other subnet it needs to know the route.<br />
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:<br />
route -p add 192.168.4.0 mask 255.255.255.0 192.168.3.1<br />
<br />
The desktop also needs the return route, but presumably that is still OK.
</div>


<div>
Hi RobWill,<br />
<br />
Yes, you are correct. &nbsp;<br />
<br />
I believe you have found the issue, but it will take me a bit of time to verify.<br />
<br />
Both adapters are going to the Checkpoint, the wireless one via a wireless router on another subnet on the firewall. &nbsp;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. &nbsp;I've disabled it now and will give the network some discovery time. &nbsp;No immediate change occurred and I can't reboot just at the moment.
</div>


<div>
Changes to the routing table, such as disabling an adapter may require a reboot to clean up. &nbsp;<br />
I would again test by pinging the IP, at least first.<br />
<br />
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. &nbsp;Many firewall rules are automatic, such as file and print sharing, as soon as you enable the feature. &nbsp;However they often only allow access from the local subnet. &nbsp;You may have to add the remote subnet or all, but start with pin, by IP, from laptop to desktop.
</div>


<div>
I had hoped that would have done it, but I've rebooted both machines now and cannot ping either. &nbsp;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. &nbsp;Any ideas?<br />
<br />
Peter
</div>


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


<div>
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.<br />
<br />
How to fix:<br />
<a href="http://technet.microsoft.com/en-us/library/cc749323%28v=ws.10%29.aspx" rel="ugc">http://technet.microsoft.com/en-us/library/cc749323%28v=ws.10%29.aspx</a>
</div>


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


<div>
That looks like a really good article. &nbsp;Thanks. &nbsp;I'll give it a go and come back to you, but it will take a day or so.
</div>


<div>
I agree windows firewall will be enabled on rebuilt machine ( laptop) which is why I suggested pinging desktop from laptop.<br />
<br />
Could you provide results from route print on laptop.<br />
<br />
3am here, will jump back in tomorrow.
</div>


<div>
Rob: I agree with everything step you are taking.<br />
<br />
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). &nbsp;<br />
<br />
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.<br />
<br />
You are concise as usual, Rob.
</div>


<div>
So, it wasn't a name resolution issue then??<br />
<br />
Just to be clear...<br />
<br />

<blockquote>
by: Peter023Posted on 2014-01-04 at 02:55:32ID: 39755492<br />
<br />
Hi Guys,<br />
<br />
Pinging by IP was one of the first things we tried. &nbsp;See first posts. &nbsp;They cannot ping each other.
</blockquote>
Also, please refer to &quot;<a href="http://filedb.experts-exchange.com/incoming/2014/01_w01/826383/Laptop-IPCONFIG.txt" rel="ugc">http://filedb.experts-exchange.com/incoming/2014/01_w01/826383/Laptop-IPCONFIG.txt</a>&quot;&nbsp;in the same post, which provides all of the information which is required to assist in solving this problem.<br />
<br />
Now,
<blockquote>
&quot;how is your logic correct here?&quot;--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.
</blockquote>
I know exactly what a CACHE record is. &nbsp;Unfortunately it appears you don't. &nbsp;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. &nbsp;Therefore it isn't actually CACHED - but SAVED.<br />

<blockquote>
If broadcast forwarding is enabled traffic on port 137 which is broadcast across the VLAN can be forwarded to other subnets, <br />
<br />
(ONLY IF IT IS CONFIGURED. WHAT MAKES YOU BELIEVE IT WAS EVER CONFIGURED).
</blockquote>
I didn't say it was. &nbsp;I said IF. &nbsp;I was considering all possible solutions as we didn't know for sure how it was configured.<br />

<blockquote>
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,
</blockquote>
Unfortunately, a failed ping (as the author already said was the case at this point &nbsp;incidentally) would not tell you anything either. &nbsp;So, your statement is exactly the same as mine and would only help IF the result was successful. &nbsp;Therefore there is no benefit to using ping against UNC path.<br />

<blockquote>
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.
</blockquote>
Assumption again - and also complete rubbish.<br />

<blockquote>
Changes to the routing table, such as disabling an adapter may require a reboot to clean up. &nbsp;<br />
I would again test by pinging the IP, at least first.
</blockquote>
No, not in Windows 7. &nbsp;A simple disconnect of the NIC, or a disable/enable will do.<br />

<blockquote>
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.
</blockquote>
EXACTLY my point. &nbsp;Thanks for confirming!<br />

<blockquote>
Firstly it has 2 NIC's each with it's own default gateway. &nbsp;Windows will not support multiple default gateways.
</blockquote>
Yes it does, by using dead-gateway detection for example. &nbsp;It is not recommended but it is definitely supported. &nbsp;Default gateways which are configured on separate NICs are easily manipulated using interface metrics.<br />
<br />
<br />
Reading the provided detail and obtaining as much extra information as possible is the number one priority when trying to troubleshoot issues. &nbsp;If you only have half the story you'll end up saying &quot;It's definitely name resolution&quot;, when in fact it is the wrong gateway (as I said I'm sure).
</div>


<div>
Oh just saw this too...
<blockquote>
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). 
</blockquote>
Need I say more??
</div>


<div>
@ craigbeck I am not sure all of that is helping Peter. &nbsp;It sounds more like a defense because I/we have offended you. &nbsp;I apologize if we have done so.<br />
--Rob<br />
<br />
@ 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.<br />
<br />
You can run from a command line:<br />
route print &nbsp;&gt;C:\Temp\RoutPrintResult.t<wbr />xt<br />
Then copy the text file results. &nbsp;(Assumes C:\Temp exists)
</div>


<div>
@RobWill - I'm not particularly defending myself as I don't really need to. &nbsp;And no, you haven't offended me at all.<br />
<br />
To cut a long story short, some of the information provided to Peter is incorrect - that's what's not helping.<br />
<br />
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).<br />
<br />
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. &nbsp;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. &nbsp;You get what I mean...?<br />
<br />
I wasn't ever suggesting that a ping was pointless, or that it wasn't the first port of call for a quick check. &nbsp;I was saying (a) that it wouldn't prove conclusive, and (b) that it had already been done. &nbsp;If you look back over this thread you'll see that nothing I said ever contradicts this.<br />
<br />
Anyhow, if I have offended anyone here I too apologise.
</div>


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


<div>
Hi RobWill,<br />
<br />
Was that a DOS command? &nbsp;It wasn't recognized. &nbsp;Did you want a Tracert?<br />
<br />
This is more of a testing environment. &nbsp;You would never put a 2200 into an environment with just 2 PCs. &nbsp;I agree it's way more complicated than it needs to be, but it should theoretically work.<br />
<br />
Peter
</div>


<div>
Yes a DOS command.<br />
You could also just run &nbsp; &nbsp;route print &nbsp; &nbsp; and copy and paste the results.<br />
<br />
No problem as I said if you have reasons to have the multiple subnets, such as a test environment. &nbsp;Just wondered if it was necessary.
</div>


<div>
No problem. &nbsp;I appreciate the advice. &nbsp;Here's the data:<br />
<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
Interface List<br />
&nbsp;20...30 85 a9 9a 26 7e ......Realtek PCIe GBE Family Controller #2<br />
&nbsp;18...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1<br />
&nbsp;19...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8<br />
&nbsp; 1.........................<wbr />..Software<wbr /> Loopback Interface 1<br />
&nbsp;12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter<br />
&nbsp;13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface<br />
&nbsp;15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2<br />
&nbsp;16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
<br />
IPv4 Route Table<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
Active Routes:<br />
Network Destination &nbsp; &nbsp; &nbsp; &nbsp;Netmask &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Gateway &nbsp; &nbsp; &nbsp; Interface &nbsp;Metric<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0.0.0.0 &nbsp; &nbsp; &nbsp;192.168.4.1 &nbsp; &nbsp;192.168.4.254 &nbsp; &nbsp; 20<br />
&nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp;255.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp; &nbsp;306<br />
&nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp; &nbsp;306<br />
&nbsp; 127.255.255.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp; &nbsp;306<br />
&nbsp; &nbsp; &nbsp; 192.168.4.0 &nbsp; &nbsp;255.255.255.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.4.254 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; 192.168.4.254 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.4.254 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; 192.168.4.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.4.254 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; &nbsp;192.168.13.0 &nbsp; &nbsp;255.255.255.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp;192.168.13.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; 192.168.116.0 &nbsp; &nbsp;255.255.255.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.116.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; 192.168.116.1 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.116.1 &nbsp; &nbsp;276<br />
&nbsp; 192.168.116.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.116.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; &nbsp; &nbsp; 224.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp;240.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp; &nbsp;306<br />
&nbsp; &nbsp; &nbsp; &nbsp; 224.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp;240.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.4.254 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; &nbsp; &nbsp; 224.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp;240.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp; &nbsp;276<br />
&nbsp; &nbsp; &nbsp; &nbsp; 224.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp;240.0.0.0 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.116.1 &nbsp; &nbsp;276<br />
&nbsp; 255.255.255.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp; &nbsp; 127.0.0.1 &nbsp; &nbsp;306<br />
&nbsp; 255.255.255.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.4.254 &nbsp; &nbsp;276<br />
&nbsp; 255.255.255.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; &nbsp;192.168.13.1 &nbsp; &nbsp;276<br />
&nbsp; 255.255.255.255 &nbsp;255.255.255.255 &nbsp; &nbsp; &nbsp; &nbsp; On-link &nbsp; &nbsp; 192.168.116.1 &nbsp; &nbsp;276<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
Persistent Routes:<br />
&nbsp; None<br />
<br />
IPv6 Route Table<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
Active Routes:<br />
&nbsp;If Metric Network Destination &nbsp; &nbsp; &nbsp;Gateway<br />
&nbsp; 1 &nbsp; &nbsp;306 ::1/128 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;On-link<br />
&nbsp;20 &nbsp; &nbsp;276 fe80::/64 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;On-link<br />
&nbsp;18 &nbsp; &nbsp;276 fe80::/64 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;On-link<br />
&nbsp;19 &nbsp; &nbsp;276 fe80::/64 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;On-link<br />
&nbsp;19 &nbsp; &nbsp;276 fe80::1017:e30b:e624:b3a7/<wbr />128<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp;18 &nbsp; &nbsp;276 fe80::192c:e05:10b9:6936/1<wbr />28<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp;20 &nbsp; &nbsp;276 fe80::f9ed:ec09:292e:84d4/<wbr />128<br />
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp; 1 &nbsp; &nbsp;306 ff00::/8 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp;20 &nbsp; &nbsp;276 ff00::/8 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp;18 &nbsp; &nbsp;276 ff00::/8 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
&nbsp;19 &nbsp; &nbsp;276 ff00::/8 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On-link<br />
==========================<wbr />==========<wbr />==========<wbr />==========<wbr />==========<wbr />=========<br />
Persistent Routes:<br />
&nbsp; None
</div>


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


<div>
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. &nbsp;Thus it will use the default gateway, the router 192.168.4.1<br />
<br />
Presumably then the Laptop will be configured in the same way, so both are dependent on defined routes in the Checkpoint firewall. &nbsp;I am not familiar with Checkpoints so I am of no help there.
</div>


<div>
Isn't it significant that the two subnets can ping each other? &nbsp;I can ping 192.168.3.1 from 192.168.4.254.
</div>


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


<div>
&gt;&gt;&quot;Isn't it significant that the two subnets can ping each other? &nbsp;I can ping 192.168.3.1 from 192.168.4.254. &quot;<br />
That would depend on the Checkpoint rules as to whether they are based on subnets or IP's. &nbsp; Also 192.168.3.1 &nbsp;is not an external device, it is the router itself.<br />
<br />
It may be difficult for us to diagnose routing, or IPS issues as CheifIT pointed out, with the router.
</div>


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


<div>
Sure. &nbsp;Here you go. &nbsp;Please note that Rule 4 is disabled.<br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w02/826590/Firewall-Rules.png" target="_blank" class="file-inline" title="FIrewall Rules (132 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>Firewall-Rules.png</a>
</div>


<div>
Sorry - my bad. &nbsp;Rule 3 is disabled.
</div>


<div>
Ok thanks. &nbsp;Can you tell us what Rule2 is for?
</div>


<div>
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. &nbsp;I've been meaning to take it out.
</div>


<div>
I'm wondering why there are no hits on any of those rules. &nbsp;I would expect to see at least something on rule 4.<br />
<br />
Can you confirm that both the laptop and the desktop get to the internet via the Checkpoint?
</div>


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


<div>
You know, I was wondering that myself, but I hadn't had a chance to explore it. &nbsp;I've attached a screen shot from SmartView Tracker which is definitely showing current, rule-based activity.<br />
<br />
Yes, they both get to the internet via the firewall. &nbsp;There are four devices connected to the firewall, each on its own subnet. &nbsp;In addition to the 2 PCs there is a wireless router which is connected to nothing and there is an ADSL2+ modem.<br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w02/826664/SmartView-Tracker.png" target="_blank" class="file-inline" title="SmartView Tracker (228 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>SmartView-Tracker.png</a>
</div>


SmartView-Tracker.png

<div>
@RobWill - the rule 4 configuration allows network objects in the source field to access anywhere as designated in the destination field. &nbsp;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.
</div>


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


<div>
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?
</div>


<div>
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. <br />
<br />
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. <br />
<br />
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. &nbsp;<br />
<br />
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). &nbsp;<br />
<br />
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.<br />
<br />
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.
</div>


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


<div>
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?<br />
<br />
IPS is usually IP-based due to the fact that intrusion prevention is required from hosts on remote networks. &nbsp;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.<br />
<br />
I would either disable IPS completely to test, as ChiefIT suggests, or set it to detect-only.<br />
<br />
Also, turn off the Windows firewall to see what happens.<br />
<br />
For info the R75.40 manual is here...<br />
<br />
<a href="http://dl3.checkpoint.com/paid/2a/CP_R75.40VS_IPS_AdminGuide.pdf?HashKey=1389049370_f38aad7dc8e1cc772b14dcd43cb0ced6&xtn=.pdf" rel="ugc">http://dl3.checkpoint.com/paid/2a/CP_R75.40VS_IPS_AdminGuide.pdf?HashKey=1389049370_f38aad7dc8e1cc772b14dcd43cb0ced6&xtn=.pdf</a>
</div>


<div>
&quot;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?&quot;<br />
<br />
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 &quot;format/reinstall&quot;?<br />
<br />
-------<br />
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. <br />
<br />
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. <br />
<br />
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.
</div>


<div>
Pinging is now working between both machines. &nbsp;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. &nbsp;However, I am still unable to see either machine from the other in Windows Explorer.
</div>


<div>
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. &nbsp;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.<br />
<a href="https://filedb.experts-exchange.com/incoming/2014/01_w02/826805/SmartView-Tracker.png" target="_blank" class="file-inline" title="SmartView Tracker Screen Shot (211 KB)"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512"><path d="M67.508 468.467c-58.005-58.013-58.016-151.92 0-209.943l225.011-225.04c44.643-44.645 117.279-44.645 161.92 0 44.743 44.749 44.753 117.186 0 161.944l-189.465 189.49c-31.41 31.413-82.518 31.412-113.926.001-31.479-31.482-31.49-82.453 0-113.944L311.51 110.491c4.687-4.687 12.286-4.687 16.972 0l16.967 16.971c4.685 4.686 4.685 12.283 0 16.969L184.983 304.917c-12.724 12.724-12.73 33.328 0 46.058 12.696 12.697 33.356 12.699 46.054-.001l189.465-189.489c25.987-25.989 25.994-68.06.001-94.056-25.931-25.934-68.119-25.932-94.049 0l-225.01 225.039c-39.249 39.252-39.258 102.795-.001 142.057 39.285 39.29 102.885 39.287 142.162-.028A739446.174 739446.174 0 0 1 439.497 238.49c4.686-4.687 12.282-4.684 16.969.004l16.967 16.971c4.685 4.686 4.689 12.279.004 16.965a755654.128 755654.128 0 0 0-195.881 195.996c-58.034 58.092-152.004 58.093-210.048.041z"/></svg>SmartView-Tracker.png</a>
</div>


<div>
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. <br />
<br />
Examples:<br />
<br />
1) If you ping FROM the computer with Windows firewall ON, it should get a response back because that computer initiated the traffic.<br />
<br />
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.<br />
<br />
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.
</div>


<div>
Hi ChiefIT,<br />
<br />
I'm not sure I understand: &nbsp;I understand your explanation of the Windows Firewall blocking, but Windows Firewall was turned off completely prior to my scratching the laptop. &nbsp;That would have allowed the desktop to ping the laptop successfully, which I remember doing often. &nbsp;I'm not sure that I explicitly pinged from the laptop to the desktop. &nbsp;It's possible that I never did.<br />
<br />
In either case though, IPS is now turned off as is AV and the other blades. &nbsp;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.<br />
<br />
Now that they can ping each other, does that open up any other areas for exploration?<br />
<br />
Thanks<br />
<br />
Peter
</div>


<div>
Have a look here, Peter...<br />
<br />
<a href="http://homeworksblog.wordpress.com/2010/06/12/unable-to-use-unc-share-win7/" rel="ugc">http://homeworksblog.wordpress.com/2010/06/12/unable-to-use-unc-share-win7/</a>
</div>


<div>
&quot;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.&quot;<br />
<br />
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.<br />
<br />
You will probably be able to ping by fully qualified domain name.. <br />
Ping laptop.mydomain.com<br />
<br />
You will probably be able to ping by IP address.<br />
Ping 192.168.3.5<br />
<br />
But, you can't ping by hostname.<br />
Ping laptop<br />
<br />
Nor will you see them in the computer browser. <br />
<br />
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).<br />
<br />
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.<br />
<br />
There are many ways to approach this, but first we have to ask a couple questions:<br />
<br />
1) Can other computers on your Desktop subnet see each other?<br />
2) Can computers on your Desktop subnet see others on other subnets?<br />
3) Can computers on the laptop subnet see each other?<br />
4) Can computers on the laptop subnet see other subnets?
</div>


<div>
Have you tried opening \\192.168.4.254 since you disabled the firewall, etc?<br />
<br />
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. &nbsp;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.
</div>


<div>
There are no other computers running in this environment. &nbsp;Just one computer on each of two subnets, so I can't answer the visibility question.<br />
<br />
I was unable to browse to \\192.168.4.254 from a couple of different browsers - Page Not Found<br />
<br />
I checked for hidden network cards and adapters in the Device Manager and couldn't find any.
</div>


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


<div>
There is no hosted web page on that machine, hence &quot;page not found error&quot;. You can try by mapping a network drive. <br />
<br />
Try this instead: \\192.168.4.254\c$<br />
<br />
That tells the browser you are trying to access the default admin share of the computer. It should ask for credentials for access.
</div>


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


<div>
Just try it without the \c$ bit on the end. Windows may not be administratively sharing the C drive by default... <br />
<br />
So just \\192.168.3.254 in the search box in the Start menu.
</div>


<div>
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.<br />
<br />
Also, Craig is right these systems may not be sharing out. On the NIC adapter settings is &quot;Client for Microsoft Networks&quot; and &quot;File and Print Sharing&quot; services installed for all your machines?
</div>


<div>
The system is overly complicated for a production environment. &nbsp;It's more like a lab. &nbsp;There are 5 pieces of hardware: &nbsp;modem, firewall and connected to different subnets on the firewall are a laptop, a desktop and a wireless router.<br />
<br />
I was going back to the lack of hits on the rules in firewall log. &nbsp;Is it possible that I might need to explicitly prevent NATing from one subnet to the other with a rule?
</div>


<div>
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.
</div>


<div>
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.
</div>


<div>
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. &nbsp;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.<br />
<br />
Your plan is good though. Eliminate routing and firewalls and try on the same broadcast domain.
</div>


<div>
I have put them both on the same subnet and they can see each other in Windows Explorer. &nbsp;I've put them back where they were and they cannot.
</div>


<div>
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.<br />
<br />
Can you see if the Checkpoint lets you forward broadcast traffic on those ports?
</div>


<div>
Sorry, I'm don't know how to check that. &nbsp;<br />
<br />
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. &nbsp;<br />
<br />
FYI, the pings are working as well.
</div>


<div>
Broadcast forwarding is a bit different to firewalling.<br />
<br />
Have a look at the Advanced Routing Guide (p37)...<br />
<br />
<a href="http://dl3.checkpoint.com/paid/be/CP_R75.40_Gaia_Advanced_Routing_AdminGuide.pdf?HashKey=1389617791_6065cf4501e74bb00574daa95102b520&xtn=.pdf" rel="ugc">http://dl3.checkpoint.com/paid/be/CP_R75.40_Gaia_Advanced_Routing_AdminGuide.pdf?HashKey=1389617791_6065cf4501e74bb00574daa95102b520&xtn=.pdf</a>
</div>


<div>
OK, after the subnet tetst, I opened up an SR with CheckPoint. &nbsp;They've looked at the issue for a few hours and (wait for it) have blamed Microsoft. &nbsp;The hit count being turned off was a reasonably easy fix and is now working. &nbsp;That was only a toggle that had to be flipped. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;The connection attempts from the desktop go unrequited, but are getting through.<br />
<br />
Checkpoint felt that this may have been some Windows settings preventing PCs on different subnets from talking to each other. &nbsp;For example, both PCs had the networks defined as &quot;Home&quot; 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. &nbsp;There is also the possibility of some homegroup/domain in compatibilities. &nbsp;I'm pursing the SmartTracker issue with them, but they've discounted the Firewall in this issue.<br />
<br />
I will still try and get through the manual regarding broadcast forwarding, but I thought I'd report this development first.
</div>


<div>
By the way, just a few more notes. &nbsp;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.<br />
<br />
Also, I inserted the NAT rule to make sure that NATting was not done between subnets and it made not difference. &nbsp;I've removed the rule now.
</div>


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


<div>
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.<br />
<br />
The issue RobWill mentioned with not failing back properly was only an issue pre-SP1 in Windows XP.<br />
<br />
What 'exactly' do you have two NICs with different gateways configured for anyway?
</div>


<div>
I have a wireless and a wired adapter on the laptop. &nbsp;The wireless router is on 192.168.2.0 and the wired adapter is on 192.168.3.0. &nbsp;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. &nbsp;But obviously, the wired connection is faster, so I tend to leave them both enabled and connected. &nbsp;I don't actually need them both, but as I occasionally need to reach the router, I leave it enabled. &nbsp;If you feel it's a problem, I can leave it disabled until I need it.
</div>


<div>
Let's keep it simple for now :-)<br />
<br />
Think logically. &nbsp;The connection between the two machines works fine on the same VLAN, but not when a firewall is in the way. &nbsp;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).<br />
<br />
If broadcast forwarding for UDP/135,137-139 isn't working I'd say this is probably the issue. &nbsp;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...<br />
<br />
TCP/UDP 135<br />
TCP/UDP 137<br />
TCP/UDP 138<br />
TCP/UDP 139<br />
TCP 445
</div>


<div>
I'm not so sure. &nbsp;When the firewall was taken out of the loop, the two PCs were then on the same subnet. &nbsp;Then they could see each other. &nbsp;I do not have the equipment to test the PCs with a different router, other than the firewall, who can connect the subnets. &nbsp;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.
</div>


<div>
Well if you think about it, Windows file sharing is designed to work on any subnet, regardless of what's in-between. &nbsp;It would be pretty pointless if there was a compatibility list of devices that it would and wouldn't work through. &nbsp;Vendors just wouldn't be able to sell kit if that was the case.<br />
<br />
I'm completely sure that if you only separate the two machines with a standard router you'll get it working instantly. &nbsp;In fact, I'm doing it at home right now.<br />
<br />
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. &nbsp;A Cisco 1841 separates the two subnets. &nbsp;I can go to \\192.168.0.100 (my media server's IP address) and see all of the shares on it.
</div>


<div>
<div class="content wysiwyg-content">
I've recently reinstalled my laptop from scratch due to some virus issues. &nbsp;I've reinstalled Windows 7 and brought it up to date and my laptop cannot now see my desktop, nor can my desktop now see my laptop. &nbsp;I've got the LAN on both machines as Private and discovery is turned on. &nbsp;Any ideas?<br />
<br />
Thanks,<br />
<br />
Peter
</div>
</div>


I've recently reinstalled my laptop from scratch due to some virus issues.  I've reinstalled Windows 7 and brought it up to date and my laptop cannot now see my desktop, nor can my desktop now see my laptop.  I've got the LAN on both machines as Private and discovery is turned on.  Any ideas?

Thanks,

Peter

PCs on same LAN cannot see each other

The Windows operating systems have distinct methodologies for designing and implementing networks, and have specific systems to accomplish various networking processes, such as Exchange for email, Sharepoint for shared files and programs, and IIS for delivery of web pages. Microsoft also produces server technologies for networked database use, security and virtualization.