Garbled output - possible character encoding issue

[TheBugiMan]

Thanks for the project. Been using it in my home lab for a little while now and experimenting with its use in my work environment where I have unfortunately found an issue. I have had a search here on GitHub and on Internet in general but haven't found anything similar.

When attempting to access Web GUI for one particular device 'brand', regardless using HTTP or HTTPS on the back end results in 'garbled' output.

Having a look at this made me think it was a character encoding mismatch. So I decided to capture the packets between the device and Warpgate (using HTTP to get 'clear text') and from the packet capture I can see the expected HTML.
In below example, 192.168.0.14 is my lab docker host and 192.168.0.118 is my lab device I am wanting to connect to (FortiGate firewall)

Looking in Docker logs there is no obvious errors or issues. You can see 200 returned for the page (which is presented as garble) and the favicon 404 (which is expected).

I haven't seen this problem in the handful of other systems I have configured before, and appears to be isolated the this brand so far, affecting 3 different that I have tested with. Other thought I had was the body is gziped and Warpgate not handling this correctly but I have other systems/servers that gzip encoded without issue (and given it is widely used), and the returned garble doesn't appear to be valid GZIP data.

I am unsure if there is anything obvious that I have missed here but I have looked at it over two different times/sessions and haven't picked up anything else. I have no experience in Rust, but basic programming and Docker knowledge. So any pointers help or guidance would be appreciated!

[Eugeny]

Could you try downloading the response body as-is (browser devtools -> reload page -> network tab -> find the document request (first) -> copy as curl -> run it and save into file) and feed it to file to see if it gets recognized as some other compression format maybe?

Also please compare the headers returned through Warpgate and when accessing the page directly

[TheBugiMan]

I'm remote from my lab today but I have been able to gather some information.

I've attempted a few different file typing/identifying methods to see if it is 'compressed' or another file type, but everything is returning it a generic binary data, so I don't believe it is a mistyped file/return.

Comparing the headers at the browser you can see that there is a difference in the content-type. Warpgate returns text/html; charset=utf-8 whereas a NGINX reverse proxy I have set up only returns text/html;. Interestingly, this appears to be added by Warpgate as when capturing the same connection attempt behind Warpgate, the response from the device/server does not contain the utf-8 charset.

NGINX browser headers

Warpgate browser headers

Response from device

Of course this doesn't make too much sense why this would be causing some issues, because the webpage itself includes the meta charset of utf-8 unless there is some weird browser or Warpgate interaction (stepping well out of my comfort zone here). But that said, I have this issue on Windows and Mac under Firefox and Chrome (this testing/output from Windows Firefox). I can't recall if I have tested under MacOS Safari but I can confirm same behavior on IOS Safari.

[Eugeny]

Is there a chance you could run tcpdump on the server side to capture the traffic directly between Warpgate and Fortigate?

[TheBugiMan]

The "Response from device" above is a packet capture (loaded into wireshark) captured on the FortiGate, is that sufficient? I came provide that.

I could try and capture on my Docker host but would be trickier as Docker and FortiGate are both VMs on the same physical host, and presumably show the same being direct without anything between them.