FreePBX | Register | Issues | Wiki | Portal | Support

Another RECEIVED INCOMING SIP CONNECTION FROM UNKOWN PEER TO Message

configuration
Tags: #<Tag:0x00007fcd1b7f5478>

(DaRussian) #1

Asterisk 13.19.1 built by mockbuild @ jenkins7 on a x86_64 running Linux
PBX Firmware: 12.7.4-1804-2.sng7

Hello,

I am having issues with a “received incoming sip connection from unknown peer” message when routing a call into my Asterisk server. I just downloaded and installed a FreePBX (latest distro) onto a virtual machine.

Have researched and can’t seem to figure out the issue – I am a bit new to Asterisk configuration.

Below is a working configuration:

GATE ASTERISK – connects to my upstream SIP Providers and connects to internal ASTERISK servers.

Outgoing Settings

Trunk Name: MY_TRUNK

username=GATE2_LINK

type=friend

secret=<secret>

qualify=yes

insecure=very

host=voip4.<domain.tld> … this is the domain pointing to the internal Asterisk Server

dtmfmode=auto

context=from-internal

trustrpid=yes

Incoming Settings

Blank

VOIP Server – internal and sits “behind” the Gate Asterisk Server

Outgoing Settings

Trunk Name: GATE2_LINK

username=MY_TRUNK

type=friend

secret=<secret>

qualify=yes

insecure=very

host=gate2.<domain.tld> … this is the domain pointing to the gate server (upstream)

dtmfmode=auto

context=from-trunk

Incoming Settings

Blank

The Responsive Firewall is disabled and both servers sit behind a firewall. Calls flow in and out of VOIP4 as expected. All extensions are CHAN_SIP and connected to VOIP4 via CISCO SPA504g phone.

I setup in a different location a new instance using the latest FreePBX distro and installed using default settings (Asterisk 13). This time I used the included Responsive Firewall and setup using the default settings.

Created CHAN_SIP and PJSIP Extensions and connected to a CISCO SPA504g phone.

PBX Server – connected to Gate2 Asterisk server

Outgoing Settings

Trunk Name: GATE2_LINK

username=MY_TRUNK

type=friend

secret=<secret>

qualify=yes

insecure=very

host=gate2.<domain.tld>

dtmfmode=auto

context=from-trunk

Incoming Settings

Blank

On the Extension connected to PBX Server I can make an outbound call. However, when I route a called to the same extension get the message “received incoming sip connection from unknown peer to …”

I can set “Allow Anonymous Inbound SIP Calls” on the PBX Server to “YES” and the calls come in but obviously this is not a permanent solution – not one I would deploy.

Any help or insight would be appreciated.


(DaRussian) #2

freepbx*CLI>

== Setting global variable ‘SIPDOMAIN’ to ‘IP_ADDRESS

– Executing [<phone_number>@from-sip-external:1] NoOp("PJSIP/anonymous-0000001d", "Received incoming SIP connection from unknown peer to <phone_number>") in new stack

– Executing [<phone_number>@from-sip-external:2] Set("PJSIP/anonymous-0000001d", "DID=<phone_number>") in new stack

– Executing [<phone_number>@from-sip-external:3] Goto("PJSIP/anonymous-0000001d", "s,1") in new stack

– Goto (from-sip-external,s,1)

– Executing [s@from-sip-external:1] GotoIf("PJSIP/anonymous-0000001d", "1?setlanguage:checkanon") in new stack

– Goto (from-sip-external,s,2)

– Executing [s@from-sip-external:2] Set("PJSIP/anonymous-0000001d", "CHANNEL(language)=en") in new stack

– Executing [s@from-sip-external:3] GotoIf("PJSIP/anonymous-0000001d", "1?noanonymous") in new stack

– Goto (from-sip-external,s,5)

– Executing [s@from-sip-external:5] Set("PJSIP/anonymous-0000001d", "TIMEOUT(absolute)=15") in new stack

– Channel will hangup at 2018-10-07 09:12:07.415 UTC.

[2018-10-07 09:11:52] WARNING[26810][C-00000022]: func_channel.c:465 func_channel_read: Unknown or unavailable item requested: ‘recvip’

– Executing [s@from-sip-external:6] Log("PJSIP/anonymous-0000001d", "WARNING,"Rejecting unknown SIP connection from "") in new stack

[2018-10-07 09:11:52] WARNING[26810][C-00000022]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from "

– Executing [s@from-sip-external:7] Answer("PJSIP/anonymous-0000001d", "") in new stack

> 0x7f47e0728c80 – Strict RTP learning after remote address set to: <IP_ADDRESS>:10604

