Found your digression on checking Firewall for UDP traffic has centered us!
Tracing the problem showed me my firewall rules were wrong on the SonicWall. I had set the firewall rules like an armature; my reasoning before…
- Accept WAN traffic from FQDN addresses (as an address object group) [“trunk1.freepbx.com” & “trunk1.freepbx.com” = this way nothing else besides SIPStations servers are allowed in. I still don’t if this was logical from an experts perspective.
- Set the destination to FreePBX test environment local IP = This way traffic checked by the firewall qualifying with the above will be routed to FreePBX test server
- Source Service (Incoming(SIPStation servers) communicating as UDP - Ports… CHAN_SIP (5060-5061), and PJSIP(5160), and Voice Traffic SIP 10000-20000 meet the qualifications to go past the firewall.
- Destination Port: Any - going to the FreePBX = because the ports from the source act as a entry restrictors (So I think?) so why restrict again?
When It should have been the a tad differenticia allwhile been missing NAT policies to make this work. The firewall rule should have been.
- Source: Any
- Destination: WAN Primary IP
- Source Service: FreePBX VoIP Services [5060-5061,5160,10000-20000] w/UDP timeout (150s).
- Dest Service: Any
The Interpretation I can make from this is this:
Anything from anwhere asking (addr) to WAN_IP - SonicW allows service ports [5060-5061,5160,10000-20000] open - NAT policy routes req to WAN_IP to "FreePBX servers" as original reqested
After this exploration I’ve been able to make outbound calls and hear audio, and from my phone hear the initial FreePBX test audio when I call in.
I used the command you shared to debug CHAN_SIP, the logged events get flooded quick. I think I need to look at it some more to understand it. Saw it contained phonenumbers, sipstation user and password. Maybe I’ll still share it later with questions about what I should pay attention for if and whenever I see another problem come up.