Asterisk + Pfsense and Static port is not fixing the problem..

dhatz

I'm absolutely confused. pfsense has absolutely refused to work with our elastix box completely. yet there is another one that works perfectly fine.. it's mind boggling.

If you need answers, you'll have to do some debugging with tcpdump.

Both Asterisk and pfSense are very complex (due to being so feature-rich) pieces of software, each with hundreds of tunable parameters. Most problems people have with VoIP is that the standard SIP protocol wasn't initially designed with NAT traversal support and as a result SIP devices have to be configured appropriately (assuming reasonable up-to-date SIP protocol implementations).

Bottom line, one cannot just plug an IP PBX and a router/firewall together and expect everything to "automagically" work; and if by chance it does, one risks encountering problems as soon any changes / upgrades occur to the initial configuration.

PS: I run various Asterisk & Elastix systems behind pfSense and iptables with remote extensions over VPN and don't have to use static-port. Currently pfSense's most serious and long-standing shortcoming is its inability to properly clear states upon WAN IP change, which isn't an issue in my case but affects many others.

itwurx

Oh by no means do I ever expect anything to be plug and play at this level. I work with cisco equipment (though it becomes plug and play once you have mastered a base config :) )

I found out why my extensions stopped working. Sipproxd and cisco phones don't play well at all.

itwurx

my issue is now, outbound calling. I can hear them but not me.

Oi.

itwurx

okay my extensions arent talking to each other again. nothing changed. this is absolutely frustrating. The problem here is, everything worked fine when we were using a PIX 515, now it isn't and I'm baffled.

SysIT

If you cant hear people, the right ports aren't forwarded or IP access is not correct on your trunk provider to allow access, if they block it.

itwurx

I figured it out a while back but I wanted this to be finalized so if anyone else is reading with a similar issue they arent like "great another unfinished topic!"

Basically I needed to modify the sip_nat.conf with two more localnet= entries as my configuration has IP phones talking via VPN.

I didnt realize you need one for every subnet a phone is on internally. d'oh.

reh1151

I inherited a situation where the previous Sysadmin placed the Trixbox (asterisk box) outside the firewall. For security reasons, I have to move it back behind my pfSense firewall. To do so, I installed a new Intel dual NIC and created a dedicated interface for VoIP traffic. Next I setup NAT rules for inbound SIP & RTP as well as HUD & VPN for Fonality. Inbound calls work perfectly. However, outbound calls fail to connect. Using the packet tracer built into asterisk, I determined that my outbound calls are going through the WAN interface instead of the VoIP interface and are being rejected by my SIP provider because the header contains the wrong IP address (this is what SysIT posted). So far so good. I installed the siproxd proxy, made the necessary changes to my sip.conf, configured it according to the instructions outlined here: http://doc.pfsense.org/index.php/Asterisk_VoIP. Still unable to make outbound calls. Inbound calls work as before. Tried a variety of NAT/Firewall rules aimed at forcing outbound traffic through VoIP interface. This time, I was able to make outbound calls but could get no sound (ringing, etc). Gave up and returned to the previous setup.

I have looked everywhere and have sifted through a lot of conflicting information. This should have worked with the NAT rules - actually it does work for the WAN interface but not the VoIP interface. What I need is an hint on how to direct all outbound traffic from the Trixbox through the VoIP interface. I thought the siproxd proxy did this but it's not working for me. Would the solution be to delete the sip proxy and create a manual outbound AON NAT rule for the VoIP interface forcing all SIP traffic through a static port? I would appreciate any and all suggestions. I feel that I am very close to solving this issue.

My NAT Rules (Autogenerated Firewall Rules) are:
VOIP UDP * * VOIP address 5060 (SIP) Trixbox 5060 (SIP) SIP Signalling
VOIP TCP * * VOIP address 8000 Trixbox 8000 VPN1 for Trixbox
VOIP TCP * * VOIP address 9000 Trixbox 9000 VPN2 for Trixbox
VOIP TCP * * VOIP address 5222 Trixbox 5222 HUD3 for Trixbox
VOIP UDP * * VOIP address 10000 - 20000 Trixbox 10000 - 20000 RTP Signalling

