OFP 7.x Rules Wizard blocks network adapter.

[Chalky_WIS]

I have logged this as a ticket with Agnitum, but in case I'm missing something, I thought I'd see if anyone can spot a quick fix.

O\S: Windows Vista Ultimate 64 bit
Outpost Firewall Pro 7.5.2 (3939.602.1809)

Everything was OK last night. However today it seems that I have lost internet connection. I did not immediately consider OFP. Why would you when things were fine the night before? However, if I set OFP to "Allow Most" everything comes back and starts working.

I was on version OFP 7.1 initially.
I went through what has changed recently, but everything had been the same for 2 days. The main change to my setup this week has been the cable modem. Out went one cable modem and in came a VirginMedia Superhub. I have the superhub set-up to provide a reserved IP address to my Cisco WRT610N router against its MAC address and then set that same IP as a DMZ. Then the Cisco router handles the DHCP and allows any LAN / Wireless connections.
I have 2 work laptops without OFP installed that connect perfectly OK through this set-up. I also have 1 other home laptop running XP Pro (32bit) that has OFP 7.5.1 and is working fine over wireless to the router. An extra check. I turned off the wireless on the XP laptop with OFP 7.5.1 and plugged it into the router direct. Everything runs fine. No problems.
So the new cable modem setup seems like a red herring.

So it comes down to OFP 7.1. So I tried the upgrade to 7.5.2. This did not resolve the issue.
I booted into safe mode and ran clean.exe
Then once back into Windows I re-installed OFP 7.5.2. I set it to 'Simple Mode' and left it.
Again the issue returned.

The odd part is that my PC is getting an IP address off the router.
Also when the issue kicks in the network icon in the taskbar loses its globe, denoting I only have local access.

So my last test was to bypass my router and plug direct into the VirginMedia superhub. This is not ideal as then I cannot connect to my wireless printer, but it would hopefully prove if the router was an issue.

With the "Rules Wizard" on, again I could not get an IP address off the DHCP on the superhub. If I set OFP to "Allow Most" I could ipconfig /release and /renew. So same problem even if I bypass the router.

It therefore seems that something is blocking the network adapter on OFP.
If I look at my LAN Settings in OFP I have the following:
192.168.1.0 (255.255.255.0) - This is my Cisco router so I have set this Trusted even though my XP laptop does not and that works ok. It had NetBIOS already ticked already so I have left this ticked.
::/0 - I have no idea what this is, but nothing is set against it
169.254.0.0 (255.255.0.0) - This I believe is the IP address you get when DHCP fails.
192.168.0.0 (255.255.255.0) - The VirginMedia Superhub. Again I set this to Trusted. It had NetBIOS already ticked.

Also it's not DNS as I can ping www.google.com even with "Rules Wizard" set on.
But then this went as soon as I opened IE and then the ping failed.
Reset to 'Allow most'. renewed IP address. Set to 'Rules Wizard' and then ping www.google.com worked.
I have tried setting Firefox.exe or Iexplore.exe to "Allow All" in the application rules, but this does not help either.

Next test. I booted in safe mode and run clean.exe
I then updated the NIC driver. Marvell Yukon 88E8056 driver from v10.51.1.9 to 11.45.3.3.
I then re-installed 7.5.2
I tried same test. Load IE or Firefox and my network card drops to 'Local Only'. Switched back to 'Allow Most' and it's back.
So back to clean.exe and then I put the previous version I had saved of OFP on that is v7.1 (3415.520.1247)
However, the issue still exists. 'Allow most' loads the internet and 'Rules Wizard' blocks it and sets the network adapter to local.

So I'm assuming that it must be something setup related that I have missed, or some unusual 64bit thing with OFP? Somewhere something is blocking the network adapter when I put OFP into "Rules Wizard" mode.

I've now left it back with v7.1, although it's still not working as "Rules Wizard". I've compared the settings against my XP laptop and I cannot see any differences that I am missing. It's really puzzling.

[Chalky_WIS]

A quick update.
This morning I have set OFP to "Allow Most" to launch Firefox.
I then had a look at the Event Viewer in OFP (Firewall Log).
When I switch over to "Rules Wizard" and then try to open a new tab with www.google.co.uk I get these blocked rules appear:

07:17:09 N/A IN IGMP 192.168.1.1 * Block IGMP 0 32
07:17:09 N/A IN IGMP 192.168.1.1 * Block IGMP 0 28

Not sure if that helps?

[Chalky_WIS]

Still no progress here. Some additional information that may help.
I have a dual login to my O\S. One for me and one for my partner.
Therefore Vista does not auto-login from boot but waits at the login screen.
It seems that this is classed as "Background" mode and sets OFP into "Block Most". I've noticed recently that this gives me a 169 IP address once I login. So I have to set OFP to Allow Most and do a ipconfig /release and /renew once I have booted up.
For dual login devices, what is the recommended setting for "Background Mode" and is it this dual login that is causing the problem as OFP then thinks that it should remain in "Block Most" as default once I have logged in?
Should I be setting OFP to "Allow Most" in "Background Mode"?

[romil]

"I thought I'd see if anyone can spot a quick fix."

This is not a permanent fix (hopefully). I'll expand my reasons why I'd like you to try this rule if it works. I intended to spend this weekend working on another unsolvable problem, but it's a pain to setup, and solving your problem will give me a good reason to think that my effort in the other problem will work.

Click "settings", "Network Rules", "System-Wide Rules" button, "Low-Level Rules", "Add" button.

