Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=
-
Starting just a few weeks ago, I cannot resolve any sites with https://go.microsoft.com/fwlink/?LinkId= in them, regardless of the number at the end. I always get:
Hmmm… can't reach this page
go.microsoft.com took too long to respond
I don't see that our firewall is blocking the traffic as it goes out and even turned off Window Firewall to troubleshoot, which didn't change anything. However, this only happens on PCs on our network. When testing on my phone use my carrier's mobile data, I can load the page. Put my phone back on the company WiFi and it times out.
How can I verify the pfSense firewall is not blocking these URLs?
-
If I tracert microsoft.com (on my DNS Server), I get:
Tracing route to microsoft.com [40.112.72.205]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms [internal router] [192.168.20.200]
2 7 ms 7 ms 7 ms 10.33.0.1
3 9 ms 11 ms 13 ms 100.127.77.30
4 10 ms 15 ms 9 ms 100.120.100.40
5 11 ms 12 ms 16 ms fed1bbrj01.xe110.0.rd.sd.cox.net [68.1.0.155]
6 13 ms 11 ms 14 ms ae60-0.phx01-96cbe-1b.ntwk.msn.net [198.200.130.148]
7 40 ms 38 ms 35 ms ae2-0.dal-96cbe-1b.ntwk.msn.net [104.44.227.71]
8 150 ms 146 ms 143 ms be-72-0.ibr02.dfw05.ntwk.msn.net [104.44.8.130]
9 138 ms 140 ms 139 ms be-3-0.ibr02.sn4.ntwk.msn.net [104.44.4.88]
10 149 ms 146 ms 139 ms be-7-0.ibr02.atl30.ntwk.msn.net [104.44.17.229]
11 140 ms 138 ms 141 ms be-5-0.ibr02.atb.ntwk.msn.net [104.44.17.224]
12 143 ms 144 ms 149 ms be-2-0.ibr03.atb.ntwk.msn.net [104.44.4.41]
13 139 ms 145 ms 147 ms be-4-0.ibr01.was05.ntwk.msn.net [104.44.4.22]
14 139 ms 144 ms 149 ms be-1-0.ibr02.was05.ntwk.msn.net [104.44.4.19]
15 139 ms 139 ms 142 ms be-6-0.ibr02.nyc30.ntwk.msn.net [104.44.4.28]
16 139 ms 140 ms 141 ms be-3-0.ibr02.ewr30.ntwk.msn.net [104.44.7.105]
17 139 ms 142 ms 139 ms be-4-0.ibr02.sxl71.ntwk.msn.net [104.44.17.155]
18 140 ms 145 ms 150 ms be-6-0.ibr02.dub07.ntwk.msn.net [104.44.16.115]
19 143 ms 141 ms 144 ms ae122-0.icr02.dub07.ntwk.msn.net [104.44.11.72]However, if I tracert go.microsoft.com, I get:
Tracing route to e11290.dspg.akamaiedge.net [23.65.34.215]
over a maximum of 30 hops:1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out. -
It's not blocking anything. I've seen this behaviour based on which browser you're using. I also used to get an error about circular links or some such with those MS fwlink URLs. In those cases, the problem magically went away if you used IE instead of Chrome/FF.
-
@KOM, Thanks for that info. However, I have now verified in the logs that pfSense IS blocking it:
X Jun 19 10:50:10 LAN 192.168.20.3:63548 23.65.34.215:80 TCP:S
So, how do I set a rule to NOT block go.microsoft.com? I'd prefer to set it to the URL and not the IP as that might change in the future.
@KOM said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
It's not blocking anything. I've seen this behaviour based on which browser you're using. I also used to get an error about circular links or some such with those MS fwlink URLs. In those cases, the problem magically went away if you used IE instead of Chrome/FF.
-
By itself pfSense is not blocking your web traffic. Are you running any packages like pfBlocker? By default, LAN has an allow all to any rule, so it would not be blocking a SYN to Microsoft on port 80. However, some packages that affect LAN traffic might be doing something.
-
I'm new to pfSense as I inherited these in my new position. I see now when I clicked the X, it shows me the rule that is causing the block. I'll look into that.
@KOM said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
By itself pfSense is not blocking your web traffic. Are you running any packages like pfBlocker? By default, LAN has an allow all to any rule, so it would not be blocking a SYN to Microsoft on port 80. However, some packages that affect LAN traffic might be doing something.
-
Post a screen of your LAN rules so we can see what's going on. Also check your floating rules in case somebody put something there.
-
Apparently, it is getting blocked by snort (snort2:c). I looked in the Snort log and see it listed in the alerts. I'm trying to remove that from the list of blocked IPs.
-
This is exactly why I don't use Snort or Suricata. Too many false positives and hits on totally benign traffic. Why on Earth would Snort block tcp/80 traffic to Microsoft?
Glad to hear that you've figured it out.
-
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
Apparently, it is getting blocked by snort (snort2:c). I looked in the Snort log and see it listed in the alerts. I'm trying to remove that from the list of blocked IPs.
Snort would generally only block this when you have the somewhat stringent policy rules enabled (Emerging Threats policy rules are what I'm talking about). One other possibility is some of the HTTP_INSPECT preprocessor rules. If you post the specific rule that blocked (either screen capture the alert or post up the numbers from the GID:SID column), that will help.
-
Thanks for sharing that. I was going into the Alerts and Tables and kept forcing to delete that IP but it kept coming back on its own. I eventually did a force-disable action on the rule (in the Alerts tab) and now it is not blocking it.
I'm going to look at what you suggested, too. Thanks!
@bmeeks said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
Apparently, it is getting blocked by snort (snort2:c). I looked in the Snort log and see it listed in the alerts. I'm trying to remove that from the list of blocked IPs.
Snort would generally only block this when you have the somewhat stringent policy rules enabled (Emerging Threats policy rules are what I'm talking about). One other possibility is some of the HTTP_INSPECT preprocessor rules. If you post the specific rule that blocked (either screen capture the alert or post up the numbers from the GID:SID column), that will help.
-
I found that Emerging Threats IS enabled. I'll have to read up on that a bit to better understand what it is doing and if needed. Thx!
-
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
I found that Emerging Threats IS enabled. I'll have to read up on that a bit to better understand what it is doing and if needed. Thx!
There are many Emerging Threats rule categories. I was specifically talking about the one called "Policy Rules" or something close to that (can't remember the exact name at the moment). It alerts on stuff like downloading EXE files, visiting software update sites, etc. That rule category (or at least some of the rules in that category) may be too stringent for many networks. An admin might want a stringent policy like that if say they ran an internal Microsoft Update Services Server and wanted to restrict company PCs to only receiving updates from that setup and not allow them access to outside sources of software updates.
You can see the rule categories on the CATEGORIES tab, and there you can click the hyperlinks to see the individual rules within each category. Or you can go to the RULES tab for an interface and select from the enabled categories for that interface and view and manage the individual rules that way.
-
@bmeeks said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
Snort would generally only block this when you have the somewhat stringent policy rules enabled (Emerging Threats policy rules are what I'm talking about). One other possibility is some of the HTTP_INSPECT preprocessor rules. If you post the specific rule that blocked (either screen capture the alert or post up the numbers from the GID:SID column), that will help.
The rule was@18(1000000110). I can't remember exactly but said something like, "Labeled Block Snort2:c..."
-
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@bmeeks said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
Snort would generally only block this when you have the somewhat stringent policy rules enabled (Emerging Threats policy rules are what I'm talking about). One other possibility is some of the HTTP_INSPECT preprocessor rules. If you post the specific rule that blocked (either screen capture the alert or post up the numbers from the GID:SID column), that will help.
The rule was@18(1000000110). I can't remember exactly but said something like, "Labeled Block Snort2:c..."
No, that's just the pfSense firewall rule name. Snort actually blocks by putting IP addresses in a special
pfpacket filter firewall table called snort2c. Snort itself will show blocks on the BLOCKS tab of Snort (access via SERVICES > SNORT from the pfSense menu). You can see Snort's alerts on the ALERTS tab within the Snort GUI (access via the same menu path).If you are new to administering Snort on pfSense, then this link can help: https://docs.netgate.com/pfsense/en/latest/ids-ips/setup-snort-package.html.
-
@bmeeks said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
I found that Emerging Threats IS enabled. I'll have to read up on that a bit to better understand what it is doing and if needed. Thx!
There are many Emerging Threats rule categories. I was specifically talking about the one called "Policy Rules" or something close to that (can't remember the exact name at the moment). It alerts on stuff like downloading EXE files, visiting software update sites, etc. That rule category (or at least some of the rules in that category) may be too stringent for many networks. An admin might want a stringent policy like that if say they ran an internal Microsoft Update Services Server and wanted to restrict company PCs to only receiving updates from that setup and not allow them access to outside sources of software updates.
You can see the rule categories on the CATEGORIES tab, and there you can click the hyperlinks to see the individual rules within each category. Or you can go to the RULES tab for an interface and select from the enabled categories for that interface and view and manage the individual rules that way.
OK, so under Snort | WAN | Categories, I now see the list of rulesets. Since I already did a forced disable of the rule, I imagine it is no longer checked. So, I'll see if I can go backwards and figure it out. Thanks!
-
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@bmeeks said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
I found that Emerging Threats IS enabled. I'll have to read up on that a bit to better understand what it is doing and if needed. Thx!
There are many Emerging Threats rule categories. I was specifically talking about the one called "Policy Rules" or something close to that (can't remember the exact name at the moment). It alerts on stuff like downloading EXE files, visiting software update sites, etc. That rule category (or at least some of the rules in that category) may be too stringent for many networks. An admin might want a stringent policy like that if say they ran an internal Microsoft Update Services Server and wanted to restrict company PCs to only receiving updates from that setup and not allow them access to outside sources of software updates.
You can see the rule categories on the CATEGORIES tab, and there you can click the hyperlinks to see the individual rules within each category. Or you can go to the RULES tab for an interface and select from the enabled categories for that interface and view and manage the individual rules that way.
OK, so under Snort | WAN | Categories, I now see the list of rulesets. Since I already did a forced disable of the rule, I imagine it is no longer checked. So, I'll see if I can go backwards and figure it out. Thanks!
Actually you just disabled a single rule in a large category of similar rules. The CATEGORIES tab shows you the rule categories selected for use. The RULES tab is where you can see the individual rules within each category. Each rule has a unique SID (Signature ID). To see which rule out of the many in the Policy Category you disabled, open that rule set on the RULES tab and scroll the list of SIDs. You will see rules that are default enabled and also rules that are default disabled by the vendor. The SID you force-disabled will show up with a special icon (see the legend at the top of the page, or hover over the State column to see a tooltip pop-up.
Many times a rule category will have default-disabled rules because those rules are very false-positive prone in many networks. The rule authors leave it up to the security admin to enable those rules if they wish (and also to disable "default enabled" rules should they wish or need to). In your case, that rule was what we might call a false positive in your environment so disabling that specific SID is OK.
-
@bmeeks
Ah, I see that now. There is a tab titled WAN Rules. Well, I probably can't figure out what it was, but it should be good now. Thanks! -
@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=:
@bmeeks
Ah, I see that now. There is a tab titled WAN Rules. Well, I probably can't figure out what it was, but it should be good now. Thanks!You can see exactly which Snort rule blocked by going to the ALERTS tab, choosing the WAN interface in the drop-down at the top, and then looking through the list of alerts to find one containing the IP address that was blocked. In your case that was 23.65.34.215. Find that alert in the DST column. If I recall correctly, you can click the DST column header to sort by the data. On the row for that alert it will show you the rule GID (Generator ID) and SID (Signature ID). The GID is usually "1" for most text rules. The SID, as I said earlier, is unique to a specific rule. In the right hand column you can find a summary of the rule's message. From that you can usually guess which category the rule is in, but the SID will uniquely identify the rule.
P.S. -- the above assumes your network traffic is not so high as to cause the alerts log to rollover. In that case, that alert may have rolled into an archived log and no longer be visible using the GUI tools.