New FreePbx Distro installation:
FreePbx 12
Asterisk 13
CentOs 6.6
Having trouble understanding the source or significance of the the following log message (/var/log/asterisk/fail2ban):
[2015-03-09 15:30:15] WARNING[21603] chan_sip.c: Retransmission timeout reached on transmission 8892276f2fd24c184057c2f005be45e0 for seqno 1 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 31999ms with no response
The referenced web page does not provide meaningful help.
The transmission ID is always different, but the seqno is always 1. Time out is always 31999ms. Frequency is variable - once every one to three minutes under very light (or zero) call volume.
Would appreciate any insights on the cause and how to fix.
That was probably in /var/log/asterisk/full not the fail2ban log, it is probably the result of of fail2ban “banning” an IP address and the host no longer being able to reply.
and the underlying bogus subscription from the rogue IP should be revealed (about 32 seconds before 2015-03-09 15:30:15 )
Generally it means that fail2ban is doing it’s stuff in a timely fashion , but if you are getting them every few minutes then you might want to look into properly tightening up your firewall to only allow necessary SIP connections from known/trusted hosts/networks.
Re tightening up the firewall, the obvious thing to do is add a rule to allow SIP connections from only my provider. But Iptables uses plain ip addresses, not domain names, so that seems a bit fragile. Is there a better way to ‘tighten up’?
FWIW, the message appears in both logs, but the activity 32 seconds earlier appears only in the full log.
The “network” can be identified from the CIDR and/or derived from the netrange depending on the location i.e. RIPE for Europe ARIN for the US etc., if there are more than one, then use the smallest one. This is quite useful in identifying many home networks as they will often use DHCP and always award IP’s from a very limited range . . .
It is not infallible but you rarely see an attack vector from a Comcast or TW address, if you are unlucky enough to use OVH/Amazon etc. then not so much as that is where the Palestinians hangout. . . .
)