Alert dialog shows NetBIOS internet traffic when using a browser

[kekukui]

This is Firefox connecting to GitHub - it happens with other sites too https://bgpview.io/ip/185.199.109.154

Windows - insecure by default? https://www.speedguide.net/port.php?port=137

Strange how Windows file sharing works over the internet when you did not even want it - but does not work properly over the freaking LAN 😆

(...and that is with the firewall disabled!)

---

Here I keep pressing "Allow" but the alert is never dismissed, I just had to quit the program...

And now the browser has stopped responding so I had to open a new tab & re-create this GitHub issue...

I also hear Mozart's piano sonata # 16 ... 🎹 🎶

[hoasis2]

Windows - insecure by default?

This is not a WFN specific problem.

Here I keep pressing "Allow" but the alert is never dismissed, I just had to quit the program...

You should have clicked at least 2 more times. See "Attempts: 2"

And now the browser has stopped responding so I had to open a new tab & re-create this GitHub issue...

Don't use nightlies on productive systems. You ought to use first v2.0-beta3, which is almost stable.

[hoasis2]

This is Firefox connecting to GitHub - it happens with other sites too https://bgpview.io/ip/185.199.109.154

BTW look at the screenshot: "Application path:" is "System", not Firefox.

Probably your Synology Assistant client is trying to access your public IP address,

[harrwiss]

Hi @kekukui, it's difficult to judge from the information what happened and why port 137 tries to connect to the internet (seems it got redirected). The GitHub IP refers it seems to a CDN (Content Delivery Network), that is hosted by GitHub. The port 137 redirection is probably the reason why dsassisten.exe didn't work and the windows firewall blocked it.

For clarification some points (which you may know already 😄 ):

• WFN Notifier does not actively block anything - it's only showing the user, that the windows firewall has blocked a connection and provides the possibility to create a rule in the firewall.
• Check the security log in WFN Console to see the history of connection attempts (uncheck TCP only to see UDP as well)
• Check in the Rules page for what rules where created by WFN Notifier (drop-down box).
• If the Allow button is pressed multiple times with the same rule setttings it may create multiple rules in the firewall (still something not working perfectly there i.e. we should remove the notifications which do not apply anymore after a Allow/Block action).
• If the rule settings are the same, then just use "Skip program" or "Skip all" to see whether notifications come up again next time.

[harrwiss]

@hoasis2 - thanks for your comments.

[wokhan]

Hi @harrwiss,

If the Allow button is pressed multiple times with the same rule setttings it may create multiple rules in the firewall (still something not working perfectly there i.e. we should remove the notifications which do not apply anymore after a Allow/Block action).

You cannot be more right. I'm pretty sure I implemented this back in the days but obviously I didn't or it's broken somehow... I'll create an issue regarding this for WFN2.1 as it's pretty important for our users.

[harrwiss]

Think we can close this issue now as there is no futher info.

[harrwiss]

btw: This is my most annoying "test" app generating lots of requests - left it running for the day. Figure somebody trying to click through that number of attempts 🤔