It might be possible to craft the right pf rule, but you'd have to invoke that in a script or something.  Can I ask what you are trying to accomplish?  Not meaning to offend, but folks here are basically providing free tech support, and I for one would rather not invest a significant amount of (unpaid) time trying to help someone massage pf in a way that makes no sense.

Correct.

@jimp: Squid puts in a pass rule for the proxy when transparent proxy is enabled, and no rule you enter manually can override this. Ok, that sounds like a pretty crucial note then, I'll put it in my pfS book somewhere.

@flanandorj: 1.2.2 built on Thu Jan 8 22:30:24 EST 2009 Upgrade to 1.2.3-RELEASE and then try again. If you still have issues, then someone might be able to help you further.

Glad it is working now ;-)

It worked perfectly!!!!!! Thx a lot

I have two settings different from the screenshots shown for Virtual IP and NAT.  First, on the Virtual IP page I have "Other" marked and not "Proxy ARP".  Second, on the NAT setup I have the radio button for "Manual Outbound NAT" clicked and not the "Automatic" button.  Don't know if that will fix you or not, but except for those two, your settings and mine look the same.  Mine is working as posted earlier in this thread. One other thing to double-check.  Under Interfaces..WAN, make sure "Block private networks" is unchecked.

UPDATE –----- I have now uninstalled Lightsquid (must be uninstalled before Squid otherwise there are errors and uninstall fails..) and Squid and after a few reboots it seems that my block rule is working as intended. Obviously Squid is in a number of situations a problem, I have to do some rethinking when it comes to if and how I should use the Squid package then. Any thoughts and comments welcome.

Thank  You! You've been very helpful  :D

OK, thanks for that. These are all ESXI VM's so i guess i will just have to add some more networking in. "you'd just need a port forward on LAN that redirected any port 80 traffic NOT going to the pfSense box's LAN IP' Is this right? Surely this would mean that the redirect would not redirect the HTTP traffic and it would continue on through the pfsense box. Or am i being dumb, which is more than possible!! Cheers Gareth

I have been running one in Xen Server for 3 months now with no issue. Just make sure to reset the states when you make firewall changes.

You do not fail PCI compliance for having an open port on your firewall.  Port 53 is DNS, and if you run your own DNS servers, you must have this port open inbound.  You need a real PCI assessment, not some free automated scan.

ok, i didn't know about the netmask in UK, im from mexico, and me neither be sure if the doc applies to wan but i try everything to resolve my situation, and seems that there are many people with your same problem in the forum, anyway, good luck

Thanks again Efonne. I've now got everything working the way I planed it. I don't think a have a use for scheduling yet, but I see how it could come in handy. Thanks for the help again and bye

The squidGuard package appears to offer this functionality, although I've never used it. I like squid though.

Hi, the dummy static route is, so it seems, the only working solution for that problem. Now there is a static supernet route that covers every subnet. Its not the best but a working solution. The thing is, I think I will stay at static routes on my pfSense because neither RIP nor OpenOSPFd are getting along with PPPoE resets :( Edit: The dummy static route has another major downside with it. It generates a routing loop whenever one of the supernet advertised subnets is down, because the next hop router has the pfSense as default gateway, which is correct because it is the internet gateway. The packets are bouncing from the pfSense to the next hop router and back again until the TTL is 0. If OSPF would be running, the network would have been eliminated out of the routing table and the request would get a "network is unreachable" or something similar. Or am I wrong? To OSFPd the second: The process is stuck after every PPPoE "redial" no matter it is caused by periodic pppoe resets or manual reconnect. After being stuck it start a new ospfd instance. When you remove the OpenOSPFd package, the other started processes are not killed and running until you kill them manually.

sweet!

You need both a port forward and a firewall rule. This troubleshooting page might be of use: http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting As well as the Port Forwarding tutorial here: http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F