I have a computer (Vista) that has to have a firewall on it. Furthermore, it's imposed (from management) that under Firewall properties, the Outbond connections are blocked. The default is "Allow". I would, however, like this computer to be able to see networked drives. I have tried opening up various things by going to Outbound Rules, picking New Rule->Predefined and turning on Network Discovery, File and Printer Sharing, Core Networking. I can't see the networked drive. As a sanity check, I have disabled the firewall and verified that all is well. Also, setting the default outbound connection to "allow" works.
Any ideas on this specific problem? Any tutorials on Windows Firewall for Vista? I've seen a few but they are basic. They certainly don't address this problem.
Thanks.
Thanks. I finally figured this out. In case someone looks at this months from now, here's the key details:
The computer had already been setup to use a "private" as opposed to "domain" or "public" setting. Thus in Windows Firewall w/ Advanced Security I made sure that CoreNetworking, File and Printer Sharing, and Network Discovery we're all opened up. I did this by clicking on "Outbound Rules", and picking Action->New Rule->Predefined and then the relevant category. Further, for all of the File & Print Sharing category, for the Profiles marked Private, set the remote address to “Any”. Finally, I changed the rules, CoreNetworking – Group Policy(TCP-OUT) and CoreNetworking – Group Policy(N-OUT). I changed the Profile from Domain to Any.
Quite possibly, I opened up things more than I needed to.
Thanks.
Related
Anyone can helme? i get problem whit virtual host
This is my problem
I solved that issue as follow
Menu -> Apache -> sites-enabled -> delete all (auto)
C:\Windows\System32\drivers\etc\hosts right click -> properties on hosts file and uncheck the "Read-only"
make sure auto virtual host is checked on laragon
restart laragon and try your project folder name inside in www with .test (or as specified in laragon setting) in the browser
This question has entirely insufficient details to help you in any meaningful way. However, if I had to guess, I would say there are couple of possible reasons:
Your DNS for is not configured properly for online-shop.dev. Note, .dev is an actual top-level domain, owned by Google and reserved for their own use - https://icannwiki.org/.dev, so it's likely you are trying to follow some advice how to setup .dev for local development, but Firefox is actually looking against the real .dev DNS servers.
Assuming your DNS is indeed properly configured (in which case you happen to work for Google, and you just accidentally leaked their Amazon competitor :-)), it is possible that your app server is not running. It's impossible to say by the screenshot.
Assuming that the DNS and the app server are configured and running properly, it's possible your firewall is blocking port 80.
This blog post ("How to Easily Watch Netflix and Hulu From Anywhere in the World") explains how someone outside the US can watch Netflix and Hulu - which are typically restricted to people living inside the United States - by changing their DNS servers.
My question is, how can this change how Hulu sees your location?
From what I understand, a DNS server simply translates a web address into an IP address for you. However, at the end of the day, it's still your computer connecting to the website, let's say Hulu. Hulu still knows that my computer is not in the US. Hulu doesn't know how I got it's address (i.e. they don't care which DNS server told me)
Instructions (reproduced from HowToGeek)
Press the Win + R keyboard combination, then type ncpa.cpl into the run box and hit enter.
Then right-click on your current network adapter and choose properties from the context menu.
When the properties dialog opens, scroll down and choose Internet Protocol Version 4 (TCP/IPv4), then click the properties button.
Then change your DNS Settings to the following IP’s:
Preferred DNS: 149.154.158.186
Alternate DNS: 199.167.30.144
The only thing you have to know here is that these are tunlr DNS service IPs. The trick here is to route all the trafic through tunlr which enables you to use virtual locations instead of more traditional VPNs or proxies.
From their FAQ :
Tunlr does not provide a virtual private network (VPN). Tunlr is a DNS (domain name system) unblocking service. We’re using sophisticated technologies (a.k.a. the Tunlr Secret Sauce ©) to re-adress certain data envelopes, tricking the receiver into thinking the envelope originated from within the U.S. For these data envelopes, Tunlr is transparently creating a network tunnel from your location to our U.S.-based servers. Any data that’s not directly related to the video or music content providers which Tunlr supports is not only left untouched, it’s also not even routed through Tunlr. In order to use Tunlr, you will have to change the DNS address. See Get started for more information.
For more information, you can refer either to the FAQ/How it works section or to this discussion on SuperUser.
Unable to do the windows update through batch patch. When I tried to check for available updates, some instances are showing the error message as “Error 1601: Failed to retrieve WMI info. The RPC server is unavailable".
I have tried the below troubleshooting steps for those instances which are showing error.
1. Windows Firewall – opened ports 135 and 445
2. Checked the RPC service to see if it is running and set to automatic
3. If the instance is stopped, we have left it alone
Followed this KB https://batchpatch.com/troubleshooting-common-errors-in-batchpatch no luck. Anyone who has experience or idea what is wrong please guide me.
It's peculiar that you would post on stackoverflow rather than contacting BatchPatch support directly (https://batchpatch.com/contact) or posting on the support forum (https://batchpatch.com/forum).
The page that you linked (batchpatch.com/troubleshooting-common-errors-in-batchpatch) contains additional links for troubleshooting the 'RPC server is unavailable' error. It specifically points to these two links:
batchpatch.com/using-batchpatch-with-windows-firewall
batchpatch.com/batchpatch-ports
It is not sufficient to just open 135 and 445 in the Windows Firewall. You must open 'File and Printer sharing' and 'Windows Management Instrumentation (WMI).' In your case, probably the error is occurring because you did not open 'Windows Management Instrumentation (WMI).'
The above link also further explains:
In order for WMI to work properly… The target computer must be able to
receive and process RPC (Remote Procedure Call) requests. Both the WMI
and RPC services must be running on the target computer. If you’re
using Windows Firewall on the target computer, then please follow the
instructions on this page to configure it properly: Using BatchPatch
with Windows Firewall
(batchpatch.com/using-batchpatch-with-windows-firewall).
If you are using a hardware firewall, the configuration for WMI can
potentially be a bit trickier, depending on the particular firewall
device. WMI connections, by default, are not established on a
static/fixed port. Instead WMI uses dynamic port configuration for its
connections, which means that the actual ports used for a given
connection are established on-the-fly at the time of connection. Each
connection will end up using different ports. In the context of a
classic hardware firewall, this used to be a problem because hardware
firewalls would typically require any open ports to be configured
manually. An enterprise firewall administrator could never know in
advance which ports would need to be opened. However, fortunately many
modern firewalls now implement DCE/RPC, which solves this problem and
allows the use of dynamic ports for WMI/RPC. If you have a network
level hardware firewall in place between the BatchPatch computer and
the target computers, you’ll need to configure it to allow DCE/RPC, so
that it can open the necessary ports, on-the-fly, for each WMI
connection. More info on DCE/RPC can be found at the following two
links:
en.wikipedia.org/wiki/DCE/RPC
wiki.wireshark.org/DCE/RPC
Very new to the Self Host WebApi, but I am very impressed with its ease of use and extendability. At least through this tutorial. Everything I've done so far works on my development machine whether I use localhost, 127.0.0.1, or my LAN Ip (192.168.0.x) but I am baffled why I can't access the service from any other computer even others in the same subnet.
In short after going through the tutorial on the machine where it is running:
Browsing to
localhost:3636/api/products/
results in the expected xml return.
On another machine on the LAN browsing to:
192.168.0.x:3636/api/products/
results in a timeout
Data points for those who might know how this all interacts:
1.) My dev machine(192.168.0.x, server, host whatever you want to call it) has IIS on it; I was so paranoid it was in the way that I stopped it via the Administration GUI
2.) I have reserved the URL/Port with the following command line executions:
>netsh http add urlacl url=http://+:3636/ user=DOMAIN\USER listen=yes delegate=yes
>netsh http add urlacl url=http://192.168.0.x:3636/ user=DOMAIN\USER listen=yes delegate=yes
2.b) I've tried both of those together and individually, and tried changing the user to "everyone" to no avail
3.) I have tried to change the code in the tutorial to set the
config.HostNameComparisonMode = HostNameComparisonMode.Exact //default is Strong Wildcard
4.) I can successfully ping and tracert to 192.168.0.x from other machines on the LAN
5.) A friend recommended I setup a TCPListener and ensure I could telnet to that to eliminate the firewall as a possibility. If that logic is sound, the firewall isn't the problem
EDIT: Thanks for your help, here's another data point that I believe confirms it's not a firewall issue. I previously posted this connection when behind a rather obtuse (at least to a non Certified guy like me) Juniper Firewall/Router. I have since redone the tutorial on another machine (without IIS) on my home network and still cannot publish the service to other computers within my LAN. Any ideas?
Well it wasn't the hardware firewall, it was the windows firewall! yikes i wasted a bunch of time on that. Once I turned off the windows firewall (the code runs in an intranet anyway) everything worked.
Anyone know of a good site that explains how firewalls and wireshark interact; or i suppose that just has to be one's first test.
I would try a couple things:
First off, get rid of the HostNameComparisonMode line. That might actually disable requests coming from other machines.
If things still don't work, try getting rid of the URL ACLs and run your application as an administrator and see if that works. If that works, you may be able to add the URL ACL back on and not have to run as an administrator. You should only need the one with '+' as the hostname.
I faced the same problem when i tried to self host using OWIN. What worked for me was -
Run Visual Studio as an Admin
Remove any and all netsh urlacl port registrations that I had added while debugging this issue
Add a inbound rule to my windows firewall
I followed the instructions on this link
https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/firewall-instructions
Check out the section - To enable a port range in advance
That's it! I was able to call my api from other computers on the network.
Hope this helps...
I have an MVC site hosted on IIS 7. It works fine when accessed from the server itself.
However when I tried to access it from the same LAN as the server's the website wasn't reachable.
Next I disabled the windows firewall on the server and the site was accessible from within the LAN.
I would like to have the firewall enabled AND be able to access the site.
What do I have to enable in the firewall?
Thanks.
Ok, it was an old question, but I just found the inbound rule you need turn on. Hope the screenshot can help others in future.
Win7-firewall-inbound-BranchCache Content Retrieval (HTTP-In)
Try opening the port in Windows Firewall. Go to "Advanced Settings" in the Firewall setup and check the inbound rules and add the port if necessary.
I had the exact same issue, but the firewall in my system is managed by ESET smart security. In my case, I was not able to access the site from my machine with the firewall enabled. I wanted to add my answer so that it helps someone who is facing this issue with ESET.
Initially, I disabled the firewall and accessed the site.
While accessing the site, I checked the ports being used for the connections using "ESET SysInspector -> Network Connections". Found that my site's port was being used by the program "system".
Then I went to ESET's "Advanced setup -> Network -> Personal firewall -> Rules and zones". Clicked on "setup" under "zone and rule editor".
Click on "Toggle application tree view". Then under the column "Application/Rule", expanded "System" and found the rule "Deny communication for System" which was set to "Deny" for "Internet in". I set it to "Allow" for my site's local port and clicked "Ok" all the way out and was able to access my site with firewall enabled.