USG FLEX 200H – Inbound UDP/5060 (SIP) not forwarded by Virtual Server NAT rule

baba

1. ENVIRONMENT

Device: Zyxel USG FLEX 200H
Firmware: V1.39(ABWV.0)
WAN interface: vlan7_PPPoE (PPPoE, dynamic public IP, referred to as <WAN-IP>)
LAN interface: vlan10 (internal network 10.10.10.0/24)
Internal server: 10.10.10.10 (Asterisk PBX, listening on UDP 5060)
Remote peer: Deutsche Telekom SIP servers, 217.0.0.0/13 (e.g. 217.0.147.69)

1. SUMMARY

Inbound SIP packets (UDP, destination port 5060) arrive on the WAN interface
but are NEVER forwarded to the internal host, even though a matching and
enabled Virtual Server (NAT) rule and an allow Security Policy exist.

The packets are silently discarded: no NAT translation occurs, nothing is
forwarded to the LAN interface, and no drop entry appears in the Security
Policy log.

Outbound SIP works normally (registration and keep-alives succeed).
This worked correctly before a firmware update, so we consider this a
regression.

1. EXPECTED BEHAVIOUR

Inbound UDP packets to <WAN-IP>:5060 should be translated by the Virtual
Server rule and forwarded to 10.10.10.10:5060.

1. ACTUAL BEHAVIOUR

The packets arrive on the WAN interface and then disappear inside the device.
They are not translated, not forwarded, and not logged as dropped.

1. EVIDENCE – SIMULTANEOUS PACKET CAPTURE (device's own capture tool)

Capture taken on BOTH interfaces at the same time, filter: port 5060.

WAN (vlan7_PPPoE):
21:04:57.219 <WAN-IP>:5060 > 217.0.147.69:5060 SIP: OPTIONS
21:04:57.249 217.0.147.69:5060 > <WAN-IP>:5060 SIP: 200 OK
21:05:04.066 217.0.147.69:5060 > <WAN-IP>:5060 SIP: INVITE sip:0561...@...
21:05:04.528 217.0.147.69:5060 > <WAN-IP>:5060 SIP: INVITE (retransmit)
21:05:05.527 217.0.147.69:5060 > <WAN-IP>:5060 SIP: INVITE (retransmit)
21:05:07.530 217.0.147.69:5060 > <WAN-IP>:5060 SIP: INVITE (retransmit)
21:05:11.537 217.0.147.69:5060 > <WAN-IP>:5060 SIP: INVITE (retransmit)

LAN (vlan10) – same time window:
21:04:57.219 10.10.10.10:5060 > 217.0.147.69:5060 SIP: OPTIONS
21:04:57.249 217.0.147.69:5060 > 10.10.10.10:5060 SIP: 200 OK
... NO INVITE packet at all ...

=> The INVITE arrives on WAN, is retransmitted 5 times by the remote side
(because it is never answered), and never appears on the LAN interface.

1. KEY OBSERVATION

Note the timestamps above: only ~7 seconds BEFORE the INVITE, an
OPTIONS / 200 OK exchange with the EXACT SAME 5-tuple
(217.0.147.69:5060 <-> <WAN-IP>:5060, UDP) passes through the device
in both directions without any problem.

The inbound INVITE uses the identical source IP, source port, destination IP
and destination port as that working exchange – yet it is dropped.

This indicates a problem in the device's NAT / UDP session handling for
inbound packets, not a configuration issue.

1. CONFIGURATION IN PLACE

NAT rule (Network > NAT):
Name: Asterisk-SIP-in
Status: enabled
Classification: Virtual Server
Incoming interface: vlan7_PPPoE (WAN)
Source IP: tested with 217.0.0.0/13 AND with "any"
External IP: any
Internal IP: 10.10.10.10
Port mapping: Port / UDP / external 5060 -> internal 5060

Security Policy (Security Policy > Policy Control):
Enabled, Action: allow
From: any To: any (Excluding ZyWALL)
Source: 217.0.0.0/13 Destination: 10.10.10.10 Service: any

1. TROUBLESHOOTING ALREADY PERFORMED

• NAT rule verified (see above); also tested with Source IP = "any"
• Security Policy created explicitly to allow the traffic
• SIP ALG / "SIP Pinhole": tested BOTH enabled and disabled
• "Restrict Peer to Peer Media/Signaling Connection": tested both on and off
• Checked the "SIP Signaling Port 5060" entry
• Verified via packet capture that the traffic really reaches the WAN interface
• Verified via packet capture that it never reaches the LAN interface
• Checked the Security Policy log: unrelated scanners hitting <WAN-IP>:5060
  ARE logged as "Match default rule DROP", but the traffic from 217.0.0.0/13
  produces NO log entry at all (neither allow nor drop)
• Internal host is reachable and works; outbound SIP registration to the same
  remote peer works continuously

1. QUESTIONS / REQUEST

1. Why is an inbound UDP packet that matches an enabled Virtual Server rule
   neither translated, nor forwarded, nor logged as dropped?
2. Is this a known issue in the current firmware for inbound SIP/UDP 5060?
3. Is there a workaround, or a firmware version in which this is fixed?
4. We can provide the original .cap files from the device's own packet
   capture tool (WAN and LAN, captured simultaneously) on request.

Thank you very much for your support.

Best baba

Zyxel_Melen

Hi @baba

Let me share you the weekly firmware first since it fixes some VoIP issue. Additionally, could you share the details about your SIP scenario/application/topology? These will allow us to check if the scenario is supported. Thanks.

Alex_91

Hi, I have same problem.

we are currently experiencing what looks like a very similar issue on another USG FLEX 200H.

Our topology is slightly different:

Cloud PBX (Yeastar P-Series / 185.127.x.x)→ Internet→ upstream router/NAT→ USG FLEX 200H WAN: 172.16.5.150→ LAN/VLAN: 10.20.8.0/24→ Yealink T43U phones

Everything worked correctly with the previous USG FLEX 100. The problem started after replacing it with the FLEX 200H.

The Yealink phones register correctly to the cloud PBX and outbound SIP traffic works, but intermittently some extensions become unavailable/offline on the PBX.

What is particularly interesting is that we can clearly see inbound UDP packets from the PBX reaching the FLEX 200H WAN interface on the NAT ports associated with the phones, for example:

185.127.x.x → 172.16.5.150:2152 UDP185.127.x.x → 172.16.5.150:2112 UDP

However, the FLEX 200H classifies these packets as traffic from WAN to ZYWALL instead of associating them with the existing NAT/session toward the internal phone, and drops them with:

We can see repeated packets from the PBX being dropped on the same ports, while the phone itself may still show as registered.

We have already tested significantly increasing both UDP Timeout and UDP Timeout Stream (up to 900/1200 seconds), without solving the issue. The Yealink phones are also configured with a 30-second keep-alive.

So although our scenario does not use a static Virtual Server rule like the original report, the symptom looks very similar: inbound SIP/UDP reaches the FLEX 200H WAN interface, but the firewall does not associate/translate it toward the LAN endpoint as expected.

This did not occur with the FLEX 100 using the same phones and PBX.

@Zyxel_Melen , you mentioned a weekly firmware that fixes some VoIP issues. Could you please confirm whether that firmware may also address UDP/NAT session handling in this scenario? We would be very interested in testing it.

We can also provide logs and simultaneous WAN/LAN packet captures if needed.

Only the first device using port 5060 (SIP) works correctly; for the others, the IP address is not translated.

Thanks.

Zyxel_Melen

Hi @Alex_91

I checked the fixed list of the weekly. There's no UDP/NAT session handling issue, but fixed Yealink registration issue, which should be your main issue. Please help to try the weekly firmware I sent in private message.

Alex_91

Perfect now working.

baba

Hello,

thank you very much @Zyxel_Melen i couldn't test the weekly firmware, I will test it
and report later.

Below are the details of our SIP scenario, application and topology.

TOPOLOGY

Deutsche Telekom (SIP provider)
SBCs in 217.0.0.0/13
|
| Internet
|
+-----------------------------+
| Zyxel USG FLEX 200H |
| WAN: vlan7_PPPoE | PPPoE, dynamic public IP (<WAN-IP>)
| LAN: vlan10 10.10.10.0/24 |
+-----------------------------+
|
| vlan10
|
+-----------------------------+
| Asterisk PBX |
| Linux server, 10.10.10.10 |
+-----------------------------+

That is the complete relevant path: Telekom <-> USG FLEX 200H <-> Asterisk.
There is exactly one hop between the firewall and the PBX.

SIP APPLICATION

PBX software: Asterisk 20.11.0, SIP stack: PJSIP
Deployment: Docker container running in HOST network mode,
so there is no container NAT. Asterisk binds directly
to the host interface 10.10.10.10:5060 (UDP).
Role: SIP User Agent / client (no SIP server published to WAN)
SIP provider: Deutsche Telekom (consumer line, "MagentaZuhause")
Registrar/Proxy: tel.t-online.de
Provider SBCs: 217.0.0.0/13 (e.g. 217.0.147.69, 217.0.148.5, 217.0.146.198)
Numbers: 10 phone numbers (MSN), each with its own outbound REGISTER
Transport: UDP
SIP signalling: port 5060 (source and destination port 5060)
RTP media: UDP 10000-10099

TRAFFIC FLOWS

Outbound, works:
Asterisk sends REGISTER to Telekom every ~8 minutes, OPTIONS keep-alives
every few seconds, and INVITE for outgoing calls. All of this passes the
firewall and is answered by the provider with 200 OK. Outgoing calls work
reliably.

Inbound, does not work (this is the reported problem):
On an incoming call the provider sends an INVITE from its SBC
(e.g. 217.0.147.69:5060) to <WAN-IP>:5060. The packet arrives on the WAN
interface but never reaches 10.10.10.10. It is neither NAT-translated, nor
forwarded to the LAN interface, nor logged as dropped. The provider
retransmits the INVITE five times, then gives up, and the caller hears
"number not available".

HOW INBOUND IS SUPPOSED TO REACH THE PBX

The PBX is a registered SIP client behind NAT, so the provider sends
inbound INVITEs to the public IP and port of the existing registration
binding, which is <WAN-IP>:5060.

Additionally configured, to be safe:

NAT rule (Virtual Server): WAN vlan7_PPPoE, UDP, external port 5060
mapped to internal 10.10.10.10:5060. Tested with source 217.0.0.0/13
and also with source "any".

Security Policy: allow, source 217.0.0.0/13, destination 10.10.10.10.

SIP ALG / "SIP Pinhole": tested both enabled and disabled.

None of these made the inbound INVITE reach the LAN.

KEY OBSERVATION (device's own packet capture, both interfaces at once)

Filter: port 5060

WAN 21:04:57 <WAN-IP>:5060 > 217.0.147.69:5060 OPTIONS
WAN 21:04:57 217.0.147.69:5060 > <WAN-IP>:5060 200 OK <- passes
WAN 21:05:04 217.0.147.69:5060 > <WAN-IP>:5060 INVITE <- dropped
WAN 21:05:04..11 INVITE x4 (retransmits)

LAN 21:04:57 10.10.10.10:5060 > 217.0.147.69:5060 OPTIONS
LAN 21:04:57 217.0.147.69:5060 > 10.10.10.10:5060 200 OK
LAN ... (no INVITE at all)

The OPTIONS / 200 OK exchange uses the exact same 5-tuple
(217.0.147.69:5060 <-> <WAN-IP>:5060, UDP) and passes in both directions
only about 7 seconds before the INVITE that is silently discarded.

ADDITIONAL INFO

Inbound calls worked before the firmware update on this device. The
Asterisk configuration was not changed at that time.

The original .cap files (WAN and LAN, captured simultaneously) are
available on request.

Please let me know if you need any further details.

Best regards