Cannot Access Website Externally Using Cloudflare w/ Hestia DNS

[Psyringe]

Can't access my website externally.



Map:

- WEBSERVER (HESTIA control panel on Ubuntu 24.04.1)
to
- NETWORK SWITCH (Netgear R7000)
to
- OPNSENSE (4 Core AMD)
to
- XFINITY ROUTER (Default)



Issue:

- WEBSERVER (HESTIA) is hosting a DNS NAMESERVER.
- CLOUDFLARE is pointing to the DNS NAMESERVER.
- WEBSERVER is timing out externally.



With exception of these changes, OPNSENSE is default;

- SERVICES: UNBOUND DNS: OVERRIDES
-- HOST OVERRIDE(s) (Allows access to the WEBSERVER internally.)

- SYSTEM: SETTINGS: ADMINISTRATION
-- TCP port: (Changed)
-- HTTP Redirect: Checked

- FIREWALL: NAT: PORT FORWARD
-- Setup w/ NAT Reflection.



Other settings:

- HESTIA
-- Default port changed to be functional with CLOUDFLARE.

- XFINITY
-- Correct ports have been opened and are confirmed using online resources.



Used many combinations of settings with multiple deployments of OPNSENSE.

If the solution is found will post it in the thread, however hoping someone else can link or otherwise list the correct settings for external access to the WEBSERVER.

[bartjsmit]

Have you looked at cloudflared on Ubuntu? https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/

[Psyringe]

Was made aware of "Cloudflare Zero Trust" and briefly looked over the services; they didn't meet the financial "wants" of the deployment.

Similar services include https://serveo.net/ (free), https://telebit.cloud/ (free)... even https://localtonet.com/ or https://packetriot.com/ (free to a single GB of traffic).

Anyone viewing this can have a party on https://github.com/anderspitman/awesome-tunneling - hope it helps.



@bartjsmit In short... no, not yet. Not a Linux Server guru so the documentation needs to be clear.

Likely to test a tunnel this evening, but need to clone the server incase something goes wrong.

[bartjsmit]

'Raid Owl' Brent has a good walkthrough: https://youtu.be/hrwoKO7LMzk

[Psyringe]

Unfortunately being trolled by the dragons this morning.

Users attempting the Cloudflared Tunnel should also look at this page. (Port Forwards) | https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/deploy-tunnels/tunnel-with-firewall/

The individual in the tutorial skipped the Port Forwards; 7844 & 443.
The dragons win this round because it appears Xfinity wont allow access to 7844, 443... or 80 in this case.

Still running tests.



Cloudflare Zero Trust is Free with Credit Card.

Made a clerical mistake while examining the first time, thinking "Users" meant "Traffic" ie. "50 active connections".

[bartjsmit]

TBH if you have more than 50 concurrent connections, you may want to look at a VPS.

Oracle has a generous free tier; quad ARM core with 24GB RAM. https://www.youtube.com/watch?v=zWeFD4NNF5o

[Psyringe]

These are fantastic solutions, however opted into a new modem not directly managed by the ISP; or as OPNsense has logged, likely third party interference. #therebedragons



Solution:

- Purchase New Modem
-- Ensure new modem is only a modem, leaving Port/Firewall options to OPNsense.



Would like to recap the best solution to this issue, located here:
https://forum.opnsense.org/index.php?topic=6155.0

If users have:
- WEBSERVER
to
- NETWORK SWITCH
to
- OPNSENSE
to
- MODEM

To make this webserver publicly available:
1. Access
FIREWALL: NAT: PORT FORWARD

2. Add (+)

3. Change Rules
- Interface: WAN NETWORK
- TCP/IP Version: IPV4
- Protocol: (Conditional)
- Destination: WAN NETWORK address
- Destination port range: (Conditional)
- Redirect target IP: Single host or Network
-- IP of WEBSERVER
- Redirect target port: (Conditional; should update with Destination port range)
- Log: Check
- NAT reflection: Enable
- Filter rule association: Add associated filter rule (Rule)
- Save

4. Apply



Was able to tinker with,
- Services: Unbound DNS: (Overrides/Query Forwarding/DNS over TLS)
however found they provided no real solution compared to the settings listed above.

In addition to this, can only access my WEBSERVER externally, not internally.

Alternative solutions include:
- Using a TUNNEL PROVIDER with a compatible port.
- Using a CLOUD SERVER with NGINX setup as a REVERSE PROXY SERVER.
- Using a CLOUD SERVER with frp setup as a REVERSE PROXY SERVER.

Open to alternative ways of performing this action, however consider the issue resolved.

Thanks for your time, @bartjsmit.