Serious Discussion Block Common Attacks: A Beginner's Guide to Windows Firewall

[Divergent]

Your Windows computer has a built-in bodyguard called Windows Firewall. By default, it's pretty good at stopping unwanted incoming connections, but to truly defend against common attacks, you need to make it more proactive, especially for outgoing connections. Think of it like this: instead of letting everything out and only blocking the bad stuff you know about, we're going to block everything unless you explicitly say it's okay. This is called the "default deny" or "whitelist" approach, and it's the most secure way to go.

Understanding Firewall Profiles​

Windows Firewall uses different "profiles" based on where your computer is connected:

• Domain network: For computers connected to a work or school network (Active Directory).
• Private network: For trusted networks, like your home Wi-Fi.
• Public network: For untrusted networks, like airport Wi-Fi or a coffee shop. This one should be the strictest!

You'll want to set up rules for each profile, making them tougher for less trusted networks.

---

The Core Strategy: Block Everything, Then Allow What You Need​

This is the golden rule for strong security. Here's how to set it up:

1. Set Your Outbound Policy to "Block"​

By default, Windows lets almost anything on your computer connect to the internet. This is a big security risk! We need to change that.

Using the Graphical Interface:

1. Search for and open "Windows Defender Firewall with Advanced Security" in your Start Menu.
2. In the left panel, right-click on "Windows Defender Firewall with Advanced Security on Local Computer."
3. Select "Properties."
4. For each profile (Domain Profile, Private Profile, and Public Profile):
   • Find "Outbound connections" and change the setting from "Allow (default)" to "Block."
   • Click "OK."

Using Command Line (for the tech-savvy, use an elevated PowerShell/CMD):

"PowerShell"

netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound

2. (Optional, but Recommended) Clear Existing Outbound Rules​

To start fresh with our "block everything" approach, you can delete existing outbound rules. Be careful! This will temporarily stop many apps from working until you create new "allow" rules for them. It's a good idea to export your current settings first if you're unsure.
Using the Graphical Interface:

1. In "Windows Defender Firewall with Advanced Security," go to "Outbound Rules" in the left panel.
2. Click on any rule, then press Ctrl + A to select all of them.
3. Right-click on any selected rule and choose "Delete."

Using Command Line (Elevated PowerShell/CMD):

"PowerShell"

netsh advfirewall firewall delete rule all

3. Create "Allow" Rules for Essential Services and Apps​

Now that almost everything is blocked, you need to tell your firewall what can connect. This step requires a bit of thought about what you use daily.

Here are common things you'll almost certainly need to allow:

• DNS (Domain Name System):This translates website names (like Google Search) into numerical addresses.
  • Protocol: UDP
  • Port: 53
  • Direction: Outbound
  • Remote IP: Your router's IP address, or public DNS servers like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).
• Web Browse (HTTP/HTTPS):For accessing websites.
  • Protocol: TCP
  • Ports: 80 (HTTP), 443 (HTTPS)
  • Direction: Outbound
  • Remote IP: Any (unless you want to restrict which websites you can visit, which is advanced).
  • Tip: Instead of allowing all web traffic, you can create rules specifically for your web browser applications (e.g., chrome.exe, firefox.exe).
• Email Client:If you use an email program like Outlook or Thunderbird.
  • Protocol: TCP
  • Common Ports: 25, 587 (outgoing); 110, 995 (POP3 incoming); 143, 993 (IMAP incoming)
  • Direction: Outbound
  • Remote IP: Your email provider's server address.
  • Tip: Create rules for your specific email client application (e.g., outlook.exe).
• Windows Updates: Windows needs to connect to Microsoft servers to download updates. Your general web Browse rules might cover this, but sometimes specific allowances are needed for svchost.exe (which handles many Windows services).

How to Create an "Allow" Rule for an Application (Graphical Interface):

1. In "Windows Defender Firewall with Advanced Security," go to "Outbound Rules."
2. In the Actions panel on the right, click "New Rule..."
3. Choose "Program" and click "Next."
4. Click "Browse..." and find the executable file for the program (e.g., C:\Program Files\Mozilla Firefox\firefox.exe).
5. Select "Allow the connection" and click "Next."
6. Choose the profiles where this rule should apply (typically all of them, or just Private/Public for home users).
7. Give the rule a clear name (e.g., "Allow Firefox Outbound") and click "Finish."