I'm looking at the following AON NAT Outbound rule:
VOIP 192.168.150.0/24 udp/5060 * udp/5060 * * YES (static port)

dhatz

@reh1151:

I inherited a situation where the previous Sysadmin placed the Trixbox (asterisk box) outside the firewall. For security reasons, I have to move it back behind my pfSense firewall. To do so, I installed a new Intel dual NIC and created a dedicated interface for VoIP traffic. Next I setup NAT rules for inbound SIP & RTP as well as HUD & VPN for Fonality. Inbound calls work perfectly. However, outbound calls fail to connect. Using the packet tracer built into asterisk, I determined that my outbound calls are going through the WAN interface instead of the VoIP interface and are being rejected by my SIP provider because the header contains the wrong IP address (this is what SysIT posted).

Could you draw a simple diagram of your network topology ?

I think your problems are due to "multi-homing" your Trixbox server, after the addition of the dual-port NIC. You'll need to configure proper routing on the IP-PBX itself. I don't think static-port NAT configuration on pfsense will make any difference and you shouldn't be needing siproxd.

I agree with your decision to put the PBX behind a perimeter firewall (pfSense) and I always add a host-based firewall & monitoring software on the IP-PBX itself.

reh1151

No, I don't think so. (see attached) The Trixbox currently has two NICs: eth0 & eth1. Eth0 connects directly to a 6MB fiber connection for Broadvox, my SIP provider. Eth1 connects to the LAN. When I move the Trixbox behind the firewall, I disable eth1 and eth0 is configured as the LAN port. The VoIP interface on pfSense is configured with the previous eth0 configuration. This works fine - I can receive calls with no quality or cutoff issues. However, no calls connect from inside because the Trixbox is sending out through the WAN interface instead of the VoIP interface (verified by Broadvox). I get lost trying to force outbound traffic from the Trixbox LAN connection through the VoIP interface. Now, I thought that the siproxd proxy did this but it didn't work. I attempted to setup a NAT port forward (with associated filter rules) like this:

LAN UDP * * VOIP address 5060 (SIP) Trixbox 5060 (SIP) SIP Signalling
LAN UDP * * VOIP address 10000 - 20000 Trixbox 10000 - 20000 RTP Signalling

Which did not work. Even if a call connects, you hear nothing because (if I understand correctly) RTP is getting randomized. Soooo, today I tried setting up an Outbound NAT AON rule:
VOIP x.x.x.0/24 * * * * * YES Outbound NAT for Trixbox

All I want is to use the dedicated VoIP interface for Trixbox traffic. There must be a way to to do this on pfSense but at this point I suffer from a severe case of overthink - I am certain the answer is simply but it eludes me.

Network_001.png_thumb

Syntax42

Is the image I attached what you are trying to accomplish? I added lines through pfSense to show what I think your intended routing is.

It sounds like your PBX needs to have the settings for the default gateway adjusted. The internal network IP address shouldn't have a default gateway. Do this by setting a static IP on the PBX and leave the default gateway blank on the LAN side.

To make management simpler, you may wish to put the WAN interface of the PBX in a separate subnet from the rest of the network. The pfSense interface it connects to should also be on the same subnet and the IP address should be the default gateway.

You might want to consider using a PBX system which is maintained. Trixbox was abandoned years ago and support for the software is very limited. My system uses FreePBX and I like it. Trixbox put my system in a Fonality database which led to intrusion attempts almost daily.

NetworkDiag.png_thumb

Reiner030

Hi,

i take a short look over this thread. If I'm right it was mentioned that it should be manual outbound NAT but nobody wrote/suggested that you have/should use

