How To Punch A Hole Through Windows Firewall
Latrisha Adan
I knew SQL Server 2012 was up and ready to take connections because I had just installed it and the original instance of TFS, but for some reason the TFS Add an AT wizard was unable to find the SQL Server. I suspect some default settings in Windows Server 2012, or possibly a change in group policy at my work.
To troubleshoot, I did exactly what it says to do in the error message. I checked that SQL Server was configured to allow remote connections, that TCP/IP was enabled, and I determined the port SQL Server was configured to use (port 1433, the default). All that stuff checked out.
In the past, TFS added a local exception to Windows Firewall that allowed incoming connections, *if* SQL Server and TFS were installed on the same computer. I have that configuration, but I am still blocked (as you can see).
I thought it might be helpful to review how to open a hole through Windows Firewall for SQL Server in case anyone else is having this same problem. I ran into this setting up a TFS Farm, but you might run into it if your SQL Server installation for TFS spans multiple computers and you enabled Windows Firewall (as it comes by default).
Here is a guide on Technet that offers the details of each port assignment based on the instance and service. If you need to determine what type instance was used, look in the Windows Server Services control panel for the associated windows service (SQL Server service for the Database Engine; Analysis or reporting services service for the report server.)
It would be nice, if during installation of LabVIEW, installer will configure Firewall as needed for LabVIEW. For example, Network Streams - is standard LabVIEW feature, but to use it, one should manually configure Firewall (as described in this KB article). I'm sure, that there are other cases when similar should be done.
I'm pretty sure LabVIEW would be banned from a large number of our customer sites if we did this automatically. If we made it something that we asked about during the installation, I'm pretty sure none of our network functions are so standard that most users would know what we were asking about (i.e. I doubt more than half of our users have even heard of Network Streams, much less could answer "Should LV reconfigure your firewall to use Network Streams?")
Thank you, AristosQueue, for your reply! I see, and I realize it - but this is something what made me crazy couple times, so I just had to leave it here. If during so many years something similar was not done, then there is no chances that it'll be implemented now, especially before new era of NXG =))
Instead of firewall changes at install time, what about adding an option to punch holes in the Windows firewall for a desired network feature from within LabVIEW? Obviously admin rights would be required, but it'd be a time saver (digging through KBs for port ranges sucks), and would be a safer alternative to just disabling the firewall to get things working (which I have seen done).
Previously the old sql server was on two network, one of which was a private network, and we had a vpn server that would put each of these client machines on that private network. This setup is no longer available for us.
You have two options, both of which you have eliminated: tunnel through a VPN or poke a hole in the firewall. So no, without knowing a lot more about your application and network infrastructure, there is no other option.
I never once had an issue with the Windows 7 firewall blocking my CMS connection once it was set up properly. Since I moved to my Windows 10 machine, I'm fiddling with settings EVERY SINGLE TIME Windows updates. Which, you know, is like every twelve seconds, because that's how often Microsoft pushes updates.
That seems fairly unusual, but you might want to consider using a third-party security software (not, however, ZoneAlarm) to see if it pergorms better. Remember that DS and PostgreSQL need only a local connection, you shouldn't need to allow them Internet access.
However I did try the newest Windows 10 secuity feature of not allowing installed programs to write to any local storage until added to a list of allowed programs and that made it impossible for me to do things like save renders made in DS because the Windows 10 security feature I enable didn't recognize the process the contained the render as part of DS. I eventually just turned that off but it is a great security feature for people and folk that say want to lock down the email the received on a local PC against phishing attacks and such secuity problems.
I know -- which is what makes it so strange. But the firewall was definitely the culprit -- Studio and Smart Content worked fine when the firewall was off, but wouldn't connect when it was on. My PC was definitely blocking the local connection. I'm hopeful that whatever the problem was, it's fixed now. Windows installed updates and it didn't break anything this time.
I second this, including the warning against ZoneAlarm, which from what I gather is produced by a foreign-owned entity fond of gathering users' data and giving it to foreign intelligence services. I suggest Comodo Firewall (also included with their security suite, but I prefer just using their firewall). I've found it both full-featured and straightforward to use. There's a nice view that shows you exactly what's using bandwidth, and how much, and lets you end any of those processes easily, or copy-paste an offending process' location into other parts of the program, which will block it for you. I've tried most of the free firewalls out there, and I keep coming back to Comodo. P.S., just FYI, you can disable Windows Firewall if you install a 3rd party firewall, that should end any problems WF is giving you.
The Windows firewall has been fine, even from a network admin perspective, since Vista shipped. With Windows XP and older there were giant holes in the firewall and it was all but useless, but Vista and newer it's as good as any third party solution.
Connecting directly to your modem is an insanely bad idea and permenantly punching holes in the firewall is basically asking for the electronic equivilant of Boubonic Super AIDS. I worked for a cable ISP a few years ago and the only time we recommended connecting directly was when troubleshooting connection issues. Otherwise everyone - your ISP, Microsoft, and third-party firewall vendors - assume there's going to be a hardware firewall between the ethernet port on your computer and the Internet at large. A router isn't just to connect up multiple computers, it's also a key piece of home network security.
You are talking about the windows firewall on the server itself correct? ShoreTel requests that this be disabled completely on the server. The newer versions are requiring it to be disabled for it to be installed. Do you have specific concerns about the security of that server?
I will agree that this is the next logical move in the meantime, but it should never be up to us to find out what ports they need. That should be a 1 - 2 done phone call or email outlining that info to you.
When I started with VOIP, the vendor required that we play the Windows XP computer with only service pack 1 on a public IP with no firewall. i thought it would get hit and it did. Within 15 minutes the whole computer was so infected with bits and malware that it shutdown. i found a router with a firewall so i could do one to one nat and that fixed the issue.
When I SSH to a machine from inside the corporate network and tunnel over SOCKS proxy with HTTP(s) with a browser everything works fine. Of course this works because SSH MITM firewall proxy server bullshit will choke the SSH connection because they do al kind of weird time based key rotation for sessions.
Sorry for my crying at this setup. But I would like to know how to punch a hole in the firewall to use Syncthing without much effort and a vanilla build. Worst case I can shoot an SSH tunnel and tunnel TCP over it and connect syncthing on both ends but that is boring.
So, you might be able to set up a relay yourself, have your firewall-inside device connect to it, it will complain about the device ID mismatch, you change the expected device ID to suit, and then be good to go.
So the story did continue. The corporate SSL deep packet inspection (DPI) will still be enable for our VLAN. So its still possible to shoot a SSH SOCKS proxy to home and connect Syncthing through this as it is immune to SSL introspection.
It produced this output: Failed to renew certificate with error: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError(': Failed to establish a new connection: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions'))
I followed recommendations found in a couple of posts here, to drill a hole in the firewall on this host. I added a rule for C:\Program Files(x86)\Certbot\bin\certbot.exe, to allow any outbound TCP connections on port 443. The error persisted. I allowed connections over any protocol. Same error. Only when I lift the firewall for outbound certbot connects.
I need the information on which specific settings are required for certbot, in Windows firewall, because I cannot allow outbound connections for anything to anything.