Prusa Connect from behind corporate firewall  

RE: Prusa Connect from behind corporate firewall

Hello

It's hard to guess without more specific info, but my experience with various „tight corporate firewalls“ might suggest they are using a MITM proxy ‒ that is, capturing all the trafic, presenting their own certificate (which isn't trusted from the point of the printer and therefore refused as TLS error). Currently, it's not yet possible to set a custom server certificate as trusted, but if the security team can confirm the above theory and cooperate, we could set the printer to communicate without encryption to the corporate firewall-proxy thing and let it encrypt it on the outer side. Or it could be possible to place a proxy that would turn unencrypted printer communication to encrypted but accept the firewall's certificate.

If anything of that is acceptable to the security team, we can provide guidance on how to set up the printer for that.

RE: Prusa Connect from behind corporate firewall

Another solution that could be acceptable by the security team (maybe?) is to put the printer into a completely separate untrusted „Guest network“ ‒ give the printer access to the outside Internet, but no access at all between the printer and the corporate network. That would mean PrusaLink would stop working, but it could then access the Connect servers.

RE:

You probably need two things:
- allow printer to get NTP servers from  DHCP or allow it to connect to the NTP server it tries to connect (I guess this is a time server in Czech) - this is required for the printer to get a proper time, which is required for TLS stack working
- if you have a corporate firewall then it probably is trying to decrypt TLS, do packet inspection and connect to the upstream servers over the internet if allowed. The problem is that to make it work your computer/printer have to have certificates from your company CA - while for the computers it is preinstalled with the system/web-browses, the problem is that your printer lacks those files - it would require to install custom firmware on it with the certificates (and this usually means that you loose warranty.

So to solve this the best option is to place 3D printer in the dedicated VLAN with restricted access:
- for the printer for the outgoing NTP protocol
- allow connections to the prusa endpoints only (which may be tricky if prusa hosts it on dynamic IP address pools and corpo firewall would not support dynamic domian resolutions). Optionally maybe prusa printer could use HTTPS proxy then you can add HTTPS proxy for the printer and control where it can connect for example with httpd in forward proxy config or squid or equvalent
- optionally connecting from specific other vlans/computers into the prusa printer directly

You can also try to set `TLS = false` in the printer config (but it's just my guess) or pass other options to allow untrusted certificates. Or maybe there are other options that can be specified?
I believe the best option would be to contact Prusa for support anyway.

RE: Prusa Connect from behind corporate firewall

(to clarify above post because editing time expired):
- you would need HTTPS proxy with CONNECT option enabled, though I am not sure if prusa printers supports it anyway
- looks like `buddy-a.connect.prusa3d.com` uses prusa certs anyway, which are not in publicly available CA chain, so even if you used TLS decryption via corpo network then the corpor proxy would have to allow to connect to TLS with unknown certs - maybe prusa could provide CA chain for that so it could be imported to the proxy server, but still I bet security team would really not be eager to do that.

Do you really need remote control for the printer using official prusa software? Cant' you use direct LAN connection instead, without going through the internet and to rely on third party app availability?

RE:

Hi, just to clarify. Michal Vaner is the person that made PrusaLink and Prusa Connect support for the xBuddy platform, it's just that we are discouraged from using our own forum, and people usually don't even apply for a moderator / staff badge, so it's a wee bit confusing. I personally love direct contact with the community, adding a chain of people to play telephone with these requests drives me nuts, but then also, this takes valuable time from what I should be doing. Soo, yea I get why those exist.

RE: Prusa Connect from behind corporate firewall

I'll add to the posts. `tls = False` and pointing to the local proxy would be the one thing that would work.

Using a modified firmware and embedding a different CA than our own would work, but this is a bit tricky. As the printer resources are very limited, it won't be able to use arbitrary certificate ‒ due to memory restraints, we had to avoid RSA and are using elliptic curves in the cert. The library also doesn't allow for some extensions for the certificates. Combination of these is the only reason why we don't use a public CA here.

The buddy-a.connect.prusa3d.com is just an alias domain for connect.prusa3d.com with that custom certificate. Everything should work (not tested) if you do the encryption outside of the printer and send the traffic to connect.prusa3d.com, which has a publicly-trusted cert.

The printer should be able to keep its time without access to NTP across reboots (it has RTC with a battery, just like normal PC), so if it was connected once, it should keep working regarding time.

RE: Prusa Connect from behind corporate firewall

Thanks everyone for the help. I was able to get a temporary SSL exclusion to test, which allowed everything to work, but I've been informed that this won't be a long-term solution. I think given the difficulty of getting this to work (combined with the lack of several key features that OctoPrint still has) I'm going to slap a Raspberry Pi on it and deal with the current shortcomings of that approach. I'll likely have to do the same for the XL I have on order.

Thanks again, and good luck to anyone else behind a serious firewall.

RE: Prusa Connect from behind corporate firewall

Sorry it cannot work out. Good luck to you too 🙂

RE: Prusa Connect from behind corporate firewall

I've configured my Prusa Mini+ with Prusa Connect in such way that printer connects to the host with nginx which works as a proxy.

More details at https://github.com/nvtkaszpir/3d-print/pull/1

RE:

I've created two directories for the proxy with different suffixes and thus different modes:
- *-debug - writes logs to directory with body dump - useful for more in-depth info what is sent and received
- *-stdout - writes basic logs to stdout, this is normal operation mode for proxying if you want to run proxy 24/7.

https://github.com/nvtkaszpir/3d-print/tree/main/prusa-connect-proxy

RE:

I did some tests and pointed my Prusa Mini+ with v5.1.2 to nginx as upstream proxy, so that printer does http requests to nginx and it forwards them to https on connect.prusa3d.com

so far so good, but I cannot get file upload from the Prusa Connect, this effectively ends in getting a command to fetch a file but it ends in getting some generic response from the upstream (html page and not the actual file).
I'mm attaching example log. process.zip

I cannot even get the contets via curl if using the same headers and calling the connect.prusa3d.com site...
I guess I'm missing certain headers or what?
What needs to be done to allow downloading files from printer via proxy?

RE: Prusa Connect from behind corporate firewall

oh god it works, changed upstream to buddy-a.connect.prusa3d.com 😀