incoming 1:1 NAT (public IP => internal IP )
oubout NAT (Interface, Source IP (network), an port , any IP, any port, public IP, no static (needed))
=> important is here also the order of rules… first match wins ;) (so PBX network must be come after PBX IP)
related Firewall rules from outside => inside
We have opened
+ UDP any IP , any port => public IP :5060
+ UDP any IP , any port => public IP :1000:20000 RTP
+ TCP/UDP any IP , any port => public IP :4569 IAX2

perhaps you need TCP for SIP, too:
+ TCP/UDP any IP , any port => public IP :5060 SIP

This rules are done in our company and work fine ;)

if your SIP Accounts passworts are secure you can open it like our ports;
If not / you don't want connect clients from outside you should better allow outside IP ranges of your trunk(s) as remote incoming IPs.

dhatz

Reiner30 you shouldn't need to open any ports (5060, 10000_20000, IAX etc) from outside, unless you have remote extensions (in that case, even if you're using strong passwords, it'd still be advisable to only let people connect over VPN, for no other reason than to avoid the flood of fake SIP registration attempts as soon as they find out you have an open port 5060)

I've seen cases where all the bandwidth was consumed by the hackers' intrusion attempts …

PS: 1:1 NAT does no port rewriting iirc.

Reiner030

@dhatz:

Reiner30 you shouldn't need to open any ports (5060, 10000_20000, IAX etc) from outside, unless you have remote extensions (in that case, even if you're using strong passwords, it'd still be advisable to only let people connect over VPN, for no other reason than to avoid the flood of fake SIP registration attempts as soon as they find out you have an open port 5060)
PS: 1:1 NAT does no port rewriting iirc.

interesting…

How do you let incoming trunk INVITES then in? ;)
If you have 1:1 connection then it's no problem but some of our providers have different IPs for their media gateways than their SIP registrar IP.
And how (if not initiated from internally) should incoming RTP streams get in?
I think pfsense didn't use an iptables equivalent of ip_sip which reads SIP stream to find out the negotiated ports ?

Our PBX has also snort running so intrusion attackes are blocked after short time.
And using full bandwith for these attacks is not impossible but needs huge resource since we have 100 MBit fiber connection.

EDIT:
forgotten... our SNOM phones can use OpenVPN tunnels but most SIP software clients doesn't support tunnels "out of the box" :(
I found 3CX as interesting solution for Windows/mobile clients but their 3cx tunnel is bundled to their 3cx server only/need windows.
So "tunneling to go" for the users is not possible from my state of knowledge.

Bests

reh1151

@Reiner030:

Hi,

i take a short look over this thread. If I'm right it was mentioned that it should be manual outbound NAT but nobody wrote/suggested that you have/should use

incoming 1:1 NAT (public IP => internal IP )

oubout NAT (Interface, Source IP (network), an port , any IP, any port, public IP, no static (needed))
=> important is here also the order of rules… first match wins ;) (so PBX network must be come after PBX IP)

related Firewall rules from outside => inside
We have opened
+ UDP any IP , any port => public IP :5060
+ UDP any IP , any port => public IP :1000:20000 RTP
+ TCP/UDP any IP , any port => public IP :4569 IAX2

perhaps you need TCP for SIP, too:
+ TCP/UDP any IP , any port => public IP :5060 SIP

This rules are done in our company and work fine ;)

if your SIP Accounts passworts are secure you can open it like our ports;
If not / you don't want connect clients from outside you should better allow outside IP ranges of your trunk(s) as remote incoming IPs.

Well, this is the last thing left to try - setup a 1:1 NAT from the VoIP provider's public IP on the VoIP interface to the Trixbox. I have tried everything else with no success. So far I have tried:

Siproxd: Didn't work for me. It appears to be made for users who have IP phones that need to register with an external VoIP provider. I have an asterisk server I want to move behind the firewall and my softphones register with it just fine. Siproxd logs

