Well, port that pfsense was plugged into need to be in trunk mode. From there it was a matter of taking it step by step. Initially we couldnt get any subnet to communicate with the pfsense box. We had to actually add the subnets to the lan interface. Once we could get vlans to communicate with pfsense it was just a matter of figuring out NAT. NOTE: Automatic NAT does not work/would not work in our situation. Has to manually do it.         1:1 NAT also would not work had to stick with NAT port forwarding. Things are good now, internally geting out we have noticed a 50% increase in speeds.

I'd hate to have things in perpetual beta though.  We'll probably be having the same discussion about something else when 2.0 is released.

Thank you for your reply ! This rule has a lot of option.. this is the following one, right ? [image: 14Anonyme-20091229-143533.png] Do you can tell me more about this option ? what does it mean, implies ? I will try as soon as possible with IPTV, thank you again.

I'm not surprised, and I'd personally discourage such development. I just sent the customer a long list of workarounds. #0 is "fix the brokenness you see first". They complain this particular server is "finicky". No wonder. I also could put the device into bridging mode and probably get the behavior back, since the Cisco is on the other end still terminating a T1. Or I could setup some OpenVPN tunnels bridging. It's gonna hurt if I have to do any of that. I even came up with a solution to the most serious consequence (broken VPN) that only involves adding a couple more specific static routes to the more important servers. So many workarounds  ::)

There is lagg(4) support in pfSense 2.0, which is still Alpha (but will be Beta very soon).

Ah, a voipo customer :)  I just ported my number out of them.  Not from unhappiness, but because they made a (totally understandable) business decision to not support BYOD customers, which I am an extreme example of :)  I am using the freepbx service which uses bandwidth.com.  voipo worked fine with pfsense, but the other service got confused due to the source RTP ports being rewritten, hence my need to use the static_port directive.

Oh thanks for your idea, It is realy clear to me. Thanks again.!

I had similar checksum errors early on when I first started using voip through my pfsense box. In my case it turned out to be what I thought to be an apparent faulty nic. (Realtech-  I know I know… I see now...)   Since replacing the nic, my voip systems have been rock solid. And no more errors. May not be related but I figured Id mention it...

@Dave: I've seen this same thing with Chrome on one of my Macs (but oddly, not on another).  I resolved it by using the Clear Browsing Data… option to clear everything. That worked :). Sorry pfSense mods!

Having just come back from a very frustrating day at work, this sounds like the best thing I heard today. Thanks man, I'll look into this.

thx for reply. On log no one answer for Who kill it, just exiting on SIGTERM (kill -SIGTERM dnsmasq)… Is there some log more specific on shell that I get more answer like /var/log/messages (OS linux like)? This happen third time with me, I´m thinking this problem happen just w/ specific hardware, cause in my T300 (DELL) this not happen w/ 30 users. Regards, Heitor Lessa

Why not a Vlan capable switch with the license server on default Vlan and PFsense with one Vlan'ed interface and loadbalanced WAN?? Then you can define exactly what kind of traffic that is allowed to pass through the different segments.

@danswartz: sounds like something got corrupted. reinstall?  i would recommend 1.2.3. Yep, thanks. Did the trick… once I fixed the machine post-upgrade. I blame this more on my old dodgy hardware rather than pfsense though.

what is strange is that im having the same pfsense log with or without spoofing the mac (I always have the NIC mac adress) maybe the spoofing is not working after all  ??? ??? plus in the 2.0 ALPHA the WAN mac adress is no longer shown in "Satus"-> "Interfaces" as previous versions.. can u put back guys ? ;) [image: nomac.jpg] [image: nomac.jpg_thumb]

If you don't have much load, the load balancing won't be equal because of the way slbd functions. The first connection every 5 seconds goes to one server, so if you only have 1 connection or less every 5 seconds, you'll never hit the other servers. As your load increases, it becomes balanced, so slbd's quirk isn't really a problem, it balances when you actually have enough load to need load balancing. And failover will remove that server from the pool so you have redundancy. Once you have a decent amount of load (20 or more connections per 5 seconds) the balancing equals out. I don't think that's detailed in the wiki, it is in the load balancing chapter of the book. http://pfsense.org/book

If you dont have a rule to allow it: yes it will be blocked. There is another entry in the drop-down: "any" If you dont have a rule allowing any, then the protocols not specifically allowed, will be blocked.

There is some support for 3G devices in 2.0. I don't recall the specific models supported, however.