> 0x7f47e0728c80 – Strict RTP switching to RTP target address <IP_ADDRESS>:10604 as source

– Executing [s@from-sip-external:8] Wait("PJSIP/anonymous-0000001d", "2") in new stack

– Executing [s@from-sip-external:9] Playback("PJSIP/anonymous-0000001d", "ss-noservice") in new stack

– <PJSIP/anonymous-0000001d> Playing ‘ss-noservice.ulaw’ (language ‘en’)

> 0x7f47e0728c80 – Strict RTP learning complete - Locking on source address <IP_ADDRESS>:10604

– Executing [h@from-sip-external:1] Hangup("PJSIP/anonymous-0000001d", "") in new stack

== Spawn extension (from-sip-external, h, 1) exited non-zero on ‘PJSIP/anonymous-0000001d’

freepbx*CLI>


Some more information. Above is the verbose output. I have an inbound route with the correct details (i.e. phone number).

Also, set my trunks as peers to each other.


#3

I’m very puzzled. Your gate2 server at .101 has chan_sip bound to port 5060. The trunk settings for the failing system (if analogous to those for voip4) have no port number specified and there is no DNS SRV record, so it sure seems that the remote system should connect to chan_sip on gate2. But your log shows it’s attempting to connect to pjsip, which is why it’s unknown!


(Tom Ray) #4

Please re-read the post again. This call trace does not show any REGISTER attempts or really any SIP messaging so this isn’t showing anything for a REGISTER.

Please show us how you are drawing this conclusion. There is nothing that has been posted to show what ports each of the channel drivers are using. The port= setting for a Chan_SIP peer is the port to use for the REMOTE side.

FreePBX has made Chan_PJSIP the default SIP channel for the last 2-3 years now. That means that Chan_PJSIP is listening on 5060 and Chan_SIP is listening on 5160. That is unless the OP has modified/updated the ports that each driver is listening on.

This log show no such thing. What this log is showing is an INCOMING CALL from an IP that is not set in any Chan_SIP or Chan_PJSIP trunk. This call is hitting the “from-sip-external” context which is for incoming requests that are not allowed to make calls once in the system. So the incoming call is being sent to the PBX IP on port 5060 which because Chan_PJSIP is running and bound on 5060, it’s going to be what accepts the call.

So this system is exposed to allow anyone to send requests to it and the PBX is accepting them. The only thing that is saving the OP’s ass is that FreePBX is dealing with it and sending the call to a “blackhole” that stops it from happening.

Basically, @TheRussian1968 needs to put some real security on this box to stop these from happening.


#5

The first mention of ‘register’ in this thread is yours. I’m reasonably sure that no registration was intended, because the trunks are set up statically (each machine pointing at the FQDN of the other).

Yes, there was, though the OP has since edited it out. I probed port 5060 with svmap and looked at the response to OPTIONS. It contained:
Supported: replaces, timer
and
Accept: application/sdp
exactly matching what chan_sip returns on my system, whereas pjsip returns:
Supported: 100rel, timer, replaces, norefersub

Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, application/dialog-info+xml, application/pidf+xml, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, application/simple-message-summary, message/sipfrag;version=2.0

So, at least as viewed from ‘outside’, which is what the OP’s failing system sees, port 5060 is almost certainly chan_sip.

IMHO that is not necessarily true. If the IP is configured in chan_sip (which the OP strongly implies) but the call attempt is routed to pjsip, it will of course be treated as unknown.

While I agree with you 100% that the box should be secured ASAP, even allowing anonymous calls would not by itself be disastrous, because the context they run in would normaly limit the attacker to obnoxiously ringing all the phones. However, combined with another mistake (in DISA, transfer, voicemail, etc.) he could call arbitrary destinations on the OP’s nickel.


(Tom Ray) #6

I hate when people do this. It makes it hard for us to actually give proper help.

Well as the OP has stated there are PJSIP extensions in existence, seeing endpoints making request over the PJSIP port/driver shouldn’t be unexpected. But regardless of what driver is listening on what port, there is still a SIP scan happening and attempts to abuse the PBX. I just find it odd that there’s a large amount of scanning traffic that is only hitting the PJSIP driver, which you say is not 5060 but Chan_SIP is, that not a single scan attempt is being shown on Chan_SIP. So this would be the first box ever I’ve seen be attacked with a SIP scan that didn’t make attempts on 5060.


(Mai Tan Ha) #7

Hello,

I’m facing the same issue with you. I have happened since 4 days ago.

Do you know how to fix it?

Thank you so much for your help in advance!

I can receive incoming call normally but It doesn’t work for outgoing call :frowning:

Here is the logs on my server: