Windows Defender Firewall Inbound Rule for ICMPv6
Hi!
I'm getting more into IPv6 these days and found that ICMP is very important for IPv6 connectivity.
Windows Defender Firewall with Advanced Security (on Windows 10 at least) comes with some inbound ICMPv6 allow rules, but unfortunately they don't allow for quite enough.
I went ahead to create a rule by hand, but found out that you cannot set a group for the rule through the GUI, so instead I opted for creating a little PowerShell command.
You have to run it from a UAC-elevated PowerShell instance.
This rule is based on the existing default ICMPv6 rules.
Create the rule:
New-NetFirewallRule -DisplayName "Core Networking - CUSTOM - Allow Incoming ICMPv6" -Group "Core Networking" -Direction Inbound -Action Allow -Protocol ICMPv6 -Program System
Remove the rule again:
Remove-NetFirewallRule -DisplayName "Core Networking - CUSTOM - Allow Incoming ICMPv6"
Some people may want to exclude echo request for privacy or "security (through obscurity)" reasons, but I don't think it's that big of a deal.
Of course feel free to customize the command in general. The official documentation page (docs.microsoft.com) is very informative.
If you have any other firewalls between you and the sender, you may have to check their rules as well.
I tested the rules with a website like ipv6-test.com.
Thanks for reading!
Making Traceroutes Work with a Firewall (Windows)
Hi!
Even though I've had software firewalls in action for years now, I haven't really come across too many instances where I'd need traceroutes. The few times I did, however, I noticed that I only got output like the following:
>tracert example.com Tracing route to example.com [123.123.123.123] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 50 ms 50 ms 50 ms example.com [123.123.123.123] Trace complete.
The number of hops would of course vary for the specific host / IP address.
Today I had to use traceroute in order to analyze a couple of networking problems. That was the incentive I needed to look up why it didn't work.
The fact that not even my router was showing up was a big indicator that something was wrong with my local firewall settings.
After searching the web for a couple of minutes, I found out what I was looking for at this page: http://www.phildev.net/ipf/IPFques.html#ques34
Traceroute is using ICMP packets (plus UDP on Linux systems, but that's outside the scope of this blog entry. You can read more about it on the page I linked above). But even for an outgoing traceroute you need to accept incoming ICMP packets.
Which ones? These:
- ICMP TTL Expired (Type 11, Code 0)
- ICMP Port Unreachable (Type 3, Code 3)
Once you've enabled these types of packets for incoming traffic in your firewall(s), you'll see that your traceroute will now function as it should.
If your firewall does not allow you to configure accepting specific types of ICMP packets, try allowing incoming ICMP packets altogether (if that's not too much of a compromise for you).
Anyway, long-ish story short: It's working now 🙂
Thanks to the webmaster of the page I linked above! And thanks to you for reading.
Adobe Premiere Pro CS5 and the Long Loading Splash
Hi!
If you have used Adobe Premiere Pro CS5 (or several other CS5 products as I've read), you might have encountered long waiting times during the program launching. In the case of Premiere Pro CS5, the splash screen shows "Loading ExporterQuickTimeHost.prm" and sticks with it for a couple of minutes (yes, minutes). This is not even a one-time thing or a once-per-Windows-session, it happens each and every program launch.
When I researched this, I quickly found the answer in Adobe's forums: Premiere CS5 takes 5 minutes to start up
In fact, what's causing this is not just the Adobe program, but rather the combination of a firewall and the Adobe program. If you are as restrictive in terms of Internet access as I am, you might have forbidden Adobe Premiere Pro.exe outgoing IP connections altogether. However, it is trying to establish a TCP connection to localhost / 127.0.0.1.
The fix is to allow outgoing TCP (I chose IP, which of course includes TCP) to 127.0.0.1 for the following executables:
- <Premiere Directory>\Adobe Premiere Pro.exe
- <Premiere Directory>\32\Adobe QT32 Server.exe
- <Premiere Directory>\32\dynamiclinkmanager.exe
with <Premiere Directory> of course being the path to your Adobe Premiere directory.
Note: Of course you can still stop every other outgoing traffic. Regard the 127.0.0.1 rule as an exception.
If you are trying to apply this fix to other Adobe programs, you are on your own to find out which .exes require 127.0.0.1 TCP connections. With modern firewalls, however, this shouldn't be that big of a problem. Just look at the prompts your firewall pops up and/or determine the .exes via logging.
I hope that helps you enjoy your respective Adobe program(s) all the more. 🙂
Good luck and, as always, thanks for reading.
Update (2010-03-28):
I recently found out that with my kind of firewall "Adobe Premiere Pro.exe" would prompt me again for a rule for outgoing traffic to addresses different from the localhost zone. If that happens to you, make sure you don't accidentally replace or override the localhost rule you added above. Rather add an additional rule for all the remaining outgoing traffic and forbid it (or allow it, depending on what you want).