Managed firewall
Choose which traffic reaches your public address.
Define the source, service and target you intend to expose. Inbound permission and outgoing routing remain separate choices.
Explore Public IP traffic modes ↗01 / One deliberate allowance
Start with the service you mean to expose.
Allow HTTPS to this target from these clients. The assignment’s managed firewall carries that intended exposure. An empty managed rule list blocks inbound by default; fully open mode requires a separate, explicit choice.
The source and service match the intended rule.
- Approved client rangeDocumentation example: 198.51.100.0/24→Incoming TCP 443
- Assigned public IPAllow TCP 443 from that range→Permitted request
- Your web serviceListener + host firewall + login
The rule permits network reachability. It does not authenticate the person or approve the application’s data access.
This illustrates one isolated allow rule. It does not define rule precedence or certify live enforcement; verify the serving gateway and endpoint.
The service port is right. The source is not.
- Different client rangeOutside the intended allowance→Incoming TCP 443
- Managed firewallNo matching permission×Blocked
- Your serviceRequest blocked in this example
A narrow source allowance can limit exposure when the clients have predictable source addresses.
If a client is behind NAT or an exit, evaluate the source address visible to the service boundary. An allowlisted address is not a replacement for user authentication.
Opening HTTPS does not open administration.
- Internet clientRequests TCP 22→Incoming TCP 22
- Managed firewallNo SSH permission×Blocked
- Administration serviceNot exposed by the HTTPS rule
With managed mode and no matching inbound allowance, the unrelated service remains closed in this model.
An empty managed rule list means blocked inbound. Fully open mode is a separate, explicit choice; it does not remove the application or host firewall responsibilities.
Permission is one part of reachability.
The rule controls network access. The target still needs a listening service, a permitting host firewall and application login. A reachable port can still lead to an insecure, misconfigured or unavailable application.
02 / Read the rule
Who, which service, and where.
Describe the required connection before adding an allowance. Keep the public assignment, the approved audience and the service precise.
- 01 / SourceWho can start a connection?
- An assessed client address or range. For clients behind NAT or an exit, consider the source visible at the service boundary.
- 02 / Protocol & serviceWhat traffic is needed?
- Choose the protocol and, where applicable, its service ports. TCP 443 permits HTTPS traffic in the example; it does not open TCP 22.
- 03 / TargetWhich assignment is exposed?
- A device or gateway public allocation. For a gateway, separately approve the mapping to the intended LAN host and service.
Scroll sideways to inspect all rule fields. Focus the table to scroll with the keyboard.
| Field | What it means | Example or limit |
|---|---|---|
| Target | The public assignment being controlled | Device or gateway allocation |
| Protocol | The traffic type | Current rule contract includes TCP, UDP and ICMP |
| Port | Service port for a port-based protocol | TCP 443; ICMP does not use TCP/UDP ports |
| Source | Where incoming traffic may originate | An assessed source range or an explicitly broad audience |
| Action and enabled state | The intended rule behaviour | Allow or block; a disabled rule is not an active allowance |
Rule processing, gateway forwarding and local enforcement
The schema records intent. Exact rule validation, precedence and enforcement must be verified for the serving implementation; this page does not invent an ordered rule-processing contract. Fully open mode is a separate explicit choice, not the managed default.
A device’s own firewall, the gateway’s forwarding configuration and the target listener still matter. A gateway may forward distinct approved public ports to different LAN servers. Opening a public port does not automatically create that mapping or start the service.
03 / Direction matters
Exposure, replies and outgoing routes are separate.
Choosing how traffic leaves a device does not decide who can connect to its public address.
Incoming permission
Inbound policy decides which remote clients may start a connection. Selected outbound and full tunnel do not automatically deny incoming traffic. An outbound-only configuration needs explicit inbound denial.
Connection replies
A permitted incoming connection needs the correct return path through Fibmesh. Confirm the gateway and host routing as well as the inbound allowance.
Unrelated outgoing traffic
In an inbound-access configuration, unrelated outgoing traffic can stay on the existing ISP path. Selected outbound routes eligible destinations through the assigned public source; full tunnel routes eligible internet traffic through Fibmesh.
An assignment firewall is not automatically a Publish login policy, private-network group membership or an Outbound profile control. Publish maps a hostname to a selected HTTP application through its own gateway boundary.
Compare Public IPs traffic modes →04 / Routed infrastructure
A routed range needs its own exposure plan.
Routed Subnets is a separate invitation-led Public IPs managed service with assisted prefix setup. The app does not provide self-service prefix provisioning. Delivering a prefix to your gateway does not make every downstream address or service safe to expose.
Place the filtering.
Agree which gateway and downstream host firewalls control the routed range, which addresses and services are permitted, and who owns changes.
Confirm each address family.
Assess IPv4 and IPv6 service configuration separately. Single-address assignment rules do not establish equivalent filtering across a routed prefix.
Routed-prefix filtering and IPv6 control traffic
Do not infer a released per-prefix firewall editor, automatic rule propagation to every host or identical enforcement to a single-address assignment. Confirm the service configuration for IPv4 and IPv6 separately. For IPv6, account for the control traffic required by the deployed network; a blanket “block all ICMP” policy can break normal operation.
05 / Apply & observe
Test the allowance. Test its limits.
A saved rule or successful API response is not proof that gateway and endpoint enforcement have converged.
- 01 / Prepare
Identify the owner and path.
Record the source, protocol, target and return route. Confirm application authentication and updates. Review broad source ranges as an intentional choice.
- 02 / Compare
Inspect observed configuration.
Compare requested and observed generations and configuration for the serving gateway and endpoint. Investigate unapplied or differing state.
- 03 / Connect
Try the approved source.
Test the intended service from an allowed client. Check the application connection and its replies, as well as the network permission.
- 04 / Challenge
Try the access you did not allow.
Test an unapproved source and an unrelated port. Confirm actual enforcement at the serving boundary; the diagram is only an illustration.
Close the exposure when the service retires.
Remove the allowance and verify that the service is no longer reachable through it.
Pausing a Public IP preserves its reservation but removes delivery after the change is applied. Releasing it gives up the allocation. Both actions affect more than an individual port rule.
Firewall questions
Keep the boundaries clear.
Network rules limit reachability. Application security and deployment responsibilities remain with the systems they protect.
Can I open any port I want?
The intended service allows deliberate control of supported protocol and port rules. Confirm the deployment’s accepted rule syntax, operational restrictions and service terms. “Fully open” does not bypass platform constraints or the target’s own firewall.
Does an allowlisted source make application login unnecessary?
No. Several users may share a NAT or exit address, and a permitted device can be compromised. Use appropriate application authentication and permissions.
Will the firewall inspect web attacks or stop every attack?
No such claim is made. Network rules limit reachability; they do not establish a web application firewall, malware inspection or a DDoS protection service.
Review security across the whole connection.
See the wider security responsibilities →