Outbound NAT AON: Broke everything and left my network without Internet access.

Port Forwards for SIP & RTP: Works inbound only. Outbound calls go nowhere and then you get a fast busy signal. VoIP provider confirmed that these are coming from WAN interface, not the VoIP interface and hence are being rejected.

Have done a great deal of reading and it appears that running VoIP behind pfSense is a hit or miss endeavor. While I love pfSense and have been running it since 2009, I have already begun pricing Cisco ASA units which can easily accomodate what I'm trying to do. One other curiosity I noticed: When I moved the Trixbox behind the firewall, I was IMMEDIATELY swamped with a flood of fake SIP registrations from the 220.240.0.0 subnet because I had opened up SIP port 5060. I ended up blocking the entire subnet on the Trixbox using IPChains. This confirms what dhatz points out.

dhatz

@reh1151:

Have done a great deal of reading and it appears that running VoIP behind pfSense is a hit or miss endeavor. While I love pfSense and have been running it since 2009, I have already begun pricing Cisco ASA units which can easily accomodate what I'm trying to do. One other curiosity I noticed: When I moved the Trixbox behind the firewall, I was IMMEDIATELY swamped with a flood of fake SIP registrations from the 220.240.0.0 subnet because I had opened up SIP port 5060. I ended up blocking the entire subnet on the Trixbox using IPChains. This confirms what dhatz points out.

I have been running Asterisk-based PBXes behind pfSense for 2+ years and it works (however there are certain issues e.g. with multi-WAN configurations, which has been semi-solved in 2.1).

However, successful deployments depend on many factors: the NAT traversal capabilities of the SIP stacks involved (both of your Asterisk PBX and your SIP trunk provider), their respective configurations and of course the configuration of pfSense NAT. Due to the fact that SIP wasn't originally designed for NAT traversal, if problems arise one usually needs a good knowledge of the protocol internals in order to do proper troubleshooting.

With Cisco the main difference is that the product is typically installed by a "CCNP Voice"-certified network engineer.

Reiner030

perhaps a helpful hint:

try to debug your voip traffic from/to your trunk

on asterisk itself:

sip set debug peer <your trunk="">or on console with wireshark/tshark

You should get something (you set public IP for remote connects?):

When your PBX send a request like:
[Jun 17 20:34:28] Reliably Transmitting (NAT) to 193.47.84.4:5060:
REGISTER sip:terrasip.net SIP/2.0
Via: SIP/2.0/UDP <your public="" ip="">:5060;branch=z9hG4bK718a8652;rport</your>
Max-Forwards: 70
From: <sip:<your account="">@terrasip.net>;tag=as5fe32ab8
To: <sip:<your account="">@terrasip.net>
Call-ID: 3e926cdc79c80af43a9edc5323403c65@127.0.1.1
CSeq: 9847 REGISTER
User-Agent: Asterisk Gemeinschaft
Authorization: Digest username="<your account="">", realm="terrasip.net", algorithm=MD5, uri="sip:terrasip.net", nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Expires: 145
Contact: <sip:<your account="">@<your public="" ip="">>
Content-Length: 0

you should get something back like:
[Jun 17 20:34:28]
<–- SIP read from UDP:193.47.84.4:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP <your public="" ip="">:5060;branch=z9hG4bK718a8652;rport=5060;received=</your>
From: <sip:<your account="">@terrasip.net>;tag=as5fe32ab8
To: <sip:<your account="">@terrasip.net>;tag=598d351d4bc9e6e8e2c538995c9c64c8.a22c
Call-ID: 3e926cdc79c80af43a9edc5323403c65@127.0.1.1
CSeq: 9847 REGISTER
Contact: <sip:<your account="">@<your public="" ip="">>;expires=145
Server: TerraSip Advanced Router 1.0.16
Content-Length: 0

