Fritzbox -> OPNsense -> FreePBX => keine eingehenden Anrufe

Hallo zusammen,

ich kämpfe seit ein paar Tagen mit einer FreePBX, bei der ich zwar ausgehende Telefonieren kann, eingehend aber keine Anrufe erhalte.
Im Livesystem habe ich seit ca. 1,5 Jahren eine OPNsense in Betrieb, welche einwandfrei funktioniert.
Da die ISDN-Telefonanlage schon älter als 10 Jahre ist, soll diese gegen ein modernes VoIP-System (FreePBX) ausgetauscht werden.

Hab mir das Ganze mal im Labor nachgebaut.
Betreibe ich die FreePBX direkt an FritzBox, funktioniert alles einwandfrei.

Schalte ich die Firewall (OPNsense) mit dazwischen, dann funktionieren zwar ausgehende Anrufe, eingehende Anrufe funktionieren nicht.
Auch wenn externe Anrufer zuerst auflegt bekommt diese die FreePBX gar nicht mit.

Aufbau ist folgender:
FritzBox (192.168.184.1) --> OPNsense (192.168.184.115 (WAN) + 192.168.99.1 (LAN)) -> FreePBX (192.168.99.12)

Für die Rufnummer ist in der FritzBox ein LAN/WLAN-Telefoniegerät eingerichtet.
In der FritzBox ist ein exposed-Host eingerichtet, das alles an die OPNsense schickt.

Die Asterisk-SIP-Settings habe ich auch entsprechend angepasst:

1615133859819.png

SIP-Port ist UDP/5060.

In der Firewall habe ich mir hierzu folgende NAT-Regeln angelegt (Port-Forward):

1615133925613.png

Die OPNsense hat dann automatisch folgende Firewallregeln erstellt:

1615134463226.png

Zusätzlich eine statische Outbound-Route gesetzt und vorher den Mode auf Hybrid gesetzt:

1615133986376.png

Hier noch die Alias-Übersicht:

1615134041537.png

Ausgehende Anrufe funktionieren einwandfrei inkl. Audio.
Eingehende Anrufe kommen gar nicht in der FreePBX an.
Zudem ist mir aufgefallen, das es das interne Telefon gar nicht mitbekommt, wenn der externe Teilnehmer aufgelegt hat.
Legt das interne Telefon auf, dann funktioniert das ganze schon.

Hab aktuell irgendwie den Eindruck, das die FritzBox eingehende Aktivitäten (neuer externer Anruf, externer Teilnehmer hat aufgelegt) überhaupt nicht an die FreePBX weitergibt.

Hat evtl. jemand schon mal eine FreePBX mit dazwischengeklemmter Firewall hinter einer FritzBox in Betrieb genommen?
Ich vermute das das Problem am doppelten NAT liegt (externe DTAG-IP -> NAT -> FritzBox -> Forwarding OPNSense -> NAT -> FreePBX)

Ich könnte zwar die FreePBX direkt hinter die FritzBox setzen und dort dann die FreePBX-Firewall zum Schutz einschalten - schöner wäre aber die Lösung mit der eh schon vorhandenen (zentralen Firewall).

Evtl. hat das gleiche Konstrukt schon in Betrieb und kann mir Tipps geben, wie ich das Ganze zum Laufen bekomme.

Vielen herzlichen Dank schon mal im Voraus für die Unterstützung und Tipps!

Viele Grüße:
Andreas

The images linked from ip-phone-forum.de are not visible to readers here, because that forum only allows registered users to view them. “Dazu muss man eingeloggt sein.”

Based on the text in your posts, I suspect that source port rewriting and/or UDP timeouts in OPNsense are causing your trouble. See reply #4 in https://forum.opnsense.org/index.php?topic=8754. .
IMO, you should ensure static NAT on all UDP ports (both SIP and RTP) as well as “Conservative state table optimization”. I don’t believe that siproxd should be used in your application. Also be sure that qualify is enabled for your trunk.

If you still have trouble, post images by dragging them to the compose window or using the upload button. If you must use an outside host, choose one that does not require the reader to register, e.g. imgur.com .

1 Like

Hallo zusammen,

hab die letzten Tage weiter debugged…
Von Seiten der FritzBox kommt überhaupt keine Signalisierung bei der OPNsense an, da kann die OPNsense überhaupt nichts dafür.

