Network and Firewall Requirements

Firewalld Handling

The AppViewX installer explicitly validates that firewalld is NOT active on any cluster node.

To disable firewalld on all cluster nodes:

sudo systemctl stop firewalld
sudo systemctl disable firewalld
# Verify:
systemctl is-active firewalld

Why Host-Level Firewall Management and Kubernetes Networking Must Be Coordinated

Linux host firewalls such as firewalld and Kubernetes networking components both interact with the same Linux kernel networking framework (netfilter/iptables or nftables). Because they operate on the same packet-processing infrastructure, host firewall configuration can directly impact Kubernetes networking behavior.

Kubernetes dynamically manages networking rules through components such as:

  • kube-proxy - Maintains service routing and forwarding rules for Kubernetes

Services, including ClusterIP and NodePort traffic

  • Calico Felix - Manages Calico networking, routing, and Kubernetes

Network Policy enforcement These components continuously create and update networking rules on the host.

Operational Considerations When Using Firewalld with Kubernetes

Running firewalld alongside Kubernetes is supported in some environments, but it requires careful planning and validation. Incorrect or incomplete firewall configuration may lead to networking disruptions within the cluster.

Potential impacts include:

  • Service Routing Interruptions

    Firewall reloads or policy changes can temporarily affect Kubernetes-managed networking rules until Kubernetes components reconcile and restore the required state. During this period, services such as ClusterIP, NodePort, or DNS resolution may become temporarily unavailable.

  • Pod-to-Pod Communication Issues

    Kubernetes networking commonly requires packet forwarding between interfaces and nodes. Restrictive firewall forwarding policies may block pod-to-pod or service communication if not properly configured.

  • Kubernetes Port Accessibility

    Critical Kubernetes and networking ports must be explicitly allowed when host firewalling is enabled. Depending on the cluster architecture and networking implementation, commonly required ports may include:
    • 6443 - Kubernetes API Server
    • 2379-2380 - etcd
    • 10250 - kubelet API
    • 179 - Calico BGP (when BGP mode is used)
    Note: Additional ports may also be required depending on the CNI, ingress controller, service mesh, or load balancer configuration.
  • Continuous Rule Management

    Kubernetes components and firewall services may both update host networking rules dynamically. Without proper coordination and testing, firewall policies can unintentionally interfere with Kubernetes networking behavior.

    As documented by Tigera for Calico deployments:

    “If your Linux distribution comes with installed firewalld or another iptables manager it should be disabled. These may interfere with rules added by Calico and result in unexpected behavior.”

Note:

If organizational or compliance requirements mandate the use of firewalld, ensure that all required Kubernetes and networking ports are allowed before cluster installation.

  • All required Kubernetes and networking ports are allowed before cluster installation.
  • Firewall policies are validated during cluster deployment and upgrades.
  • Firewall reload procedures are tested to confirm they do not disrupt cluster networking.

Required Firewall Ports

S/No Port Protocol Direction Purpose
1 22 TCP All ↔ All SSH for installation, administration, and prerequisite checks.
2 179 TCP All ↔ All BGP communication for Calico CNI routing between nodes.
3 6443 TCP All ↔ All Kubernetes API server communication. Also required between the load balancer and master nodes.
4 10250 TCP All ↔ All Kubelet agent REST endpoints for the Kubernetes API Server.
5 31443 TCP LB → Worker AppViewX Web UI access. Must be open in single-node deployments.
6 2379 TCP All → Master ETCD client communication.
7 2380 TCP Master ↔ Master ETCD peer communication (multi-master only).
8 4789 UDP All ↔ All VXLAN in Calico is an overlay networking mechanism that encapsulates pod traffic using UDP packets to enable seamless pod-to-pod communication across different nodes and network segments without requiring underlying network routing changes.
9 9100 TCP All ↔ All Node health exporter (optional - required only if an external metrics stack is enabled separately).
10 30022 TCP Client → Worker SCEP auto-enrollment protocol endpoint.
11 30021 TCP Client → Worker EST auto-enrollment protocol endpoint.
12 Protocol 4 IP-in-IP All ↔ All IPIP (IP-in-IP) in Calico is a tunneling mechanism used to enable pod-to- pod communication across different nodes or subnets by encapsulating network traffic inside IP packets.
Note:
  • Each node requires exactly 1 IP address.
  • Port 22 is required between all nodes for SSH-based deployment.
  • An external TCP load balancer is recommended to distribute traffic across master nodes.
  • Ensure external endpoints accessed by AppViewX worker nodes (For example, ADC devices, Microsoft CA) are accessible on their respective ports.

External Integration Ports

Source Destination Protocol Purpose
AppViewX Worker Nodes ADC Devices SSH SSH-based device management.
AppViewX Worker Nodes ADC Devices HTTPS REST API device management.
AppViewX Worker Nodes MSCA Agent HTTPS AppViewX to Microsoft CA agent communication.
AppViewX Worker Nodes CA / PKI Systems HTTPS Certificate authority REST API.