Question about firewall checker and stun message transaction id

[KeithTX]

I'm running v15sp6. I'm trying to troubleshoot an issue where 1 or 2 random media ports are failing with the "mapping does not match" during the firewall check, I am also having random inbound audio issues. What I am finding when the firewall check fails and I try to correlate the missmatched packet there are multiple packets with the same transaction id. In a specific example where the firewall checker shows that port 10680 is mapped to 10682. I have 4 packets with the same transaction id. The first packet is the bind request for 10682, the second is the bind request for 10680, then I have to bind responses for port 10682, all with the same transaction id. While it's easy to surmise that one of the bind responses was for the port 10680 bind request but it's not conclusive, shouldn't they have separate transaction ids? Or am I not understanding something?

Background info: I am using a watchguard firewall, I have had watchguard support verify the setup is correct. Since the one way audio calls are so random we have not been able to capture one. I am trying to use the firewall checker capture to convince them there is actually a problem.

Thanks
Keith

Capture for the 4 packets

Frame 6041: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: Watchgua_dd:5c:cf (00:90:7f:dd:5c:cf), Dst: JuniperN_78:c7:c0 (00:24:dc:78:c7:c0)
Internet Protocol Version 4, Src: xx.xx.xx.xx, Dst: 158.69.11.6
User Datagram Protocol, Src Port: 10682, Dst Port: 3478
Simple Traversal of UDP Through NAT
[Response In: 6057]
Message Type: Binding Request (0x0001)
Message Length: 0x0008
Message Transaction ID: 3343586e74312e3047f0ab42c3950fe5
Attributes
Attribute: CHANGE-REQUEST
Attribute Type: CHANGE-REQUEST (0x0003)
Attribute Length: 4
.... .... .... .0.. = Change IP: Not set
.... .... .... ..0. = Change Port: Not set]


Frame 6042: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: Watchgua_dd:5c:cf (00:90:7f:dd:5c:cf), Dst: JuniperN_78:c7:c0 (00:24:dc:78:c7:c0)
Internet Protocol Version 4, Src: xx.xx.xx.xx, Dst: 158.69.11.6
User Datagram Protocol, Src Port: 10680, Dst Port: 3478
Simple Traversal of UDP Through NAT
Message Type: Binding Request (0x0001)
Message Length: 0x0008
Message Transaction ID: 3343586e74312e3047f0ab42c3950fe5
Attributes
Attribute: CHANGE-REQUEST
Attribute Type: CHANGE-REQUEST (0x0003)
Attribute Length: 4
.... .... .... .0.. = Change IP: Not set
.... .... .... ..0. = Change Port: Not set

Frame 6056: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Ethernet II, Src: JuniperN_78:c7:c0 (00:24:dc:78:c7:c0), Dst: Watchgua_dd:5c:cf (00:90:7f:dd:5c:cf)
Internet Protocol Version 4, Src: 158.69.11.6, Dst: xx.xx.xx.xx
User Datagram Protocol, Src Port: 3478, Dst Port: 10682
Simple Traversal of UDP Through NAT
[Request In: 6041]
[Time: 0.047082000 seconds]
Message Type: Binding Response (0x0101)
Message Length: 0x0044
Message Transaction ID: 3343586e74312e3047f0ab42c3950fe5
Attributes
Attribute: MAPPED-ADDRESS
Attribute Type: MAPPED-ADDRESS (0x0001)
Attribute Length: 8
Protocol Family: IPv4 (0x0001)
Port: 10682
IP: xx.xx.xx.xx
Attribute: SOURCE-ADDRESS
Attribute: CHANGED-ADDRESS
Attribute: SERVER

Frame 6057: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Ethernet II, Src: JuniperN_78:c7:c0 (00:24:dc:78:c7:c0), Dst: Watchgua_dd:5c:cf (00:90:7f:dd:5c:cf)
Internet Protocol Version 4, Src: 158.69.11.6, Dst: xx.xx.xx.xx
User Datagram Protocol, Src Port: 3478, Dst Port: 10682
Simple Traversal of UDP Through NAT
[Request In: 6041]
[Time: 0.047327000 seconds]
Message Type: Binding Response (0x0101)
Message Length: 0x0044
Message Transaction ID: 3343586e74312e3047f0ab42c3950fe5
Attributes
Attribute: MAPPED-ADDRESS
Attribute Type: MAPPED-ADDRESS (0x0001)
Attribute Length: 8
Protocol Family: IPv4 (0x0001)
Port: 10682
IP: xx.xx.xx.xx
Attribute: SOURCE-ADDRESS
Attribute: CHANGED-ADDRESS
Attribute: SERVER

 

[KeithTX]

I should have mentioned, the packet capture is from the firewall though the capture from the 3cx server has the same results.

 

[Marari]

Just out of curiosity, have you disabled SIP ALG in the Watchguard firewall?

https://www.watchguard.com/help/doc...S/Fireware/proxies/sip/sip_proxy_about_c.html

 

[KeithTX]

It's off by default, you have to specifically setup a SIP proxy policy to enable it.

 

[YiannisH_3CX]

Please note that we have identified an issue with the firewall checker in V16 which can falsely fail a few RTP ports in certain scenarios. If you are only failing a few RTP ports with the "mapping does not match"
message then i would recommend ignoring them for now until the issue has been resolved.

 

[KeithTX]

I knew about the issue with v16, I am running v15. However, in working with Watchguard yesterday we were able to confirm that the firewall was not remapping the port which points to an issue with the firewall checker in v15 as well.

 

[NickD_3CX]

Same issues exist in V15 also from a certain service onward. We are aware of it, but thanks for reporting it!

 

[KeithTX]

Thanks for the update

 

[NickD_3CX]

This is also being discussed here: https://www.3cx.com/community/threads/random-port-mapping-does-not-match-v16.64573/