Not sure if this will help but here goes.  I am not familiar with elastix but I had registration issues on my asterisk box until I made some changes in sip_custom.conf (sip.conf)  the file may be named different on your system (I use piaf)
here is what mine looks like

externip=put the ip of your wan interface here localnet=192.168.150.0/255.255.255.0 localnet=10.0.5.0/255.255.255.0 localnet=10.0.8.0/255.255.255.0 nat=yes promiscredir=yes

all the local net entries are for the different internal (local) networks I have that contain phones.  Some of the are vpn

I only have the default outbound rule in pfsense and my wan nat/fw rules look like the attachment below (192.168.150.201) is my local asterisk box

My gut feeling is that this is probably an issue with the config on the asterisk box and not necessarily the fw.  Once I got everything on my piaf box configured it has worked smooth for a very long time.  (knock wood)

2014-07-13_150110.jpg
2014-07-13_150110.jpg_thumb

"does pfsense intercept dns traffic if clients set their own DNS servers?"

No but my ISP does this all the time and forces me to use pages that they have cached even when i use OpenDNS for the upstream server.

Bit rude of them when I have elected not to use their DNS server but this means that they are also having to isue fake SSL certificates too and are doing a Man-in-Middle to speed up pages and to save themselves money on the upstream bandwidth.

Does not seem legal to me

Once you get the pppoe connection working you will have to decide how you are going to use the two wans, either independently or in a load balancing configuration.
After that you have set up firewall rules on your lan and other interfaces to direct traffic accordingly.

A common cause of high CPU usage like this is opening the dashboard on some client somewhere and forgetting to close it. Though that would not usually be for more than a day.  ;)

Steve

Can anyone confirm for sure that this is the correct way to do this, and if it's working?
This is how I have ours set up – 2 domain controllers (.2 and .3) but I am not sure how to tell if it's actually doing the right thing without forcefully shutting down one of the DCs.

It won't be gone for long. Reinstalling won't stop that kind of issue. It may prolong its life for some period (because just a power cycle could kick it back into shape temporarily), but I'd have a spare drive on hand as it's likely it won't last long.

@MarkVLK:

Would it be possible to just install Snorby on the pfSense box and have Snort + Snorby both running on it?

Probably not without adding a lot of dependent libraries.  I do not recommend doing this on your firewall.  It adds way too many attack vectors with all the extra stuff like shared libraries.  You can also run out of CPU horsepower pretty quickly with a MySQL server, Snort (or Suricata), Snorby and then basic firewalling as well.  Much better to do this on a different server.  You can use a physical machine or a virtual one.

Bill

@cmb:

It's that package, not country blocking in general, that's no longer supported or maintained. pfblocker replaces it (though its data is very old at this point, other options better if you need data with a very high degree of accuracy). The country lists in pfblocker stopped being updated when countryipblocks stopped distributing data for free. There will be an alternative to that coming before too long though, stay tuned.

I disabled the Countryblock package in the repo since it's been so long no one should be using that anymore.

Thanks for the explanation!

Did some troubleshooting and it was the traffic shaping dropping packets! I should have thought of that before I posted here. Thank you for getting me thinking.

@crossroads1112:

How would I configure pfsense to issue IPS to the phone and TV?

By default pfSense issues IP addresses dynamically from its internal DHCP server. Most consumer devices (TVs and phones) are also configured to receive IP addresses dynamically from a DCHP server. So no additional configuration is necessary in most cases. This configuration should simply just work:
Devices  <–> switch/hub <--> [LAN pfSense WAN] <–> [LAN modem WAN] <–> internet

This is the simplest configuration and the one that pfSense is specifically preconfigured for. You can actually test it without making any changes to the modem and it should still work anyway although there will be a double NAT performed (once by pfSense and once by the modem).  Steps to test:
1. Plug in everything according to above diagram
2. Configure pfSense with all defaults except change the LAN IP address to be different from the one the modem is using. (192.168.20.1 as divsys suggested)
3. Reboot everything in this order so that all the devices get issued new IP's: modem, pfsense, devices

This setup should simply work. If it does, then you can remove the double NAT from the design by reconfiguring the modem for bridging only, then reboot the modem and pfsense and pfSense should pick up a public IP and everything should continue to "just work".

@crossroads1112:

Alternatively would there be a way to configure pfsense to just pass that traffic along to the modem and let it handle the TVs and phones?

Yes, although it's a bit more involved and shouldn't be necessary in most scenarios. You could place an additional switch between pfSense and the modem for those devices, or create a DMZ, or use 1:1 NAT, or bridging, etc.  I would try the test setup above first to see if it works. If it turns out that the TV and phone have to connect to the modem, then things get a bit more complicated. You'll want to review the ISP's requirements to determine the best configuration at that point.

Thanks fir the reply, appreciate it.

The reason that I'm asking is I've always used a router and ran
everything through the VPN.  The problem is running all our devices
through the VPN slows everything down to a crawl and makes streaming
near imimpossible.

I have 50/10 internet.  Do you think a pfsense box would help with running
everything through the VPN ?  Or would I be better off just using a router
and just selectively running the important devices through the vpn?

Relatively simple, probably not. If you're familiar with RRD and comfortable with the BSD command line,  this script might do it for you:
http://oss.oetiker.ch/rrdtool/pub/contrib/merge-rrd.txt
merge-rrd.tgz  http://oss.oetiker.ch/rrdtool/pub/contrib/

https://www.google.com/search?q=pfsense+merge-rrd

Most people just toss the old data.

First thing to check is Status: System logs: Firewall to see if the traffic is being blocked.

That said  ;), I think your floating rule is being applied to OPT1 and LAN interfaces (the members), but when you set net.link.bridge.pfil_bridge=1 and net.link.bridge.pfil_member=0 you're telling the firewall to filter the bridge, not the interfaces. So the floating rule isn't matching.  (f you invert your net.link.bridge.pfil_ settings, it might work)

Or…

The recommended procedure for version 2.x is to assign the bridge as an interface and assign the IP address to the new Bridge Interface. See this post for the summary: https://forum.pfsense.org/index.php?topic=38042.msg196370#msg196370

@GruensFroeschli:

1: Interfaces –> assign --> bridges.
2: Create a bridge and add all interfaces you want as member.
3: Interfaces --> assign
4: Assign the bridge you just created. The bridge is treated like a normal interface. Configure IP's on this interface
(5:) Assign the interfaces which are member of the bridge. Set their IPs as "none".
(6:) Create firewall rules on the member-interfaces of the bridge to allow traffic.

More detail: https://forum.pfsense.org/index.php?topic=20917.0

That said (again)  ;), I used the book. It's got an entire chapter devoted to bridging.

Yes, but not nearly as pretty or concise.

For allowed packets and current connections go to Diagnostics: States, enter the IP address, click filter. (To update, click filter again.)
You can also get real time state monitoring at Diagnostics: pfTop.

To see blocked packets go to Status: System Logs: Firewall, enter the IP, click filter. To update, click filter again.
(To see which rule caused the block, click on the white/red X at the far left.)

If anyone could give me an idea, I'd be very grateful  :)

Just noticed this thread got some more replies.

One doesn't really have anything to do with the other.  Just because you are using the DNS forwarder doesn't necessarily mean that you don't also have a good reason for allowing some machines to use external DNS.

I made the assumption it did because pfsense does a lot of things automatically; many rules are implicit. A warning such as I suggest is just a warning; it wouldn't harm people who did not make the assumption, and it would help those who did (not to mention, those who have to straighten the latter out…)