Die FritzBox sitzt vmtl. selber auf dem Port 5060.
Hab jetzt mal die Rufnummern direkt bei der DTAG registriert (über STUN), dann gehts einwandfrei.
Mit Arcor (Vodafone) sollte es dann genauso auf diese Variante klappen…

Hat evtl. jemand die Parameter zur Hand, welche für die Registrierung eines Arcor (Vodafone)-IP-DSL-Anschlusses in der FreePBX für die Amtsleitung (Hauptleitung) benötigt werden?
Hab bisher nur Infos für den Kabel Deutschland-Anschluss gefunden…

Vielen Dank nochmal an alle!

Viele Grüße:
Andreas

So I suspect that the Contact header in the REGISTER request has the wrong address. You can check that with pjsip logger or sip debug (depending on trunk type), or with sngrep or tcpdump.

If you are trying to use the Fritzbox itself as a trunk (server is 192.168.184.1), then the Contact address must be 192.168.184.115. If your trunk is on an external IP address, Contact address must be your public IP. That is also required for any external extensions not connected via VPN. If you need both contact addresses, setup will be more complex.

If you still have trouble, please repost directly in this forum, the images you linked at ip-phone-forum.de (which are not visible to readers here). Also, a SIP trace showing a REGISTER request, which gets a 200 OK response but does not get incoming calls routed correctly.

Hello Steward,

yes, i’m trying to use the Fritzbox itself as a trunk. (Server 192.168.184.1)
I created a LAN/WLAN telephone in the FritzBox:

If i plug the FreePBX directly to the FritzBox, everything works fine.

But if i switch a firewall (OPNsense) for security reasons between the FritzBox and the FreePBX, the whole construct no longer works.

This is my structure:

MyAsterisk SIP-Settings:

Hauptleitungen:



And my Inbound-Route:

The pjsip-Registration is ok:

The contact seems also to be good:
contact

Hier noch der Trace:

20:54:43.316536 IP (tos 0x0, ttl 63, id 64636, offset 0, flags [none], proto UDP (17), length 1108)
192.168.184.1.sip > freepbx.sangoma.local.sip: [udp sum ok] SIP, length: 1080
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.99.12:5060;rport=5060;branch=z9hG4bKPjbaddaa04-481a-4b3f-bced-4e4c694f4d6c;received=192.168.184.115
    From: <sip:[email protected]>;tag=e89d210e-5f3f-479b-b454-8d2319e95579
    To: <sip:[email protected]>;tag=F4BD39C14F4F6517
    Call-ID: 1f9506f3-8ac1-41d8-a2fd-cc5556afcbc5
    CSeq: 15871 OPTIONS
    Contact: <sip:[email protected]>
    User-Agent: FRITZ!OS
    Supported: 100rel,replaces,timer
    Allow-Events: telephone-event,refer
    Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
    Content-Type: application/sdp
    Accept: application/sdp, multipart/mixed
    Accept-Encoding: identity
    Content-Length:   359

    v=0
    o=user 1646401 1646401 IN IP4 192.168.184.1
    s=call
    c=IN IP4 192.168.184.1
    t=0 0
    m=audio 7078 RTP/AVP 8 0 2 102 100 99 97 101
    a=sendrecv
    a=rtpmap:2 G726-32/8000
    a=rtpmap:102 G726-32/8000
    a=rtpmap:100 G726-40/8000
    a=rtpmap:99 G726-24/8000
    a=rtpmap:97 iLBC/8000
    a=fmtp:97 mode=30
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=rtcp:7079

One problem (may not be the only one) is that Asterisk must present the 192.168.184.115 address to Fritzbox in the Contact header and SDP.

For a test, change Externe Adresse to 192.168.184.115, Submit, Apply Config, restart Asterisk. If you still don’t get any calls, check whether the INVITE from Fritzbox is now reaching OPNsense and debug from there.

Unfortunately, the above test is not a real fix, because for external extensions or trunks to work, Externe Adresse must be 87.118.xx.xx.

A ‘cheap’ fix is to use chan_sip for Fritzbox and pjsip for everything else, or vice versa.

An alternative is to avoid SIP over UDP for everything except Fritzbox.

