I am not sure this was mentioned before but https://desec.io no longer new registrations for DynDNS.For the German speaking audience I can highly recommend https://ipv64.net/ Many texts on the website are English, but someone not speaking German might have problems understanding everything
Just chiming in here --Thanks very much doing all the work on this How-To, OP, and for keeping it updated, etc.I successfully implemented it in my modest OPNsense instances/networks, before realizing that for small networks where there may never be more than perhaps 1 to 3 people logging in to a given OPNsense instance, in fact it's far more secure to simply shut off all HTTP listening on external network ports, and instead use SSH tunnels / port redirects, i.e. ssh -L 9450:localhost:80 my.opnsense.host to connect directly to the opnSense instance and access the webgui that way. Then it doesn't matter at all whether HTTPS is active as the entire connection takes place inside the highly-secured SSH network connection. With SSL tunnels there is no need for a webgui process to be listening anywhere except localhost:80.It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.
Quote from: johnmcallister on February 22, 2024, 01:35:06 amJust chiming in here --Thanks very much doing all the work on this How-To, OP, and for keeping it updated, etc.I successfully implemented it in my modest OPNsense instances/networks, before realizing that for small networks where there may never be more than perhaps 1 to 3 people logging in to a given OPNsense instance, in fact it's far more secure to simply shut off all HTTP listening on external network ports, and instead use SSH tunnels / port redirects, i.e. ssh -L 9450:localhost:80 my.opnsense.host to connect directly to the opnSense instance and access the webgui that way. Then it doesn't matter at all whether HTTPS is active as the entire connection takes place inside the highly-secured SSH network connection. With SSL tunnels there is no need for a webgui process to be listening anywhere except localhost:80.It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.The main purpose of the tutorial is not to to access the OPN UI, for which your method makes perfect sense, but instead to reverse proxy services that are hosted internally in a LAN.
It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.
Hi all,I'm trying to get my internally hosted services to report the originating client IP when going through a proxy chain starting with Cloudflare then to HAproxy. Currently HAproxy logs shows the local CloudFlare CDN address.Cloudflare is setup to proxy and is Full (Strict) meaning I'm using the Cloudflare origin cert offloaded at HAproxyI've found that cloudflare do collect the Client IP within cf-connecting-iphttps://developers.cloudflare.com/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/And I have found this post that helps someone with pfSense to do what I wanthttps://forum.netgate.com/topic/176777/haproxy-cloudflare-restoring-original-ip/3What I'm not sure about is how (if possible) to get HAproxy to reference the cloudflare IP address list to know what sessions to insert the cf-connecting-ip into x-forwarded-forIdeally this is in the form of some alias or map that dynamically checks https://www.cloudflare.com/ips-v4Thanks for any help with this, also it's not urgent at all and just for my home setup and for fun really.
OPNsense is up-to-date --> OPNsense 24.1.2_1-amd64FreeBSD 13.2-RELEASE-p10OpenSSL 3.0.13Firefox: 121.0 (64-bit), archlinux (doesn't matter, latest update on windows brings up the same issue)DEFAULT in FF: security.ssl.enable_ocsp_stapling = true--> leads to no access on any pages with certs following the tutorial. At least if pages are secured to local access only. I assume, same error for public access.Changing the default in FF to false gives access back.
## Automatically generated configuration.# Do not edit this file manually.#global uid 80 gid 80 chroot /var/haproxy daemon stats socket /var/run/haproxy.socket group proxy mode 775 level admin nbthread 2 hard-stop-after 60s no strict-limits maxconn 10000 tune.ssl.ocsp-update.mindelay 300 tune.ssl.ocsp-update.maxdelay 3600 httpclient.resolvers.prefer ipv4 tune.ssl.default-dh-param 4096 spread-checks 2 tune.bufsize 16384 tune.lua.maxmem 0 log /var/run/log local0 info lua-prepend-path /tmp/haproxy/lua/?.luadefaults log global option redispatch -1 maxconn 5000 timeout client 30s timeout connect 30s timeout server 30s retries 3 default-server init-addr libc,last# autogenerated entries for ACLs# autogenerated entries for config in backends/frontends# autogenerated entries for stats# Frontend: 0_SNI_frontend (listening on 0000:443 0000:80)frontend 0_SNI_frontend bind 0.0.0.0:443 name 0.0.0.0:443 bind 0.0.0.0:80 name 0.0.0.0:80 mode tcp default_backend ssl_backend # logging options# Frontend: 1_HTTP_frontend (listen on 10.1.2.3:80)frontend 1_HTTP_frontend bind 10.1.2.3:80 name 10.1.2.3:80 accept-proxy mode http option http-keep-alive option forwardfor # logging options # ACL: no_ssl_condition acl acl_642ff4b1bd6b30.27652312 ssl_fc # ACTION: http_to_https_rule http-request redirect scheme https code 301 if !acl_642ff4b1bd6b30.27652312# Frontend: 1_HTTPS_frontend (listen on 10.1.2.3:443)frontend 1_HTTPS_frontend http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" bind 10.1.2.3:443 name 10.1.2.3:443 accept-proxy ssl curves secp384r1 strict-sni no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/642ffac3a289a1.74357812.certlist mode http option http-keep-alive option forwardfor # logging options # ACTION: PUBLIC_SUBDOMAINS_rule # NOTE: actions with no ACLs/conditions will always match use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/642ff59e3f1923.99537840.txt)] # Backend (DISABLED): acme_challenge_backend (Added by ACME Client plugin)# Backend: ssl_backend (ssl virtual ip backend)backend ssl_backend # health checking is DISABLED mode tcp balance source # stickiness stick-table type ip size 50k expire 30m stick on src server ssl_server 10.1.2.3 send-proxy-v2 check-send-proxy# Backend: test_backend (test backend pool)backend test_backend # health checking is DISABLED mode http balance source # stickiness stick-table type ip size 50k expire 30m stick on src http-reuse safe server test_server 10.1.1.100:81 # statistics are DISABLEDfrontend prometheus_exporter bind *:8404 mode http http-request use-service prometheus-exporter if { path /metrics }
