Allow access to "destination: !LAN" (not LAN) If you have multiple LAN's you could create an Alias which contains all your LAN's and set the destination as !yourAlias (not yourAlias)

mad shit :D

Hi Gruens, Thanks for the reply, I did get it wrong thanks for pointing that out. The situation is that we can have to set all the inbound firewall rules on the WAN interface, but would much rather move the rules "backwards" a step by allowing all traffic through on the WAN and having firewall rules per VLAN. That way we can just plonk new servers/subnets into the relevant VLAN and it inherits all the rules without us having to add rules for each subnet individually. Hope this makes sense and I hope someone has a bright idea on how to get this working ;)

hm…. someone pls say something  ???

tried a fresh config, 2nd LAN works fine now, thank you very much for the help. i've been testing pfSense for a week or so and the support here as well as the features are most impressive.

I ended up redoing the pfsense box. All's fine now.

Use OpenDNS as your DNS instead of your ISP's.  There you can block those domains through the control pannel. http://www.opendns.com

Fixed! ;D  There was no rule on the outbound NAT. ::)

System -> Advanced has an option for disabling offload Csum.  Might be worth a shot to enable that option.

http://forum.pfsense.org/index.php/topic,7001.0.html

I think you need to find out what they're doing that allows them to do that.  Are you shaping by protocol, by IP, or have you just not got it configured correctly ;) I'd raise this in the Traffic Shaping sub-forum.

A google search on " ddos protection +freebsd " turns up http://www.webhostingtalk.com/showthread.php?t=647542 http://silverwraith.com/papers/freebsd-ddos.php Maybe not the solution your sicking but anyways a good read imo.

The 1-1 NAT is pretty hard to screw up. A typical entry would be: interface=WAN external IP=100.200.100.200/32 internal IP=192.168.1.200/32 The AON if you were using port-forwards would be like this: interface=WAN source=192.168.1.200/32 * * * NAT address=100.200.100.200 * NO (AON rule must be placed before the auto created LAN rule)

I continued to have problems with my CIDR notation matching the subnet provided by my ISP for my DSL connection… since this didn't appear to make any sense at all, and everything else was working on the firewall, I reconfigured the WAN for my new internet connection (not the old DSL circuit), set my IP to the new IP/29 (as it should be), and put it into production.  All is working as it should be now. As was suggested by others here, and on #pfsense on IRC, this must have been something flaky with my ISP and/or DSL connection.  Though I didn't get to the root cause, my DSL circuit is now off-line and everything is working as it should be on the new internet connection.  Thanks to everyone for the assistance!

I dunno if this was the way to solve this, but i did tried creating a firewall rule in the WAN interface blocking all type of ICMP traffic to it. Well now PING for IP and DDNS name do not reply at all (=good). If thare are other correct solution please feel free let me know, thanks.

@GruensFroeschli: Your entry is wrong. Look at the screenshots i attached. Also make sure your clients use pfSense as primary DNS @GruensFroeschli Thank you soooooo much. I have been trying to figured out why i didn't see my own web server ;)

I can try :) You say that server with ip 192.168.3.97 get block in firewall when trying to send to ip 147.249.x.x and the problem it's only with ip 147.249.x.x As you don't have a host directly connected to pfSense with the ip 192.168.3.97 something must publish that ip to pfSense.

FYI we found another solution to our SIP problem. Just enable NAT keep alive on the client device