If you won’t have external trunks, you could connect external extensions via VPN.

The ‘proper’ fix is to set up two separate UDP transports on pjsip. Unfortunately, there have been several associated bugs. I don’t know whether any remain or whether there may be a good workaround.

Hello Steward,

I’ve changed the external address to 192.168.184.115, submit and apply the config and restartet Asterisk. And now it works!
Thank you so much! After a long period of testing, finally a positive moment with the FreeBPX!

You have written, that the above test is not a real fix, because for external extension or trunks to work external address must be set to 87.118.xx.xx.

But I have only 3 SIP-Accounts in the FritzBox, no other external extensions or trunks.
Do you think, I’ll run into some problem with this configuration?

At the end, I will have the mentioned 3 SIP-Accounts (FreePBX-Trunks) and 3 call-extensions
(External numbers => internal Extension => use for)

  1. 0123/456789 => 84 => private Number
  2. 0123/9845674 => 88 => Work Number
  3. 0123/9845675 => 99 => Fax

For the first little test I created 2 SIP-trunks (1 and 2) and tested the calls (incoming + outgoing) - everything was fine.
The only thing I noticed is that the DID-Numbers are not working properly, I get the following DIDs:

Trunk 1: Number 0123/456789 => DID=“0123456789”
Trunk 2: Number 0123/9845674 => DID=2192.168.184.115"

That means that I cannot diverentiate between the two incoming calls.
I still have to find this error, then I can work with the FreePBX.

Thanks again for your big support!

Andreas

Try changing the Context for your trunks to from-pstn-toheader

Then call each of your numbers and see what shows as the DID. If they are all unique, set up the Inbound Routes accordingly and it should work properly.

If you still see the same DID when calling different numbers, look at the incoming INVITE requests to see if there is some way to tell them apart.

If you don’t add external extensions or trunks, there won’t be a problem. If you later decide you need them, you can resolve the issue then.

Hello Steward,

the problem is solved.

When debugging, I noticed that the DID was transmitted correctly for one number, but not for the others.
I’ve deleted this 2 entries in the FritzBox and created them new.
=> Now I can distinguish the incoming phone lines via the DIDs.

Now I just have to find out how to set the UDP timeout in the OPNsense to 10 minutes, because the calls break off after about 33 seconds…

So far, I haven’t found a setting for it in the OPNsense.

At work, we have Fortigate-Firewalls from Fortinet, there’s relatively easy to change this setting:

config firewall service custom
_ edit “SIP_Port”_
_ set category “General”_
_ set protocol UDP_
_ set visibility enable_
_ set udp-portrange 5060-5060_
_ set udp-idle-timer 600_
_ next_
end

Thanks for all help!
Andreas

Try Firewall: Settings: Advanced: Firewall Optimization set to “conservative”.
Also see https://support.onsip.com/hc/en-us/articles/204029430-PFSense-Firewall-Settings-for-VoIP
especially the part about disabling source port rewriting.

If you still have trouble, at the Asterisk command prompt type
pjsip set logger on
make or receive a failing test call, paste the Asterisk log at pastebin.freepbx.org and post the link.

Hello Steward,

that was the problem. I’ve changed the settings and now it works perfect.

One last question: Do you know whether it is possible to allow an extension to only make internal calls?

Thanks for your great help!

Andreas

That’s not a simple question.

  1. If you just want to block an extension from dialing external numbers (other than 112 and other emergency numbers), you can use the CallerID field of Outbound Routes, and/or set up a route above the regular non-emergency routes that matches the restricted extensions and has no trunks. However, this has various loopholes. For example, the restricted user could set up forwarding to an external number, then call his extension from his mobile.

  2. A restriction system without the above issues is https://wiki.freepbx.org/display/FPG/Extension+Routing . Although there is no cost, this is a commercial module (not open source) and requires your system to be properly configured and activated.

  3. If you also want to restrict access to system features e.g. disallow parking calls or retrieving voicemail, you can purchase https://wiki.freepbx.org/display/FPG/Class+of+Service-Admin+Guide .

  4. If you need really fine control e.g. allow a user to retrieve his own voicemail but not someone else’s, even if he knows their password, you will need to write your own dial plan code.

There is always the oldie but goldie “custom contexts” module, it’s a little scary to get your head around but still works well.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.