The server works for clients on the LAN, but when a client on the Internet tries, I can see on my router’s firewall that they send SIP packets over TCP, and they are being NATed to the server, but the client gets 408 timeout error. Where can I find logs that explain why the server does not respond to register?
The full log (/var/log/asterisk/full, but I believe there is also GUI access to this), with verbosity set (I think that is default for FreePBX), and with the relevant protocol option for your channel driver set, using the appropriate CLI command, a couple of possible ones are:
pjsip set logger on
sip set debug on
The security log, I believe, also includes IP addresses.
Never mind it was hiding in the plain sight. But no dice: no IP addresses in freepbx-security log either. Only my own failed attempts to log into the UCP earlier today as I was setting it up. It almost feels like something between my router and freePBX is not passing the packet that are NATed.
The security log is /var/log/asterisk/security. It might not be accessible from the GUI, as it is input to fail2ban. In any case, the full log, with protocol debugging turned on is usually the best source of information for this sort of problem.
You can also use sngrep, or tcpdump (bash command line) to capture input before the Linux firewall.
If the protocol logging doesn’t show any incoming traffic, it isn’t reaching Asterisk.
I wouldn’t bother chasing it. I only mentioned it because it might technically meet the requirement in the headline. The full log is the place to look on Asterisk. If it is getting blocked by a firewall, it won’t appear on the security log, either.
In sngrep, I can see register or invite if I try to call, but the client still says response timeout.
Asterisk does not answer, unlike it answers to the client on my LAN.
If you are seeing INVITE from local callers in both sngrep, and the full log, but seeing remotely sourced ones only in sngrep, and the destination port number is correct, you have an Asterisk firewall problem.
I might have, don’t know anymore after the self-destruction of the box during this morning’s activation/upgrade.
Ended up rebuilding the box from scratch, and this time calls from the Internet over UDP worked immediately, as expected. No idea what had been wrong, but your theory about TCP is plausible. just have no way of confirming it anymore.