---

Best Practices for Even Better Protection​

• Only Allow What's Essential: If an app doesn't need internet access, keep it blocked. If it only needs to connect to specific web addresses, try to limit it to those.
• Disable Unnecessary Services: Windows runs many background services. If you don't use something, disable it to remove potential vulnerabilities.
• Block Insecure Protocols: Block old, less secure protocols like Telnet (Port 23) or FTP (Port 21) if you don't need them. Use secure alternatives like SSH and SFTP.
• Block Common Attack Ports (Inbound):Your default inbound block is good, but be aware of ports often targeted in attacks if you ever need to allow inbound:
  • RDP (Remote Desktop Protocol): Port 3389. Block this unless you absolutely need it and only allow specific trusted computers to connect.
  • SMB (Server Message Block): Ports 139, 445. These are often used by malware to spread. Keep them blocked inbound.
• Keep Software Updated: Always update Windows and all your applications. These updates often include crucial security fixes.
• Use Antivirus/Anti-Malware: A firewall is great for network traffic, but you still need good antivirus software to catch malicious files that might sneak onto your computer.
• Keep User Account Control (UAC) On: UAC (those pop-ups asking "Do you want to allow this app to make changes to your device?") helps prevent unauthorized changes, including to your firewall settings.

---

A Word of Caution​

Setting up a "default deny" firewall is very secure, but it can also be a bit challenging at first. When an app suddenly stops working, your firewall rules are the first place to check. You might need to experiment and create new "allow" rules as you go.

By taking these steps, you'll significantly strengthen your computer's defenses against many common online threats.

What's the first application you're going to create an "allow" rule for?

 

[Bot]

Great comprehensive guide! The first application I'm going to create an "allow" rule for is my web browser, as it's essential for my daily tasks.

 

[Victor M]

you'll significantly strengthen your computer's defenses against many common online threats

In particular, it will stop malware from calling back to it's C2, because it is default deny.

Don't make a rule like 'allow tcp 443 to anywhere'. Instead you should make a browser specific rule that says 'allow Brave to connect via TCP 443 to anywhere'. If you blanket allow all port 443 traffic without specifying the browser app, malware will ride that rule and call C2.

Just remember this rule for making firewall rule: 'be specific, and use as many as you can: program name, protocol(tcp/udp), port number and ip address (from and to).

 

[Divergent]

In particular, it will stop malware from calling back to it's C2, because it is default deny.

Don't make a rule like 'allow tcp 443 to anywhere'. Instead you should make a browser specific rule that says 'allow Brave to connect via TCP 443 to anywhere'. If you blanket allow all port 443 traffic without specifying the browser app, malware will ride that rule and call C2.

Just remember this rule for making firewall rule: 'be specific, and use as many as you can: program name, protocol(tcp/udp), port number and ip address (from and to).

The initial post already covered the importance of application-specific rules as a more secure alternative to blanket port allowances.

The tip explicitly stated:
"Instead of allowing all web traffic, you can create rules specifically for your web browser applications (e.g., chrome.exe, firefox.exe)."

This directly addresses the concern about malware "riding" a general rule, highlighting that specifying the program name (like Brave, Chrome, or Firefox) is the preferred method for enhanced security.

 

[Victor M]

The initial post already covered

Sorry mate, didn't read too carefully.

 

[Parkinsond]

Don't make a rule like 'allow tcp 443 to anywhere'

Unfortunately, WFC when creating rules after selecting allow, does not specify the protocol and rules most of the time, meanwhile, I do not know what protocols and ports each program might require exactly.

 

[Divergent]

Sorry mate, didn't read too carefully.

No worries at all, it happens!

Unfortunately, WFC when creating rules after selecting allow, does not specify the protocol and rules most of the time, meanwhile, I do not know what protocols and ports each program might require exactly.

The statement 'Unfortunately, WFC when creating rules after selecting allow, does not specify the protocol and rules most of the time" is incorrect. Both the native Windows Firewall and Windows Firewall Control (WFC) absolutely allow you to specify protocols and ports, and you should always aim to do so for better security.

When you simply 'allow a program' using WFC's quick options (like from a notification), it might create a broad rule for convenience. However, you can always edit that rule or create a new, highly specific rule from scratch.

Here's how you create a specific rule to avoid 'allow tcp 443 to anywhere' for a program like a web browser (using TCP 443 for HTTPS):

1. Identify the Program: Know the exact path to the program's executable file (e.g., C:\Program Files\Google\Chrome\Application\chrome.exe).
2. Specify Direction: Is the program connecting out (Outbound Rule) or is something trying to connect to it (Inbound Rule)? For a browser connecting to websites, it's Outbound.
3. Specify Protocol: For HTTPS, it's TCP.
4. Specify Port: For HTTPS, it's 443.
5. Optionally Limit Scope: If you know the program only connects to certain specific IP addresses or ranges, you can add those. For general internet use, you'll often leave the remote IP as 'Any IP address', but the critical part is tying it to the program and the specific port.

I will demonstrate a common scenario: allowing an outbound connection for a specific program on TCP port 443. This is often used for web browsers or applications that connect to HTTPS services.

Steps using Windows Firewall with Advanced Security:

Open Windows Firewall with Advanced Security:

• Press Win + R to open the Run dialog.
• Type wf.msc and press Enter. (This is the fastest way).
• Alternatively: Go to Control Panel -> System and Security -> Windows Defender Firewall -> Advanced Settings.

Choose Rule Type:

• In the left-hand pane, select Outbound Rules (since we're allowing a program to connect out).
• In the right-hand "Actions" pane, click New Rule...

Rule Type:

• Select Program. This is crucial for tying the rule to a specific application, not just a port.
• Click Next.

Program:

• Select This program path:
• Click Browse...and navigate to the executable file (.exe) of the program you want to allow.
  • Example: For Google Chrome, it might be C:\Program Files\Google\Chrome\Application\chrome.exe.
• Click Next.

Action:

• Select Allow the connection.
• Click Next.

Protocols and Ports:

• This is where you specify the details.
• Protocol type: Select TCP.
• Local port: Usually All Ports for outbound rules (unless the program listens on a specific local port for its own operations, which is less common for outbound 443).
• Remote port: Select Specific Ports and type 443.
• Click Next.

Scope (Optional but Recommended for Security):

• Local IP address: Leave as Any IP address unless your system has multiple IPs and you want to restrict it.
• Remote IP address: This is where you can be more specificthan "to anywhere."
  • Any IP address: This is the "to anywhere" option you may want to avoid.
  • These IP addresses: Click Add...Here you can add specific IP addresses or IP ranges that the program is allowed to connect to on port 443.
    • Example: If your application connects only to 192.168.1.10, you'd add that. If it connects to cloudservice.com, you'd need to find the IP addresses associated with cloudservice.com (which can change, making this less practical for public services).
  • For most common applications like browsers, leaving "Any IP address" for remote scope on port 443 is often necessary for functionality, but the program-specific rule is still a vast improvement over a blanket port rule.
• Click Next.

Profile:

• Choose when the rule applies:
  • Domain: When connected to a corporate domain network.
  • Private: When connected to a private network (home, trusted Wi-Fi).
  • Public: When connected to a public network (coffee shop Wi-Fi, untrusted networks).
• It's generally safest to apply it only to the profiles where the program needs to function securely. For a browser, you'd likely enable all three.
• Click Next.

Name and Description:

• Name: Give the rule a meaningful name (e.g., "Allow Chrome HTTPS Outbound").
• Description (optional): Add details like "Allows Google Chrome to make outbound HTTPS connections on TCP port 443."
• Click Finish.

 

[Parkinsond]

No worries at all, it happens!


The statement 'Unfortunately, WFC when creating rules after selecting allow, does not specify the protocol and rules most of the time" is incorrect. Both the native Windows Firewall and Windows Firewall Control (WFC) absolutely allow you to specify protocols and ports, and you should always aim to do so for better security.

When you simply 'allow a program' using WFC's quick options (like from a notification), it might create a broad rule for convenience. However, you can always edit that rule or create a new, highly specific rule from scratch.

Here's how you create a specific rule to avoid 'allow tcp 443 to anywhere' for a program like a web browser (using TCP 443 for HTTPS):

1. Identify the Program: Know the exact path to the program's executable file (e.g., C:\Program Files\Google\Chrome\Application\chrome.exe).
2. Specify Direction: Is the program connecting out (Outbound Rule) or is something trying to connect to it (Inbound Rule)? For a browser connecting to websites, it's Outbound.
3. Specify Protocol: For HTTPS, it's TCP.
4. Specify Port: For HTTPS, it's 443.
5. Optionally Limit Scope: If you know the program only connects to certain specific IP addresses or ranges, you can add those. For general internet use, you'll often leave the remote IP as 'Any IP address', but the critical part is tying it to the program and the specific port.

I will demonstrate a common scenario: allowing an outbound connection for a specific program on TCP port 443. This is often used for web browsers or applications that connect to HTTPS services.

Steps using Windows Firewall with Advanced Security:

Open Windows Firewall with Advanced Security:

• Press Win + R to open the Run dialog.
• Type wf.msc and press Enter. (This is the fastest way).
• Alternatively: Go to Control Panel -> System and Security -> Windows Defender Firewall -> Advanced Settings.

Choose Rule Type:

• In the left-hand pane, select Outbound Rules (since we're allowing a program to connect out).
• In the right-hand "Actions" pane, click New Rule...

Rule Type:

• Select Program. This is crucial for tying the rule to a specific application, not just a port.
• Click Next.

Program:

• Select This program path:
• Click Browse...and navigate to the executable file (.exe) of the program you want to allow.
  • Example: For Google Chrome, it might be C:\Program Files\Google\Chrome\Application\chrome.exe.
• Click Next.

Action:

• Select Allow the connection.
• Click Next.

Protocols and Ports:

• This is where you specify the details.
• Protocol type: Select TCP.
• Local port: Usually All Ports for outbound rules (unless the program listens on a specific local port for its own operations, which is less common for outbound 443).
• Remote port: Select Specific Ports and type 443.
• Click Next.

Scope (Optional but Recommended for Security):

• Local IP address: Leave as Any IP address unless your system has multiple IPs and you want to restrict it.
• Remote IP address: This is where you can be more specificthan "to anywhere."
  • Any IP address: This is the "to anywhere" option you may want to avoid.
  • These IP addresses: Click Add...Here you can add specific IP addresses or IP ranges that the program is allowed to connect to on port 443.
    • Example: If your application connects only to 192.168.1.10, you'd add that. If it connects to cloudservice.com, you'd need to find the IP addresses associated with cloudservice.com (which can change, making this less practical for public services).
  • For most common applications like browsers, leaving "Any IP address" for remote scope on port 443 is often necessary for functionality, but the program-specific rule is still a vast improvement over a blanket port rule.
• Click Next.

Profile:

• Choose when the rule applies:
  • Domain: When connected to a corporate domain network.
  • Private: When connected to a private network (home, trusted Wi-Fi).
  • Public: When connected to a public network (coffee shop Wi-Fi, untrusted networks).
• It's generally safest to apply it only to the profiles where the program needs to function securely. For a browser, you'd likely enable all three.
• Click Next.

Name and Description:

• Name: Give the rule a meaningful name (e.g., "Allow Chrome HTTPS Outbound").
• Description (optional): Add details like "Allows Google Chrome to make outbound HTTPS connections on TCP port 443."
• Click Finish.

I know the required steps for specifying protocols and ports for each program or process.
What I need to know is which one to specify for each; I assumed WFC knows such data, and consequently when I select "allow" it allow only required protocols and ports for each program.
Considering WFC does not know, it is expected common user (such as myself) are not able to know.

 

[Divergent]

I know the required steps for specifying protocols and ports for each program or process.
What I need to know is which one to specify for each; I assumed WFC knows such data, and consequently when I select "allow" it allow only required protocols and ports for each program.
Considering WFC does not know, it is expected common user (such as myself) are not able to know.

The tutorial above is designed to kickstart your learning journey as a beginner.

You're absolutely right: it's not intuitive for a common user to know these details. This is where a bit of investigation or a more cautious approach comes in.

Here's how you, as a user, can typically figure out what protocols and ports a program requires:

1. Use Windows Firewall Control's "Connections Log" / "Notifications": (Your Best Friend)

• How it works: This is the most practical method. When a program tries to connect and is blocked by the firewall, WFC can often log this attempt or generate a notification.
• What to look for:The log entry or notification will often show:
  • The program path (.exe)
  • The direction (Inbound/Outbound)
  • The protocol (TCP, UDP, etc.)
  • The local port (if the program is listening)
  • The remote port (the port it's trying to connect to on the other end)
  • The remote IP address
• Process:
  1. Temporarily set your firewall to a more restrictive mode (e.g., "Medium Filtering" or "High Filtering" in WFC, or just ensure default outbound blocks are active).
  2. Launch the program you want to configure.
  3. Try to use the specific features of the program that require network access (e.g., if it's a game, try to join a multiplayer match; if it's a chat app, try to send a message).
  4. Watch WFC's notifications or check the "Connections Log" (usually found in WFC's main interface).
  5. When you see a connection attempt from your program that was blocked, note down the protocol and remote port. These are your prime candidates for the specific rule.
  6. You can often right-click the blocked entry in WFC's log and choose to create an "Allow" rule for that specific connection. Review and refine this rule.

2. Consult Official Documentation / Support Forums:

• How it works: Reputable software developers often document the network requirements for their applications, especially server-side software, multiplayer games, or business applications.
• What to look for: Search the software's official website, user manuals, or support knowledge bases for terms like "firewall ports," "network requirements," "port forwarding," or "allow list."
• Example: For many online games, you'll find articles listing specific UDP and TCP ports required for multiplayer.

3. Netstat Command (More Advanced):

• How it works: The netstat command in the Windows Command Prompt can show active network connections and listening ports on your system.
• Process:
  1. Open Command Prompt as Administrator (Win + X, then Command Prompt (Admin) or Windows Terminal (Admin)).
  2. Run netstat -ano. This shows active connections, the protocol, local and foreign addresses/ports, and the Process ID (PID).
  3. To find out which program owns a PID, open Task Manager (Ctrl + Shift + Esc), go to the "Details" tab, and sort by "PID."
  4. This is useful for seeing what's currently connected or listening, but less useful for discovering ports a program might use in the future.

4. Process Monitor / Wireshark (Very Advanced):

• These are powerful tools for system and network analysis, but they have a steep learning curve. If the above methods don't work, these can provide deep insights into a program's network activity. Generally overkill for a typical user.

Conclusion:

You're right, it's not a click-and-done solution for specific ports and protocols. The "common user" does indeed face a learning curve here. However, Windows Firewall Control's "Connections Log" and notifications are designed precisely to help bridge this gap. They give you the real-time data on what your applications are actually trying to do on the network, allowing you to build those precise rules you're looking for.

Start with monitoring WFC's logs when the program is active, and if that doesn't yield results, check the program's official documentation.

 

[Parkinsond]

The tutorial above is designed to kickstart your learning journey as a beginner.

You're absolutely right: it's not intuitive for a common user to know these details. This is where a bit of investigation or a more cautious approach comes in.

Here's how you, as a user, can typically figure out what protocols and ports a program requires:

1. Use Windows Firewall Control's "Connections Log" / "Notifications": (Your Best Friend)

• How it works: This is the most practical method. When a program tries to connect and is blocked by the firewall, WFC can often log this attempt or generate a notification.
• What to look for:The log entry or notification will often show:
  • The program path (.exe)
  • The direction (Inbound/Outbound)
  • The protocol (TCP, UDP, etc.)
  • The local port (if the program is listening)
  • The remote port (the port it's trying to connect to on the other end)
  • The remote IP address
• Process:
  1. Temporarily set your firewall to a more restrictive mode (e.g., "Medium Filtering" or "High Filtering" in WFC, or just ensure default outbound blocks are active).
  2. Launch the program you want to configure.
  3. Try to use the specific features of the program that require network access (e.g., if it's a game, try to join a multiplayer match; if it's a chat app, try to send a message).
  4. Watch WFC's notifications or check the "Connections Log" (usually found in WFC's main interface).
  5. When you see a connection attempt from your program that was blocked, note down the protocol and remote port. These are your prime candidates for the specific rule.
  6. You can often right-click the blocked entry in WFC's log and choose to create an "Allow" rule for that specific connection. Review and refine this rule.

2. Consult Official Documentation / Support Forums:

• How it works: Reputable software developers often document the network requirements for their applications, especially server-side software, multiplayer games, or business applications.
• What to look for: Search the software's official website, user manuals, or support knowledge bases for terms like "firewall ports," "network requirements," "port forwarding," or "allow list."
• Example: For many online games, you'll find articles listing specific UDP and TCP ports required for multiplayer.

3. Netstat Command (More Advanced):

• How it works: The netstat command in the Windows Command Prompt can show active network connections and listening ports on your system.
• Process:
  1. Open Command Prompt as Administrator (Win + X, then Command Prompt (Admin) or Windows Terminal (Admin)).
  2. Run netstat -ano. This shows active connections, the protocol, local and foreign addresses/ports, and the Process ID (PID).
  3. To find out which program owns a PID, open Task Manager (Ctrl + Shift + Esc), go to the "Details" tab, and sort by "PID."
  4. This is useful for seeing what's currently connected or listening, but less useful for discovering ports a program might use in the future.

4. Process Monitor / Wireshark (Very Advanced):

• These are powerful tools for system and network analysis, but they have a steep learning curve. If the above methods don't work, these can provide deep insights into a program's network activity. Generally overkill for a typical user.

Conclusion:

You're right, it's not a click-and-done solution for specific ports and protocols. The "common user" does indeed face a learning curve here. However, Windows Firewall Control's "Connections Log" and notifications are designed precisely to help bridge this gap. They give you the real-time data on what your applications are actually trying to do on the network, allowing you to build those precise rules you're looking for.

Start with monitoring WFC's logs when the program is active, and if that doesn't yield results, check the program's official documentation.

Tried but it did not work.
1-Deleted allow rule for Edge
2-Blocked Edge when prompted by WFC
3-Took a note of each blocked protocol and port for Edge
4-Created five separate rules for each one
and still Edge was not able to connect.

 

[Divergent]

Tried but it did not work.
1-Deleted allow rule for Edge
2-Blocked Edge when prompted by WFC
3-Took a note of each blocked protocol and port for Edge
4-Created five separate rules for each one
and still Edge was not able to connect.

In the beginner's tutorial I provided earlier for creating a specific rule, I focused on TCP port 443 for HTTPS as the primary example, as it's the most common and easily understood.

My initial beginner tutorial was simplified to avoid overwhelming a complete novice with too many details at once, focusing on the most fundamental port. My later explanation in the troubleshooting section was designed to fill in those gaps for a user who encountered real-world issues.

To be completely accurate and helpful for a beginner, a more comprehensive initial rule set for a browser should indeed mention:

• TCP Port 443 (HTTPS)
• TCP Port 80 (HTTP)
• UDP Port 53 (DNS)
• UDP Port 443 (QUIC/HTTP/3)

Troubleshooting Edge Connectivity: A Step-by-Step Approach

It's understandable that trying to fine-tune firewall rules for a complex application like a web browser can be frustrating. Browsers are incredibly dynamic, using many ports and protocols for various functions (web content, ads, telemetry, updates, etc.).

If you've tried creating specific rules based on initial blocked prompts and Edge still isn't working, let's use a systematic approach to identify the root cause.

Recommendations to get Edge working, and then refine your rules:

1. Simplify and Re-test (The "Scientific Method" Approach):

This step helps us confirm if the firewall is truly the issue, or if something else is preventing Edge from connecting.

Delete any existing specific rules you created for Microsoft Edge.

Create one single, broad "Allow" rule for Edge:

Program: Specify the full path to msedge.exe (e.g., C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe).

Direction: Outbound (since Edge initiates connections to websites).

Action: Allow the connection.

Protocols and Ports: Choose All Protocols and All Ports (both Local and Remote).

Scope: Set Any IP Address for both Local and Remote.

Profiles: Select All (Domain, Private, Public) to ensure it works on any network type.

Test Edge: After creating this broad rule, try using Edge extensively. Does it work now, allowing you to browse different websites?

If YES: This confirms that your firewall rules were indeed the problem, and you likely missed some critical ports, protocols, or directions in your initial specific rules. Proceed to Step 2 to refine.

If NO: If Edge still doesn't connect even with this broad "Allow All" rule, then the problem is likely not your firewall configuration. Instead, investigate other potential issues such as an Edge installation problem, network adapter issues, DNS problems, or incorrect proxy settings.

2. Refine Rules After Confirmation (If Step 1 was "YES"):

Now that you know Edge can connect with a broad rule, you have a baseline. The goal is to identify only the truly necessary connections.

With Edge working (using the broad "Allow All" rule), go back to Windows Firewall Control's "Connections Log" and "Notifications."

Actively use Edge: Browse different types of content, visit various websites, stream a video, and engage with interactive elements. This will force Edge to make a wide range of connections.

Identify all the protocols and ports that Edge is successfully using as they appear in the logs. You will likely see a wide variety.

Start adding specific "Allow" rules for these identified connections, but be realistic about granularity:

You will almost certainly need TCP Port 80 and TCP Port 443 outbound (for standard HTTP and HTTPS web traffic).

You will almost certainly need UDP Port 53 outbound (for DNS resolution, converting website names to IP addresses).

You will very likely need UDP Port 443 outbound (for QUIC/HTTP/3, a newer, faster web protocol often used by modern browsers).

For the Scope of these core Browse rules, keeping "Remote IP address" as "Any IP address" is usually necessary for a web browser, as it connects to countless different servers worldwide. Trying to restrict this to specific IPs for general Browse is generally impractical.

Gradually disable and test: As you create and enable your new, more specific rules, incrementally disable the broad "Allow All" rule you created in Step 1. Test Edge's functionality after each disabling step. This iterative process will help you narrow down the minimal set of rules required. You'll likely find a practical set of 5-10 rules that covers most of Edge's Browse needs without being overly restrictive.

 

[Parkinsond]

• TCP Port 443 (HTTPS)
• TCP Port 80 (HTTP)
• UDP Port 53 (DNS)
• UDP Port 443 (QUIC/HTTP/3)

I created rules for the above mentioned and one more for TCP 5222 according to the blocked connections log; did not work.
Actually Avast-AVG firewall in "ask" mode is very good; it allows only the connection to the specified protocol and port, not like WFC or simplewall.
The only drawback of their firewall in ask mode, it blocks completely Edge, even if allowed in rules.

 

[Trident]

The only drawback of their firewall in ask mode, it blocks completely Edge, even if allowed in rules.

I’ve not experienced that. You’ve created some wrong rules.

 

[Divergent]

I created rules for the above mentioned and one more for TCP 5222 according to the blocked connections log; did not work.
Actually Avast-AVG firewall in "ask" mode is very good; it allows only the connection to the specified protocol and port, not like WFC or simplewall.
The only drawback of their firewall in ask mode, it blocks completely Edge, even if allowed in rules.

you've seen Avast's "ask" mode's effectiveness, you need to simulate that "ask" mode's data gathering with WFC's capabilities:

1. Re-enable your broad "Allow All" for Edge (the one with All Protocols, All Ports, Any IP). Confirm Edge is fully functional. This is your working baseline.
2. Clear WFC's Connections Log.
3. While Edge is active and functional (with the broad rule), closely monitor WFC's "Connections Log" for all connections Edge makes.Pay attention to:
   • Source Process: Make sure it's msedge.exe or related Edge processes.
   • Protocol: Note TCP and UDP.
   • Local Port & Remote Port: Note both. Remote ports are especially critical.
   • Remote IP/Address: Look for the various destinations.
   • Frequency: Observe what connections are constantly active.
4. Gradually Build Specific Rules (Iterative Process):
   • Identify the most common, fundamental connections (TCP 80, 443; UDP 53, 443, etc.).
   • Create specific allow rules for these.
   • Important: Start by disabling the broad "Allow All" rule for Edge.
   • Test Edge immediately. What breaks? What new connections are blocked in the log now? Add rules for those newly blocked connections.
   • This will be an iterative process. You might have to use Edge for a while (e.g., an hour or two of normal Browse) to capture most recurring connections.
   • Consider slightly broader "program-specific" rules: For a browser, creating a rule that allows msedge.exe to use TCP Any Remote Port and UDP Any Remote Port for outbound connections (instead of specifying every single port) is often a more practical and still relatively secure compromise compared to "Allow TCP 443 to anywhere." This way, you're tying the allowance to the program, but giving it flexibility on ports.

 

[Parkinsond]

I’ve not experienced that. You’ve created some wrong rules.

I just selected allow when prompted; Avast-AVG are the second in bugs after B.

 

[silversurfer]

Unfortunately, WFC when creating rules after selecting allow, does not specify the protocol and rules most of the time, meanwhile, I do not know what protocols and ports each program might require exactly.

What if you wouldn't use WFC Learning Mode and allowing manually outbound connections, then ALL info about protocol, ports, etc. are displayed in notifications by WFC

 

[Parkinsond]

What if you wouldn't use WFC Learning Mode and allowing manually outbound connections, then ALL info about protocol, ports, etc. are displayed in notifications by WFC

View attachment 289911

I did what Divergent instructed (which is almost the same), collected the data of blocked connections from log, created allow rules for each, and still failed to connect.
Only AVG firewall did it the right way with no effort.

 

[Divergent]

I did what Divergent instructed (which is almost the same), collected the data of blocked connections from log, created allow rules for each, and still failed to connect.
Only AVG firewall did it the right way with no effort.

For a browser, the most practical balance between security and full functionality with a static firewall often requires one additional, slightly broader program-specific rule.

Here's the most practical set of rules for Edge using Windows Firewall/WFC:

This set of rules is much safer than non-program-specific allowances. It's a smart and practical way to balance the security of containing network access to specific applications with the functional needs of a modern web browser. It's a well-chosen compromise for the limitations of a static firewall in this scenario.

1. Rule 1: Edge - Outbound HTTP/HTTPS
   • Program Path: msedge.exe
   • Direction: Outbound
   • Action: Allow
   • Protocol type: TCP
   • Remote port: 80, 443
   • Remote IP address: Any IP address
   • Profiles: All
2. Rule 2: Edge - Outbound DNS
   • Program Path: msedge.exe
   • Direction: Outbound
   • Action: Allow
   • Protocol type: UDP
   • Remote port: 53
   • Remote IP address: Any IP address (or your specific DNS servers)
   • Profiles: All
3. Rule 3: Edge - Outbound QUIC/UDP443
   • Program Path: msedge.exe
   • Direction: Outbound
   • Action: Allow
   • Protocol type: UDP
   • Remote port: 443
   • Remote IP address: Any IP address
   • Profiles: All
4. (Crucial Addition) Rule 4: Edge - Allow Remaining Outbound TCP/UDP
   • Name: Edge - Outbound General
   • Description: Allows Microsoft Edge to make all other necessary outbound TCP and UDP connections not covered by specific rules (e.g., updates, extensions, sync, WebRTC). This rule ensures full browser functionality while still being tied to the Edge executable.
   • Program Path: msedge.exe
   • Direction: Outbound
   • Action: Allow
   • Protocol type: Any (or TCP, UDP)
   • Remote port: All Ports
   • Remote IP address: Any IP address
   • Profiles: All

Why Rule 4 is often necessary for browsers:

This rule specifically allows the msedge.exe process to make any outbound TCP or UDP connection it needs to any remote port or IP. It's a broad allowance, but it's tied to the specific program. This is a significant security improvement over allowing "TCP All Ports to Anywhere" for any program, because only Edge can use this rule. It's the compromise needed to make a browser fully functional without the "ask" mode of a firewall like AVG.

 

[Divine_Barakah]

For me the GUI of FW seems overwhelming. I prefer 3rd party Firewalls as they are easier to use.

In BD there is an option called "Alert Mode" which gives alerts for application rights to access the internet and control each connection. The same functionality is available in Norton, Avast and AVG and im sure other vendors have it, too.