Cloudflare Tunnel vs Port Forwarding: Which to Use

For cloudflare tunnel vs port forwarding, start with the application: Tunnel suits browser-based services behind CGNAT; port forwarding suits services needing direct inbound connections. The goal is remote access without exposing the rest of your LAN. Cloudflare Tunnel uses an outbound connector, so your router needs no inbound mapping for the application.

Related: Cloudflare Tunnel Error 1033: 7 Fixes in Order.

Cloudflare Tunnel vs Port Forwarding at a glance

Port forwarding rewrites an incoming packet’s destination, such as WAN TCP 443 to a local HTTPS server. It supplies reachability; the application still needs authentication.

Property	Cloudflare Tunnel	Port forwarding
Connection direction	Connector initiates outbound	Remote client initiates inbound
Public IPv4 at home	Unnecessary	Usually required for direct IPv4 access
Client compatibility	Browser for HTTP; published TCP needs client software	Native TCP/UDP clients
NAT, IPS-on, VPN throughput	No universal rating; measure the complete path	Depends on router, inspection, encryption, and WAN
PoE budget; 1G/2.5G/10G/SFP+ ports	Determined by LAN hardware	Determined by LAN hardware
Software cost	Free Tunnel; Access has free and paid plans	Router feature; ISP public-address charges may apply
Update cadence	Schedule connector updates	Follow router and application releases

The protocol matrix explains client requirements. Cloudflare documents free Tunnel availability separately from Access pricing. Follow its connector update procedure; a restart can interrupt sessions.

Where it wins / where it loses

Tunnel wins behind CGNAT. An ISP-facing address in 100.64.0.0/10 uses the shared space defined by RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space. Your router’s port forward cannot configure the ISP’s upstream NAT. Dynamic DNS tracks an address; it does not create inbound reachability.

Tunnel alone does not make a dashboard private. Create an Access application before publishing its hostname, allow specific identities, and validate Access tokens through cloudflared or the origin. Without Access, the published application is Internet-accessible, subject to its own authentication. Cloudflare’s setup guide explicitly warns about this.

Direct forwarding wins on protocol compatibility and control. A published Tunnel TCP route transports TCP over WebSockets and requires client-side cloudflared; it is not a generic public UDP listener. For private network access, evaluate Cloudflare One Client routing or a VPN. That recommendation follows Cloudflare’s documented protocol limitations.

For published HTTPS, Cloudflare terminates browser TLS. Treat it as a trusted HTTP intermediary; encrypting the connector-to-origin leg does not remove that trust. Direct HTTPS forwarding can terminate TLS on your own reverse proxy. See the edge/origin certificate model.

Tunnel adds dependencies on Cloudflare and cloudflared. Neither design removes your upload bottleneck. For media servers, check the Tunnel FAQ: public hostname routes carry video and large-file service restrictions; private network routes are treated differently.

Topology

Illustrative wiring: Netgate 6100 LAN → USW-Pro-24-PoE port 1; port 2 → application host; port 3 → U6-Enterprise.

Use native VLAN 10 and tagged VLANs 20/30 on the router trunk. Port 2 is an access port, PVID 30. Port 3 uses native VLAN 10 for AP management and the untagged Trusted SSID, plus tagged VLAN 20 for IoT. These are proposed assignments; UniFi documents native and tagged port behavior.

Run cloudflared beside the application on 10.30.0.10, mapping app.example.com to http://127.0.0.1:8080. Loopback HTTP assumes the same host network namespace. A separate origin host should use certificate-validated HTTPS.

VLAN plan

Example addressing; DHCP pools show final-octet ranges. Infrastructure uses addresses outside those pools.

VLAN ID	Name	CIDR	DHCP range	Gateway IP	Inter-VLAN policy
10	Trusted	10.10.0.0/24	.100–.199	10.10.0.1	Deny; admin exception below
20	IoT	10.20.0.0/24	.100–.199	10.20.0.1	Deny all
30	Services	10.30.0.0/24	.100–.149	10.30.0.1	Deny all

Firewall rules

Keep established-state handling and DHCPv4 rules. Apply these new-flow rules on their source VLAN interfaces, in order. LOCAL contains every internal subnet and router address; CF_TUNNEL contains Cloudflare’s documented tunnel destinations.

1. Each VLAN → its gateway, TCP/UDP 53: allow DNS.
2. Admin 10.10.0.10 → 10.30.0.10, TCP 22: allow SSH.
3. Connector 10.30.0.10 → CF_TUNNEL, UDP/TCP 7844: allow QUIC/HTTP2.
4. All VLANs → LOCAL, any protocol: deny/log.
5. All VLANs → other destinations, TCP/UDP 53: deny/log.
6. Trusted → Internet, any protocol: allow.
7. IoT/Services → individually approved vendor/update endpoints, TCP 443; approved time servers, UDP 123: allow.
8. Any remaining source → any destination, any protocol: deny/log.

Populate endpoint allow-lists for your devices. Limit host-firewall SSH access to the admin address. An earlier broad allow shadows isolation rules. Keep UPnP off.

The forwarding alternative needs WAN TCP 443 → 10.30.0.10:443, with a reverse proxy listening there. On pfSense, the accompanying WAN pass rule targets the translated internal address because NAT precedes filtering. Tunnel needs neither inbound rule. Check IPv6 separately: native IPv6 normally needs no NAT, but still needs firewall policy.

DNS and discovery

Use Cloudflare-managed DNS for the published hostname. Keep Access-protected names resolving through Cloudflare internally. For direct forwarding, split DNS can avoid hairpin NAT, provided local access has appropriate authentication.

Use per-VLAN resolver policies: general filtering for Trusted, required vendor domains for IoT, required service/update domains for Services. Blocking external DNS on port 53 alone does not control DNS-over-HTTPS.

Keep Bonjour/mDNS reflection disabled unless discovery is needed; then scope it to selected VLANs and services. IGMP snooping limits multicast flooding; it does not authorize inter-VLAN connections.

What you actually need

Choose Tunnel plus Access for household dashboards. Choose controlled direct forwarding for public native-protocol services. For private NAS administration, prefer a VPN or private client routing. Keep patching either design; sister publication Tech Sentinel covers broader cybersecurity developments.

Things to test before you call it done

On the connector host, verify DNS and the local application; substitute your hostname:

dig @10.30.0.1 app.example.com A
curl -I http://127.0.0.1:8080

From IoT, these should fail; confirm firewall deny logs:

ping -c 4 10.30.0.10
nc -vz -w 3 10.30.0.10 22

For a LAN baseline, temporarily allow only a Trusted test client’s TCP 5201 to a Trusted test server. Use iperf3, then remove that host-firewall allowance:

# Server 10.10.0.20
iperf3 -s -1
# Trusted test client
iperf3 -c 10.10.0.20 -t 10

From outside your LAN:

mtr -T -P 443 -rw -c 10 app.example.com
curl -I https://app.example.com

For Tunnel, expect an Access challenge without credentials. Verify an authorized browser succeeds, an unauthorized identity is denied, and direct origin access fails over both address families where configured. mtr reaches the Cloudflare edge, not the origin; LAN iperf3 does not benchmark Tunnel. Restart the connector and confirm recovery. These are proposed checks, not reported measurements.