I’m still new to IPFire and have been stumbling around to get things working. I struggled with port forwarding but I seem to have it working now (kinda).
On port forwarding I can manage to get one port from red to open an internal IP on green. This is working for my Home Assistant. At first this only worked when using my actual external IP Address but now it works with my DuckDNS url too. I also managed to get it working on SSL for Home Assistant.
This is not the case for other SSL DuckDNS URLs. I also have Vaultwarden (selfhosted Bitwarden). It worked perfectly before but now gives me the " SSL_ERROR_RX_RECORD_TOO_LONG" or “ERR_SSL_PROTOCOL_ERROR”.
My Let’s Encrypt certificate is valid. I used Nginx (NPM) to set this up and to get the certificate. The strange part is that it works with the External IP but not with the DuckDNS Url and port. I read somewhere that someone using Adgaurd uses CNAME in the DNS for these DDNS URL’s but I have no idea on how to do that in IPFire.
Here is some more information on my setup:
I have IPFire connected to my FTTP modem. It also does the PPPoE connection. IPFire than connects to my TP-Link X60 (Access Point Mode). This is for my Mesh network. IPFire does the DHCP. The DNS is setup to use Quad9 TLS.
Currently Rule 1-6 works as expected. My network knowledge is lacking so any help would be appreciated.
Update:
I have removed my NPM as it was giving errors. I replaced it with a new docker image and received a new Certificate. I cleared my browser cache and tried again. Firefox, chrome and Brave all still give the error. I even moved to DynU just incase it was an issue with DuckDNS.
Hi @manbearpig73, I supose you would like the firewall closed from outside and open to outgoing rules! portforwarding and NAT rules are very dangerouses, here you are alowing free traffic trough those always open ports! If I were you I would want a port forwarding to some DNS server proxies in the case of using an internal server DNS caching for queries, block the firewall and open it to outgoing requests.The thing here is this type of configuration you also have to alow ICPM trafficc for a minimum good conection between networks, wich is happening with Policy Alowwed, but wont happen with firewall blocking, that way having to open outgoing firewall rules (not portforwarding). See the picture below:
THe ICMP requests you’ll need to alow is echo request and replie and network unreachable, as well some ICMP for times. in services if you order ICMP you’ll get to wich ones acept. Meanwhile I’m stil working in some other rules, but to start with this is ok Now you’ll want the red to reach DDNS’s I supose in outgoing firewall rules. If you ping the hosted the reverse IP number I would try to use them to alow traffic from red to them.
Regards
G70P
Thank you for your reply. I have to honest, everything you said went right over my head. Is there any way you can dumb it down for me? I have a basic understanding of networking an honestly never head of ICMP for you wrote about it. After looking it up I now know it’s primary purpose is for error reporting.
No worries, ICMP is for network administrative tasks and can be exploited. Allow the only ones needed for conections and reject excessive or not necessary ones. they have to work in and out ecxept for the echo replie. I think ICMP were the ever first made rules for network connection in net history!
G70P
By the way if DDNS’s you are using uses the 443 or 80 they are already open/filtered in picture above, other way, the 53 port instead of the servers pointed in the picture and blanked out should be changed with your DDNS’s IP’s
Don’t forget, turn suricata (IPS) on for both zones and whitelist for suricata the Internal network (or IP’s)of your working (PC) devices.
The way I see ipfire is: firewall policy - general firewall policies. Incoming firewall policies:administrative. Outgoing firewall - distribuition/filtered to zones (red , blue, orange, green, black)
General Policy (Firewall) - Block/Drop Incoming, Alow outgoing.
Incoming Traffic to firewall - just needed to access webGui (Defenitly block the RED here, no chances of internal or private external IP’s leaving or getting here)
Outgoing the Firewall (blocked by definition in group) - allowing only: ICMP for administrative conections (Green and Red); common ports for surfing in RED 123, 53, 443 (what ever you need, generaly UDP or large block are used for DNS’s and time 123 depends); The outgoing the ipfire firewall to Green (at the moment just the ICMP packets)
I’m not using the advanced webproxie but I think it works on port 800, thus having to adapt.
@manbearpig73
I tried to understand your matter and to follow connections.
Some connections work, other 7 – 8 not…
For this what you claim I suggest some idea to check:
The time and NTP of all your machines
Certificates for connections, over DDNS and for rerouted direct connections too
Set IPs
Domain name setting and resolve
The ports allowed by the DDNS service
The ports allowed/needed by the application
Furthermore test bypass connection at proxy, add those IPs to unrestricted.
Note: For two-way communications/connections you need internal and external same ports (no rerouting).
I never mentioned this before but I’m using Nginx (NPM) on the vaultwarden server to forward the traffic on port 8080 to the docker container for vaultwarden. I believe this is where the problem lies. This worked perfectly before I started using IPFire. Now when I stop the NPM container and do a wget I still get the same “Unable to establish SSL connection.” error. I would expect to get a connection error.
Can anyone help with this. Somehow the reverse proxy is not doing what it should do.
I installed this entire setup onto a different server with the same error.
Could it be that IPFire does not accept the reply received from the reverse proxy?
it’s worth noting that SSL is now considered insecure and outdated, and TLS has replaced it as the standard for secure connections. Therefore, it is recommended to use TLS instead of SSL for security reasons. TLS versions are indicated by numbers, like TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, etc.
If you encounter a system that still mentions SSL but doesn’t mention TLS support or only supports outdated versions of TLS, it might indicate a security concern, and you should proceed with caution.
I’m a little off my foot here. As there might be some internal setup blocking SSL insecure or maliciose connections?!?
Nginx is not limited to handling only SSL connections. Nginx is a versatile web server and proxy server that can handle both HTTP and HTTPS (SSL/TLS) connections.
When it comes to SSL connections (HTTPS), Nginx can act as a secure web server by serving content over HTTPS using SSL/TLS encryption. This is a common use case for Nginx, where it helps secure data transmission between clients (such as web browsers) and the web server.
Regards
If you have been following this thread, then I am happy to report that I did eventually figure it out.
My previous system was to have a Let’s Encrypt SSL certificate for each of my DuckDNS external URL’s. This was making a lot of extra work for me to renew these every 3 months and with IPFire it was not necessary. I installed Nginx on IPFire and acme.sh. Acme.sh renewed all my certificates without me having to change router rules for port 80 from one server to the next. Once I had all my certificates I setup Nginx Reverse Proxy for each server as an “upstream”.
Once I removed any proxies on the actual servers and let the IPFire Nginx handle it my issue was solved.