IP protocol type: UDP
Direction: Inbound
Remote Address: 0.0.0.0

This rule opens ports. If this alone doesn't work, click "0.0.0.0" and add the macro "local network". If I'm correct in what I think your problem is, the rule should work, but in case it doesn't, remove "Direction" (not likely that this will help).

If you would like to spend more time trying to solve your problem, I need some entries from your "Packet Log".

[romil]

While working on my local network rules last night, something happened that I've never seen before. I assume that I will be going off-topic if I discuss it in this thread, but I now have a reason to think that IGMP may be your problem, or an additional problem.
If you tried my first suggestion, you might have noticed the "IGMP" system rule. Change that rule to "allow". If that works, let me know if you would like help in tightening that rule.

[Chalky_WIS]

I tried your suggestions but it has not changed the issue. I even un-selected the "Block IGMP" in the Low Level Rules to completely allow IGMP.

[romil]

If I am understanding you correctly, you are not having any problems in "allow most" mode, or when Outpost is not installed, so I did not ask any questions about your setup. Addressing some setup issues might help, because of the way handles netbios. It's an old feature, too many ports to control, and I think it's time to get rid of that feature, and make system rules for netbios. Are there any cable users using Outpost?

Since "allow most" works, the question is - what is being allowed in that mode which is now blocked when switching to "Rules Wizard". What I've found is that in "allow most" mode, there are no "packet to closed ports" messages in the packet log. So, I need some entries from your "packet log" logs, but since my rule did not help, I have a feeling that Outpost's netbios is blocking more that can't be overruled with a system rule.

There must be some cable users using Outpost, so there is a solution. You switched from a cable modem to Superhub. Did your old cable modem have routing capabilities, or was it just a modem? You seem to be using the Superhub only for the purpose of connecting to your ISP. I, personally, would set the Superhub into a pass-though mode. You started to do this by disabling DHCP. But since you are a cable user, you may not be able to do this. Your present setup should work with one slight change. The cable from the Superhub should go to one of Cisco's lan port, not to "line-in". Hopefully, this cable change will solve your problem. I have no more suggestions without log entries to work with.

I connect my machine to a lan port in my router, but everyone in my home uses wireless. I have a solution, probably controversial, that allows me to access wireless devices for a wireless printer, file-sharing, etc.. So far, no man or machine has been able to break my security. If you start another thread (Computer Help), I tell you how I do it.

[Chalky_WIS]

I do have cable, but the desktop PC is the only device that I daily have to connect to the LAN ports of my Cisco router. All other devices use Wireless.

I did have the superhub set with DHCP on and a reserved IP address for my Cisco router, with the reserved IP set as a DMZ. Wireless is off on the superhub.
I have since found a "Modem only mode" option at the bottom of the advanced superhub settings and I have set this on, defaulting the superhub to just a cable modem. This is how the old cable modem worked.
I powered off the Cisco router and powered it back on.
Unfortunately the same issue occurs and I have had to set OFP to "Allow Most".
My work laptop (without OFP) can connect fine through the LAN port of the Cisco router.

So it seems that in either mode on the superhub I get the same issue. At least now the superhub is in 'pass-through' or 'modem only' mode.

I switched back to "Rules Wizard" just for a minute and checked the Packet.log.
It flooded with loads of "Packet to closed port".
I recognise some as UDP connections trying to get to the VirginMedia DNS servers. (194.168.4.100 & 194.168.8.100)
Some to the Cisco router on the local subnet xxx.xxx.xxx.1
Then some broadcast message inbound from the Cisco router was blocked too.
and a handlefull of the odd external addresses that I do not recognise.

I have a windows XP laptop with OFP 7.5.2 installed that works fine on wireless. I may plug that back into the LAN port on the router and go and double check the settings. But I have never had to play with OFP on the Windows XP laptop ever, it has always been a default setup, like how I installed it on Vista (64bit).

[romil]

"(194.168.4.100 & 194.168.8.100)"

That is weird. You should be seeing 192.168.0.x or 192.168.1.x. Maybe the Superhub is defective. Now that the Superhub is in pass-through mode, the cable should go to Cisco's "line-in" again. Try removing Cisco from the picture, and see if you still have Outpost problems when using only the Superhub. I'm not sure that the Superhub can be used in pass-though mode because the modem connecting to your ISP may need DHCP enabled.

[romil]

After doing some research, the Superhub can be used in the "bridge mode" with the latest firmware update. Upon further reflection of your situation, the 194.168.4.100 & 194.168.8.100 addresses may not be your problem. Since Outpost appears to be your problem, change netbios to 192.168.0.0 with a mask of 255.255.0.0, although Outpost should be detecting and adding the 192.168.4.0 or 192.168.8.0. I just noticed that your addresses started with 194. Is that a typo error?

[romil]

I see now that the addresses you posted are from Virgin Media. Can you copy & paste some of those entries. Right-click on the entry, select "Copy Log Text", then paste them to your message. I'm beginning to wonder about the safety of using cable. Disregard my last message.

[Chalky_WIS]

Well thanks for your help, but a very helpful support person from Agnitum asked me to check my "Base Filtering Engine" service.
and..... It's not there
Neither is the Windows Firewall service. And, the Windows Firewall and Security Centre components in Control Panel are both messed up.
So it appears that something, somewhere has removed these integral O\S components, that makes troubleshooting this any further rather pointless. If only Microsoft would make their O\S more modular and allow these type of components to be easier to remove and re-install. But as they don't, it looks like I will have to resort to a back-up and re-install of my O\S.