Mblock V5.3.0 network bug with proxy

#1

Hello,
with a connection using proxy i can’t add extension or devices with mblock V5.3.0
i’m a teacher and all the PC in the classroom use a proxy. it’s impossible to add extension or device all the time “network bug”
when i use my portable computer i can use 2 wifi connection.
when i use the wifi connection with proxy, i can’t add extension or devices
when i use the wifi connection without proxy, i can add extension or devices.

someone have the same bug ?
thanks a lot

#2

Hi karlTH,

We are behind a Fortigate and I have never had this problem. I had problems updating extensions in the LOCAL version, which worked intermittently but in the end I managed to update after a few tries. Now I am using mLink 2 and the online version on the Internet.

  1. You should inquire about which Proxy solution do you have
  2. You should look at the Windows Firewall (if you are on Windows);
  3. You should look at the level of Anti-Virus (if you have one).

We temporarily disable one service at the same time: Anti-Virus and Firewall and we test. Of course, you will have to do it with IT.

Good luck

#3

thanks, i will try again

#4

Hello,

We also want to use Mblock v5.4.0 Windows on Win10 behind http proxy.

Proxy is properly set in Windows as displayed by command “netsh.exe winhttp show proxy”
Proxy is also set in the GUI Win10 proxy config app

The thing is that Mblock ignores the Windows proxy settings and keeps on trying direct http connections on ports 80 and 443 (instead of connecting to proxy port as defined).

Ower organisation forbids non proxy http connections (i.e. direct tcp/443 or tcp/80 connections): those are not allowed and blocked by firewall policies.

As a result downloading additionnel mblock objects fails.

Some connections do pass through proxy though:

TCP_MISS/200 CONNECT extservice.mblock.cc:443
TCP_MISS/200 CONNECT mblock-expanded.oss-cn-shenzhen.aliyuncs.com:443

but not all of them:

IP 10.0.2.124.50352 > 47.246.49.207.443
IP 10.0.2.124.50352 > 47.246.49.207.443
IP 10.0.2.124.50339 > 8.129.90.57.443

Solution: make Mblock for Windows handle system proxy settings properly

Workaround: make mblock objects available online so that you can download them using a web browser an then import them in mblock localy afterwards

Thanks for you help.

#5

We suggested users to switch to the web version which is working just fine trhrough the web browser for most of them.

Nevertheless some users still complain the web version is not as convenient for education use case. For instance you have to register in order to save your data, which is not quiet appropriate dealing with different courses and students. For them, the best way to go remains to fix the proxy issue in the PC version I guess.

#6

Hi Sebastian,

It is always possible to save your projects offline BUT the local version has a big advantage: It is not dependent on the Makeblock servers which had to be restarted a few times.

In conclusion: It’s always more reassuring to be able to count on a local compilation because the problem always happens at the wrong time…

I understand you…

To correct the problem, is it really a problem with the Proxy or is there another protocol that Makeblock uses. My question for Makeblock: Does the web version only use HTTPS (443)???

#7

Hi Crackel,

Thank you for your interest on this topic.

I will inform users about the offline backup possibility.

Firewall tracing shows direct mblock outbound tcp/443 connections. Since this is not allowed, these are blocked and I guess this is part of the issue faced by PC version users who cannot download extra objects into the library.

On the same PC (ie. behind the same firewall), using the web version with a browser configurerd to use proxy, downloading new objects into the library works just fine. Since everything seemed to worked as expected this way I did not checked if mblock web version did try to use another protocol beside https. Anyway I am pretty sure it does not because of the current firewall policy which filter unexpected protocols and ports.

So my guess is that the PC version would work nicely if the app could send https through proxy as configured in Windows (WinINET library) instead of send direct https bypassing local proxy config.

#8

Hi Sebastian,

I have already gone through this problem at my job BUT the use of Makeblock was not justified in the context of my work (It was to relax for lunch). However, there was the problem that you speak with the extensions. Some passed and others didn’t, it was a bit random BUT in my opinion, nothing to do with the PROXY. On our side, we use FORTIGATE as Firewall, I could probably analyze the traffic a little (easily) and watch what does not pass BUT I have progressed in the company and the Fortigate is no longer in my responsibilities. You should ask the network administrator to look at your traffic when you update an extension, it should indicate the protocol or the reason. Probably he can create a rule to correct the situation. I could probably have helped you easily but the administrator at the office is overwhelmed…