SIP Trunk Down. Wireshark Shows ICMP Communication Administratively Filtered

Home » Asterisk Users » SIP Trunk Down. Wireshark Shows ICMP Communication Administratively Filtered
Asterisk Users 1 Comment

Hello,

I’ve got a remote system that is plagued with a strange issue.

It happens from time to time. Yet, I’ve not found any condition that trigger this phenomenon.

Here is my setup:

– PSTN <---> ITSP <--SIP trunk--> Router <----> Switch <----> Asterisk box

|

|
SIP
Phones

– Asterisk box is a Raspi/Rasbian with Asterisk 1.8.13
– Switch is DLink DGS-1210-10P
– Router is Zyxel box (I don’t manage it)

I see (with Asterisk console) that Asterisk is sending OPTIONS/REGISTER
requests.

With tcpdump and wireshark, I see that :
1. those OPTIONS/REGISTER messages are sent to my ITSP gateway (IP src is Asterisk box, IP dst is ITSP gateway)
2. my router replies (within 30ms) with something Wireshark presents as an ICMP message like this:
ICMP 491 Destination unreachable (Communication administratively filtered) ( (IP src is router box, IP dst is Asterisk box)

While this happens, I can successively ping my ITSP gateway.

Searching the web, I found [1] and [2].

1. Is it common to get an ICMP reply to a SIP message ?
2. Any advice or suggestion ?

[1]
https://ask.wireshark.org/questions/26667/have-packet-capture-somethings-wrong
[2] http://www.tahi.org/sip-ipv6/ua6/doc-1.0/sip-ipv6-tm/icmp/UA-15-2-1.html

Best regards

One thought on - SIP Trunk Down. Wireshark Shows ICMP Communication Administratively Filtered

  • Sounds like a firewall setting to me. If you can ping, then Internet Control Message Protocol (ICMP) packets are allowed, but if SIP traffic is returning the ICMP Type 3 (code 13) response, then your SIP ports are blocked (at least the firewall admin was nice enough to leave the reason code messaging enabled).

    Get in touch with your firewall admin and have them forward TCP/UDP 5060,
    4569, 5036, and UPD 10000:20000 and 2727 to your Asterisk box IP address. Make sure they white-list the traffic they pass, so get the IP adress(es)
    of your ITSP and only have the firewall accept traffic on those ports from that(those) address(es). That’s your first line of defence on toll fraud.

    If the firewall has a VoIP helper function that opens up UDP ports as needed during a session start, that should reduce your attack surface too.

    -Tim