And now I'm sure: I [auto]upgraded pfsense from webconfig and restarted it, and all went fine.  ;D

Hi submicron First of all thanks a lot, sorry for the wrong version number. But is DNS forwarder capable of this ? I'd like to register my access points in DNS in order to be resolved  by a snmp system. The snmp system checks if the access points are all alive and sends a mail in case any of them is not. So it would be great if it would be like "accesspoint_lobbybar" instead of just the ip adress in the notification mail. Is this possible ? Thx thafener

I like the contact info Contact Info Email:     pfsense@gmail.com Website:     http://www.pfsense.com Office:     The Internet

There is no "bash" though I assume you really just mean mean "shell". On pfSense it defaults to tcsh/csh. Don't try to add users from the command line (and if you lookup how to do it on FreeBSD you'd see there are many ways to do it, especially the pw command). Just add them from the GUI. Also I wouldn't expect that user to stick around indefinitely, especially if you're using an embedded install. Perhaps if you explained what you are really trying to accomplish you might get some more constructive feedback.

For the first you need one of 2 things. A switch (and network interface) that supports VLANS Two LAN interfaces For the QoS please look at the traffic shaping forum (and read the documentation).

@alanlai88: If I want fxp1 bridge with fxp0, fxp1 will use DHCP automatically because of fxp0 is using DHCP, am I right? DHCP will be enabled on fxp1 when fxp1 is bridged to fxp0 and DHCP is enabled on fxp0. DHCP on workstation B is configured entirely independently. @alanlai88: Firewall rule on fxp1 already set to any to any. There are more than two parameters in a firewall rule (protocol, source IP, source port, destination IP, destination port etc). Firewall rules described as "any to any" won't necessarily pass DHCP requests. For example, protocol=TCP, source IP=any, source port=any, destination IP=any, destination port=any won't pass DHCP traffic. Also, preceding rules are important because the first rule to match a packet determines what happens to the packet. I suggest you reboot workstation B, see what IP address it has and if the IP address is in the DHCP range. If the IP address is out of the DHCP assigned range take a look in the firewall log (Status -> System logs, click on the Firewall tab) to see if the firewall blocked the request.

Set static DNS servers e.g. 4.2.2.1-6 in General Setup. it should solve the problem I'm doubting missing DNS info would cause the whole connection to fail at most DNS lookups would have issues but not ip connectivity

Hi again Think I found most of the answers my self. Found how many sessions I had running on the System Overwiev page…

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.