if the red part is filled out and NOT your public IP/port you intend to have then you have a misconfigured firewall .
You can take a look in Diagnose => States if the mentioned IP/Port is "open" on your firewall.

BTW … we are still searching for a good SE VoIP provider with a 10 number block ;)

Bests</your></sip:<your></sip:<your></sip:<your></your></sip:<your></your></sip:<your></sip:<your></your>

reh1151

Well, the Trixbox is still not working behind the pfSense firewall but Reiner030's post struck a chord. All this time I was assuming that the problem lay with pfSense. But everything I have read about running Asterisk behind a NAT firewall/router says that I have setup pfSense & the Trixbox properly. What I hadn't looked at was the firewall on the Trixbox itself. It's currently setup for the Trixbox sitting outside the pfSense firewall thereby acting as the sole firewall. It either (1) Should be turned off completely or (2) readjusted to send all outbound SIP/RTP traffic to the VoIP interface. The instructions I've read say the following:

1. Disable the firewall on the Asterisk server (Not done!!!)
2. Set a static IP address on the Asterisk server (Done. Created alias Trixbox on pfSense)
3. On firewall, forward SIP ports (UDP) 5060 and RTP ports (UDP) 8000 - 20000 to Trixbox IP address (Done on pfSense)
4. On Trixbox, edit the "rtpstart" value in rtp.conf to rtpstart=10000 (Done on Trixbox)
5. On Trixbox, enter the same externip=xxx.xxx.xxx.xxx and localnet=xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx info from your sip.conf general settings into sip_nat.conf (Done on Trixbox)
6. On Trixbox, in sip.conf under the account authentication settings for each remote extension add nat=yes, and canreinvite=no (Done on Trixbox)
7. Reload or restart Asterisk using the CLI

And that's all that is needed to get Asterisk working behind a NAT firewall like pfSense. I plan to try again only this time, I will shut off the firewall on the Trixbox first. As I posted before, once I moved the Trixbox behind the pfSense firewall, I was able to get incoming calls just fine. It was outgoing calls that did not work. Since the Trixbox is NAT aware, this will hopefully solve my problem.

Reiner030

ah ok… thats often the problem thats all assumed "as expected" ;)

1. Disable the firewall on the Asterisk server (Not done!!!)

Has the PBX surely own firewall rules ?

2. Set a static IP address on the Asterisk server (Done. Created alias Trixbox on pfSense)

Or you can set static IP on DHCPd so that the PBX gets a "static" IP ;)

3. On firewall, forward SIP ports (UDP) 5060 and RTP ports (UDP) 8000 - 20000 to Trixbox IP address (Done on pfSense)

Yes but they mus fit the RTP ports used on PBX... this is in this case not the case:

4. On Trixbox, edit the "rtpstart" value in rtp.conf to rtpstart=10000 (Done on Trixbox)

[general]
; RTP start and RTP end configure start and end addresses
; Defaults are rtpstart=5000 and rtpend=31000
;
rtpstart=10000
rtpend=20000

is in my case… you should set ports as needed both on PBX and firewall same range.

5. On Trixbox, enter the same externip=xxx.xxx.xxx.xxx and localnet=xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx
info from your sip.conf general settings into sip_nat.conf (Done on Trixbox)

Yes, this is set automatically in my pbx, too.
BTW. You can also set hostname on externip then it's resolved fixed at pbx start.
There is also an option externhost so you can use a pbx behind a dynamic IP ;)

;externhost=foo.dyndns.net ; Alternatively you can specify an
; external host, and Asterisk will
; environments! Use externip instead
;externrefresh=10 ; How often to refresh externhost if

6. On Trixbox, in sip.conf under the account authentication settings for
each remote extension add nat=yes, and canreinvite=no (Done on Trixbox)
7. Reload or restart Asterisk using the CLI

