Protonmail bridge requires both port 80 and 443 not filtered, and so does the web service. If you have blocked the traffic from your green network to the red interface in order to go only trough the proxy, Protonmail doesn’t like that. I never found a good alternative solution to opening a direct access to the web.
Green to Red is allow all, except bad countries (which I also temporarily switched off and it didn’t make a difference).
By proxy I meant a 3rd party proxy I am running on my client, which switches the original destination IP of the e.g. Proton Webmail server to the proxy destination IP and uses HTTP Connect. This happens before the traffic gets to the IPFire and seems to make a difference. Hence my initial thought that something in the IPFire engine drops traffic to the original Proton service IPs (and this doesn’t happen when requests to Proton are transported “behind” a request to Proxy IP).
Still I need to find what / why are the non-proxy requests to Proton not getting through. Will look more into that and post here when I find anything.
I use both proton VPN and protonmail bridge as well as the web based access, and by leaving open port 80 and 443 I have 0 problems. I do not have suricata and I only use spamhouse drop in the firewall options. I do not use externals web proxy, only squid in IPFire, but as I said, I leave port 443 and 80 open for my laptop when I am either in the green network or VPN connected to my home network.
I have a rule that blocks the outbound traffic on the web ports in blue, green and VPN networks so that only packets addressed to the firewall (the squid-based IPFire proxy) can pass through. However, with another rule I need to open a direct access for my laptop so that I can use proton services. If I leave everything open by default, everything works without any special intervention from my part.
You should look carefully at the logs to see why you are having this problem. The way I deal with this kind of problems is to open a console access to IPFire, open the system log with tail -f /var/log/messages, connect to proton mail and see what happens to the logs, in real time. contrl-c to exit.
I also encounter this error. @chimpanzeejade Did you figure out what the issue was? In my case, the only thing dropped that was to protonmail-connected IP addresses are some DROP_CTINVALID and DROP_NEWNOTSYN packets. The weird thing is that tail -f /var/log/messages while attempting to curl -v http://mail.proton.me yields no packet drop errors, making this very hard to debug, indeed. If the firewall was dropping these packets, a packet drop log entry would consistently appear, right?
Nothing is filtered through URL filtering or proxy filtering. The only firewall rules are related to port forwarding 443, 80, 22 to a homelab server I have.
Doing the following yields the same result: curl -v 185.70.42.37, so not a DNS issue. I even went as far as to reinstall IPFire, setting up a red+green+orange network. Doing the previous command from orange also yields the same result. Connecting directly to the modem with my laptop, thus circumventing IPFire, allows connecting to ProtonMail.
Do I understand correctly that curl from IPFire machine works and the problem happens only from behind the firewall?
this would suggest that the syn packets starts from behind the firewall but somehow they are not kept in account by the kernel. This would explain the firewall receiving SYNACK packets that would trigger DROP_NEWNOTSYN and consequently the DROP_CTINVALID (connection absent in the conntrack table). However I cannot think why this happens. Also I never had this issue with protonmail.
Does this happens only with proton mail? Is there anything in your firewall that could lead to this event? Are you using suricata? Location block? Spamhaus drop in firewall options?
Alternative hypothesis, could this happen because your modem is not in bridge mode (potentially a double NAT could explain this anomaly) ? Assuming that you have an ADSL, If you cannot setup your modem in bridge mode, you should put IPFire IP address in the DMZ zone of the modem and possibly also write a static rule sending all the traffic to the DMZ of the modem.
can you drop this rule (port 443) for few minutes and check if the DROP_NEWSYN goes away when you connect from the laptop?