I think that you should think about changing your game-server list to use two IP addresses, one to check the status and one to provide to the public to connect to. That's how I'd do it personally anyway.

If it is pfSense to pfSense, I would definitely go OpenVPN. I have had both and had much better experience with OVPN than IPSec. I don't anticipate any issues between versions of pfSense connecting but I haven't tried it. I assume you would want a second OpenVPN server on a separate port for the site-to-site but I don't have experience with both on one box.

By any chance do you have or implemented traffic shaping recently?  The rules might be catching inter-LAN traffic hence, limiting the transfers to your upload cap (~50mbit/s).

Here's what it says. For the record, I'm using 2.0 RC1 After eliminating the provided FibreOP Actiontec router from my network I thought I would document all I have learned about how the FibreOP infrastructure actually works, so here it is. Your first question might be why did I eliminate the Actiontec router? Well… I found that when watching multiple HD channels and downloading many high traffic torrents the TV quality would suffer. While the Actiontec router doesn't really have good enough tools to determine the cause I suspect that it just could not handle the sheer number of packets per second. This is because all traffic between Bell Aliant and your local network (Internet / IPTV) has to go through the embedded processor within the router. This is a 680MHz ARM processor which can certainly handle sustained traffic, but not lots of tiny packets at the same time. Lots of tiny packets kills lots of equipment out there. I have replaced the router with a dual core Atom server, and even that machine is usually hovering around 13% with my traffic patterns. When you order any FibreOP service you are assigned a specific router and an ONT. The MAC address of this router is added to your account. You are given access to a management VLAN (a virtual network segment over the ethernet from the ONT). This VLAN is number 33. Bell Aliant can use this to remotely manage your router. As for the ONT it is configured (usually at installation) with a specific timeslot for the fiber you are connected to. With the architecture Bell Aliant has deployed there are actually multiple people on the fiber you are connected to. You get a copy of all their data incoming but since it is encrypted you can only really see yours. As for outgoing data since you can't send light from multiple sources at the same time you have to be synchronized and only send when it is your turn (thus the timeslot value). When you order FibreOP internet service DHCP access is added to your account and you are given access to the internet VLAN. This VLAN is number 35. The DHCP access is based on the MAC address of your router. If you hook up a different router on this VLAN with DHCP it will not get an IP address unless it is using the same MAC address as your provided router. You can not have a client identifier set in the DHCP client or you will get no DHCP lease. Additionally if you hook up another router and it's not on any VLAN (well, it's on the default VLAN of 1) you will not be able to get a DHCP lease either and you will not be able to get to anything. The router does NAT between this VLAN and your local network. When you order FibreOP TV service you are given access to the IPTV VLAN. Unlike internet service where the router gets an IP address and then NATs this VLAN is actually 'bridged' to your local network. This means that any packets that your router gets and doesn't handle gets forwarded to this IPTV VLAN at Bell Aliant. One thing I learned is that packets going to this VLAN MUST contain a priority of 4 (for video). If you don't have this priority set then the packets are ignored. I suspect Bell Aliant is doing this for filtering purposes. Let's examine how this works in the real world. When you turn on an IPTV Receiver it sends out a request to get an IP address. The provided router IGNORES this request and instead the request gets forwarded to the IPTV VLAN of Bell Aliant. A server at Bell Aliant provides the receiver with an IP address and also with additional information (where to get firmware, what firmware to get, some other configuration details). This is why you see your IPTV receiver getting a 10.X.X.X address even though your local network might be different. As the receiver contacts various IPTV servers these packets get sent to the router, which forwards them on to the IPTV VLAN and vice versa. The router is essentially a dumb forwarder. When you tune into a channel the receiver joins a multicast group which is broadcasting the channel. This gets forwarded up the chain so that if equipment in the chain is not yet receiving the channel it shortly will, and if it already is receiving the channel then nothing needs to be done except send it downward. This is crucial for IPTV since it scales far, there aren't multiple copies of a channel being sent simultaneously in the core infrastructure like a normal UDP stream would be. Multicast is good. As for bandwidth usage on channels HD channels seem to utilize about 7.45Mbps and SD channels 2.45Mbps.

Ah okay then thank you - The firewall rules system makes more sense to me now. I think I will leave the Internet-Only network as it is - I don't want to have to setup a pfSense interface for each restricted port and there would still be a problem of what happens over the wireless network. It's not really needed to have that level of isolation anyway.

Hi, I am brand new to this forum.  Have been using BSD for about 5 years and pfsense for about a year (running on an Alix).  I had noticed I couldn't get anything out of the packet capture function and never really played with it until recently.  I am having a flaming nasty dispute with my ISP and really needed this to work.  I did a search and found the posts talking about how this was broken on embedded and suggesting replacing a file.  There were also some other patches proposed.  Having poked around a bit in the file system I realized that the issue was that the file is being written to /root which is normally read only on the embedded version.  The patch calls the PHP function that marks the file system read/write and sets it back to read only on exit.  If you stay in that page and are not attempting to capture after you leave it then maybe that will work, but here is a much more stable (and easy) to apply fix: 1.  Go to Diagnostics - Edit file. 2.  Enter /usr/local/www/diag_packet_capture.php 3.  Scroll down to just past the copyright notice for the line $fp = "/root/" 4.  Change it to $fp = "/var/" Save the file.  Your packet capture should now work fine on 1.2.3 embedded.  /var is a memory disk on embedded.  Your captured data will not survive a reboot.  I don't personally see this as an issue.

Thanks again for your help :) ;D

This sounds to me like your IP Phones already send tagged traffic to the switch. In this case you would have to add the ports on the switch as tagged members of the VLAN. The PVID would be set to the VLAN on which you get the config.

It's a third ISP, and there was nothing wrong with it..? I was able to rebuild the routing tables by running "/etc/rc.d/routing restart", and this removed that erroneous route, and cleared everything up. I don't know how it got created in the first place, but fingers crossed it won't happen again.

install rrd summary or vnstat2 package… They should help you

Hi, hmm  bridging is not a good option here because services would affect each other eg. dhcp gateway. I think that dont work very well. I would prefer option 2 because: -devided networks -prevent broadcast traffic over wireless network -failover possible and more easy (the failover gateway is the wlan interface ip adress of the opposite pfsense) cya