For our PBX trunk is configurable per WebGUI including NAT options and I tested it and with our setup it's not needed to activate this option when 1:1 incoming/outbound NAT is defined right.
We have it only activated to get our VoIP providers happy which always claims that this must be the cause if something didn't work as expected (it's always the customer who made the errors; not the providers ^^)

Greets

Reiner

reh1151

@Reiner030:

ah ok… thats often the problem thats all assumed "as expected" ;)

1. Disable the firewall on the Asterisk server (Not done!!!)

2. Set a static IP address on the Asterisk server (Done. Created alias Trixbox on pfSense)

3. On firewall, forward SIP ports (UDP) 5060 and RTP ports (UDP) 8000 - 20000 to Trixbox IP address (Done on pfSense)

4. On Trixbox, edit the "rtpstart" value in rtp.conf to rtpstart=10000 (Done on Trixbox)

[general]
; RTP start and RTP end configure start and end addresses
; Defaults are rtpstart=5000 and rtpend=31000
;
rtpstart=10000
rtpend=20000

is in my case… you should set ports as needed both on PBX and firewall same range.

I did as you pointed out.

5. On Trixbox, enter the same externip=xxx.xxx.xxx.xxx and localnet=xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx
info from your sip.conf general settings into sip_nat.conf (Done on Trixbox)

Yes, this is set automatically in my pbx, too.
BTW. You can also set hostname on externip then it's resolved fixed at pbx start.
There is also an option externhost so you can use a pbx behind a dynamic IP ;)

;externhost=foo.dyndns.net ; Alternatively you can specify an
; external host, and Asterisk will
; environments! Use externip instead
;externrefresh=10 ; How often to refresh externhost if

6. On Trixbox, in sip.conf under the account authentication settings for
each remote extension add nat=yes, and canreinvite=no (Done on Trixbox)
7. Reload or restart Asterisk using the CLI

For our PBX trunk is configurable per WebGUI including NAT options and I tested it and with our setup it's not needed to activate this option when 1:1 incoming/outbound NAT is defined right.
We have it only activated to get our VoIP providers happy which always claims that this must be the cause if something didn't work as expected (it's always the customer who made the errors; not the providers ^^)

Greets

Reiner

Has the PBX surely own firewall rules ?
Yes. Since it is currently connected directly to its own WAN connection outside of the pfSense box, it HAS to run it's own firewall.

Or you can set static IP on DHCPd so that the PBX gets a "static" IP ;)
Good point but I don't use the pfSense box as the primary DHCP server. I use the AD server to manage internal DNS & DHCP..

Yes but they mus fit the RTP ports used on PBX… this is in this case not the case:
For my environment, I had to forward SIP port UDP 5060 & RTP ports UDP 10000-20000. For the Trixbox, I also had to forward TCP ports 8000 & 9000 for the VPN to Fonality plus TCP port 5222 for HUD signalling.

Followed 5, 6 & 7

Well, after performing these steps, I was able to make one outgoing local call. As I pointed out before, incoming calls worked perfectly. When I tried to make a test LD call, nothing happened and from that point onward I was unable to make any outgoing calls (local & LD). So I tried setting up 1:1 NAT and resetting the state tables. No work. Then I switched over to Manual Outbound NAT AON. Still nothing. I ended up restoring the backup I took before making these changes in order to get pfSense back online. I am encouraged that I actually saw this work but I am mystified as to what caused it to stop. And that's where I left it although I plan to try again this weekend after reviewing my steps. I am missing something but cannot figure out what is lacking.

dhatz

I think that the fact that you keep having problems is most probably due to using Trixbox. Trixbox CE is a very old, obsolete IP-PBX distro.

A VoIP setup primarily depends upon the capabilities and configuration of the two SIP end-points (your IP-PBX and your SIP trunk provider). If one side (or both) is "brain-dead" wrt NAT traversal, then you can only do so much by fiddling with the router / NAT gateway config.

If you can't upgrade your IP-PBX your best alternative would be to use pfSense's 1:1 NAT.