|
The Zultys PBX IP system is a VoIP-based private branch exchange used for business communications.
It provides features such as call processing, voicemail, auto-attendant, and unified communications.
It operates over IP networks using SIP and related VoIP protocols.
Topology:
Follow the steps mentioned below to resolve the issue:
Step 1: Verify firewall configuration:
The following firewall configuration elements should be reviewed on both the spoke and hub firewalls:
-
Routing tables should include correct routes for:
-
Client subnets.
-
PBX server subnet.
-
IPsec tunnel interfaces.
-
Firewall policies should be validated using policy lookup to confirm:
-
Correct source and destination addresses.
-
Required PBX service ports are allowed.
-
Traffic is matched against the expected policy.
-
NAT should be reviewed and disabled for VPN traffic where required.
Step 2: Verify IPsec tunnel configuration:
IPsec configuration should be reviewed on all relevant firewalls:
-
Phase 1 parameters should be verified, including:
-
Phase 2 selectors should be confirmed to include:
-
Tunnel status should be validated to confirm that traffic is flowing through the correct tunnel.
Step 3: Validate NPU offloading settings:
-
Hardware offloading (NPU) settings should be reviewed for IPsec and firewall policies.
-
In some scenarios, offloading may interfere with traffic inspection or packet visibility.
-
NPU offloading may be temporarily disabled for testing purposes to determine the impact on PBX traffic.
Step 4: Analyze TCP session behavior:
-
Packet capture should be performed on the spoke firewall where the client is located.
-
The TCP three-way handshake should be confirmed.
-
If TCP FIN packets are observed immediately after handshake completion, session termination by the client should be suspected.
Step 5: Evaluate the impact of deep packet inspection:
-
Security profiles applied to the firewall policy should be reviewed.
-
Deep SSL/SSH inspection (deep packet inspection) may introduce additional latency.
-
PBX applications are sensitive to latency and timing.
-
As a result, the client may terminate the session due to inspection-related delays even though the network path is functional.
Step 6: Bypass security profiles for isolation:
-
A temporary firewall policy without security profiles should be used for testing.
-
If connectivity is restored, the issue is likely related to one or more inspection profiles.
Step 7: Adjust SSL inspection for PBX traffic:
The SSL/SSH inspection configuration applied to the firewall policy should be reviewed when PBX application traffic is involved. If deep inspection is not strictly required by security or compliance requirements, certificate inspection may be considered as a preferred alternative, as it allows encrypted traffic to pass with reduced processing overhead. This approach can help minimize latency and avoid potential disruptions to PBX application sessions while still maintaining basic certificate validation.
Step 8: Validate application connectivity:
-
Stable TCP sessions without immediate FIN packets should be confirmed.
-
PBX registration and signaling should function normally.
-
Packet capture should be repeated to confirm sustained sessions.
PBX applications may terminate sessions due to latency introduced by deep packet inspection. Deep SSL inspection can delay encrypted traffic processing, leading to timeout or protocol handling issues on latency-sensitive applications such as PBX systems.
|
