The slingbox is basically embedded into the Dish reciever.  It's off the LAN interface, same network as my desktop PC's. Thats why I'm so confused..  :)

ok, it is fine if you have one LAN but with multi LAN i find this setup not very good :-( because it is necessary to think after adding new network to aliases and create new rule to block traffic between LANs

Alright, I fixed the problem. The other issue being I can't make it DMZ, and when I attempt to connect to the web server (via port 80 from LAN) it won't work. Example : Attempt to visit the servers web page (port 80) but it won't work - But people outside (WAN) CAN get to it. When I try to ping from Orange to LAN it rejects it, but I couldn't fix that even though I set everything to allow.

The issue with lighttpd is only DoS of the web interface itself and since that should never be open to the Internet and can't really do any harm we didn't release an update for that. 2.0 has the latest, and disables the ciphers it's noting.

All is good, I got it working. Thanks anyway.

PF is not pfSense…. pfSense uses PF. http://en.wikipedia.org/wiki/PF_(firewall)

nope, no rule

Running pfsense as a transparent bridge would certainly work but it's a far more difficult configuration to achieve. If you've done some research you'll have found posts from people struggling to get it right. If you feel confident try it. Steve

The pfsense boxes are physical, the servers in the subnet are VMWare virtual machines.

ANSWERS…. Hello all... Well it looks like I have solved the issue!  Actually I did not need to setup vlans on pfsense since my switch handles all that.  It was merely to set static routes for each vlan and it worked like a charm!  I really appreciate all the help and hope this helps someone else out there!! Sean

That has to do with how if_bridge and pfil function, sometimes rules from LAN can apply in your scenario rather than OPT1 rules, and vice versa. To make sure it's consistent you assign the LAN to bridge0 rather than the physical interface, or just configure your OPT1 rules the same as your LAN rules.

So finally i removed HAVP package ,i was working in HAVP transparent mode that where causing rule not to be apply correctly on that specific network destination.

Usually em-drivers is for intel nics right?, then i think that should work. but don't assign ip for physical interface, assign ip's for vlans

Hi Jimp, Thanks for the answer, yes i wanted to make two rules in one (access the internet but not local lans),i found out that only one LAN is permitted from all Lan's list alias i dont know why is the reason PF letting communication to this LAN although i am sure i written CIDR correctly 21x.14x.23x.0/24 , i did tested and i saw clearly that firewall block to other LANS and i created rul pass all and disable the other rule and i can access other LANS in other hand when i disable both rule i can't acces any LAN'S so that mean that something in the alias doesn't work regarding 21x.14x.23x.0/24 LAN. Any idea? Thanks btw version is 2.0-RC3 (amd64) built on Tue Jun 21 23:08:07 EDT 2011 [image: net_rule.PNG] [image: net_rule.PNG_thumb]

@cmb: @MikeN: It's really a problem I can't reliably filter traffic based on source/destination interfaces. If I allow traffic to 'the internet' (which I can't specify with an IP range), I immediately allow traffic to all other interfaces and not just the gateway interface….. Easy, just block or reject what you don't want to permit (most commonly with an alias of local and VPN-attached networks, if not all of RFC1918) above allowing destination "any" for required Internet traffic. That is an option, but: It's error prone. If in the future new IP ranges get added to interfaces, I will have to make sure that these get blocked too. I rather have something closed/secure by default, instead of the other way around. It's quite some work if you got multiple interfaces. I still have to look into the floating rules (running 2.0-rc3 here), and where they're added in the pf ruleset, so maybe floating rules can resolve this issue…

Got it. Thanks for the suggestions cmb :). It was the default gateway that my my dhcp server on the opt1 was handing out. I had it set to 192.168.1.108 for some reason. Brain fart I guess. Maybe this will help you too Snowman58. Time to start playing with cloning the wireless :).

Because the Internet is basically "any" destination, there isn't anything you can specify for "Internet" other than any. If you want to restrict those rules, add block or reject above them.

yes, randomize port setting is not checked off and I've set it to that specific port