IPv4, IPv6 and firewalls: review the paths into your server
A service can be reachable through more than one address family and more than one network layer. Restricting an IPv4 port does not prove that the same service is restricted through IPv6. Build the review around the paths that actually exist, including DNS, listeners, host rules and any upstream controls.
The practical takeaway
Inventory both address families, expose only intended services, preserve the control traffic the network needs, and test access from outside the server after every relevant change.
Start with services and addresses, not a rule list
List each public-facing service, the transport it uses, its listening port and the audience that should reach it. A web application, an administrative interface and a database usually need different exposure. Record the addresses actually assigned to the server and the interfaces on which each process listens. A process bound to a loopback address has a different intended boundary from one listening on every available interface.
Include IPv4 and IPv6 in the same inventory, while keeping their addresses and policy handling distinct. Public DNS can direct visitors to IPv4 through an A record and to IPv6 through an AAAA record. The presence or absence of one record does not replace checking the service itself. Someone who already knows an address may reach it without using the hostname you expected them to use.
HM Bastion describes IPv6 allocation as dependent on address-pool availability. Confirm the allocation and configuration for the actual service before planning around it. Additional IPv4 options are separate from the number of application ports exposed: another address is not a firewall or a substitute for application authentication. Keep network requirements in the order or support brief rather than assuming that a particular address arrangement follows from a range name.
Follow policy through every layer that handles traffic
A connection may pass through provider network controls, a host firewall, a container network, a reverse proxy and the application’s own access checks. Document which layers exist in your deployment and who manages each one. Two useful controls can complement each other, but they can also make a failure hard to locate when their rules are not recorded. A host configuration should not depend on an upstream restriction that has never been confirmed.
| Layer | Question to answer | Useful test |
|---|---|---|
| DNS and public addresses | Which destinations can clients discover or already know? | Inspect the intended A and AAAA answers |
| Listening process | Which addresses and transports accept connections? | Check the service configuration and active listeners |
| Network and host policy | Which sources can reach each service? | Test permitted and denied paths externally |
| Application | Who can perform an action after connecting? | Check authentication and authorisation with test accounts |
When using a firewall manager, confirm how it handles both IP families in the installed configuration. Read the documentation for the tool and distribution rather than assuming identical defaults everywhere. Container platforms can add their own networking and filtering rules, so a published container port deserves an explicit review. Do not use the apparent state of one familiar command as proof of the complete path into the workload.
Prefer a small policy that matches the inventory. Public web traffic may be intended from many sources, while administrative access can have a narrower source policy where practical. Databases and internal management endpoints often do not need direct public access at all. Keep a recovery access path while changing rules, and verify a second permitted session before closing the only working administrative connection.
Avoid breaking the network while trying to reduce exposure
IPv6 relies on ICMPv6 for functions beyond a simple echo test. A blanket rule that drops all ICMPv6 can disrupt necessary network behaviour, including discovery and error handling relevant to packet delivery. The IETF’s filtering guidance distinguishes message types and the roles of different boundaries. Use the guidance appropriate to the environment rather than copying an unexplained rule set that treats every control message as hostile.
A network that appears to work for a small request can still fail for other traffic sizes or paths. Test real application exchanges, not only whether one port opens. Compare behaviour from networks that support the intended address family, and retain the exact time and destination when diagnosing a problem. A failed IPv6 test from a client with no usable IPv6 path says little about the server’s application configuration.
DDoS mitigation and service exposure also solve different problems. Mitigation can reduce attack traffic, while a firewall policy defines permitted network reachability at its boundary. Neither replaces secure application accounts, updates or careful handling of secrets. An exposed administrative panel can be a risk even when its bandwidth consumption is tiny. Review what an authorised connection is allowed to do after reaching the service.
Test the intended boundary and retain a rollback path
- Record the current rules, intended policy and recovery access method.
- Apply a narrow change during a suitable maintenance window.
- Test allowed and denied connections for each relevant address family.
- Verify the normal website and required internal dependencies.
- Record the final policy and remove temporary diagnostic exceptions.
For example, after moving an administration interface behind restricted access, verify that an approved operator can still connect and that an ordinary external path cannot. Repeat that check for every assigned public family the interface listens on. Make these tests only against systems you operate or have permission to test. The objective is to verify a defined boundary, not to generate broad scans against unrelated addresses.
Return to the inventory after publishing a new application, enabling IPv6, adding a container platform or changing proxies. These changes can introduce a new listener without altering the old rule list in an obvious way. A short record linking service, address, port, owner and permitted audience makes future reviews faster and reduces reliance on whoever last edited the firewall.
