thank you both. I will do it this afternoon, and post the result later. Thanks again for the very quickly response. ;)

We have noticed the exact situation on our firewall. Network : –-------- DNS (.4)  <--------------> (LAN) PFsense bridged (WAN) (.2) <---------> Internet The "DNS query" is send from the DNS through our firewall. The source packet is like "natted" from IP address .4 to .2. (natting has not been activated on our firewall) Is this a bug ? Or a setting ?

http://doc.pfsense.org/index.php/Unable_to_Access_Some_Websites

@jimp: There is no bug. I configured a VM in this manner, testing Deny Unknown clients and Static ARP, and it worked as expected. If you have "deny unknown clients" checked and you are still getting an IP on machines not listed on the DHCP server page, you might have another DHCP server on your LAN or some other misconfiguration. It's also possible you need to reboot the router after checking static ARP, as a machine may have still been in the router's ARP cache and I'm not sure if that gets flushed when switching to static ARP. well, it seems you are right, after i reboot pfs and all switches … it seems that now works fine, it still gives IP address, BUT  it does not pass any traffic ;)

I think what you're looking for is a static route.  Something like: interface:  lan network:  your-remote-net/netmask gateway:  your-lan-ip

Just confirmed it in a VM setup… set deny unknown clients, and I can't pull an IP address from pfSense, but I can set a static IP. Then if I set static arp, I can't even talk with a hard coded IP address. Just as expected.

Check all of your DHCP settings on every tab. Ensure that your DHCP ranges are set to the proper subnets for each interface.

As a followup to my own post, apparently the DNS forwarder (dnsmasq) does not work with a DHCP failover configuration.  In a DHCP failover configuration, both DHCP servers are actively issuing leases and dnsmasq only sees the leases issued by the local host. I do not see a solution to this problem.  In fact, the dnsmasq man page doesn't even seem to indicate that this mode of operation is possible (i.e. registering leases provided by a separate DHCP server process).

I am by no means an expert on DHCP failover; however, the ISC dhcpd.conf manual page states the following: The  failover  protocol  allows  two  DHCP  servers  (and  no more than two) to share a common address pool.   Each server will have about half of the available IP addresses in the pool at any given time for allocation.   If one server fails, the other server will continue to renew leases out of the pool,  and  will  allocate  new addresses out of the roughly half of available addresses that it had when communications with the other server were lost. Thus if one server fails, the second should still issue new leases from half of the address space.  Whether or not this is working correctly in pfSense, I cannot say. I gave up on using DHCP failover with pfSense as it will not work with dnsmasq/DNS Forwarder.

Thanks for the reply. The point of this is that I can plug my laptop into the cable for gigabit speeds when I want, but I don't lose connections when I decide to go wireless. When the cards have different IPs and I disconnect the cable, I lose all the connections for a while even though the wifi is already connected. I do have an update though; it seems that this was not the problem that is causing the connection to be dropped. I only had one connection on all night and still it got disconnected. There were no more such messages in the log, since I only had the wireless connection on, so something else must be going on. Any ideas where to look?

Have a look in the DHCP log: From the web GUI, Status -> System logs then click on the DHCP tab. Depending on how long your system has been up and how many DHCP requests have been serviced you may see the startup messages from the DHCP daemon (dhcpd). You should see "action" records like Jan 18 19:37:45 dhcpd: DHCPDISCOVER from 00:12:7b:46:e7:65 via vr0 Jan 18 19:37:45 dhcpd: DHCPOFFER on 192.168.211.240 to 00:12:7b:46:e7:65 via vr0 Jan 18 19:37:45 dhcpd: DHCPREQUEST for 192.168.211.240 (192.168.211.173) from 00:12:7b:46:e7:65 via vr0 Jan 18 19:37:45 dhcpd: DHCPACK on 192.168.211.240 to 00:12:7b:46:e7:65 via vr0

I believe there are enhanced dynamic dns features in pfSense 2.0 (compared with 1.2.3). Perhaps what you are looking for is already in 2.0. (I don't have any experience of pfSense 2.0 yet).

Attempted that, did a flushdns, tried a totally different website that is blocked on my WAN IP, still no success. DNS trace shows that it is using the WAN IP for DNS queries. Any other way? Thanks

@wallabybob: I've had another look at this. There is a problem in your LAN firewall rules. When a system is powered up it doesn't have a IP address so the source IP address in the DHCP request will be 0.0.0.0 which is not on your LAN. Hence the DHCP request won't match your first rule. Sorry, this shouldn't be a problem. I checked against the pfSense book last night and firewall rules to allow DHCP traffic are need on bridged interfaces so I need them on my home network where a wireless LAN is bridged with a wired LAN and I want DHCP service on both wireless and wired LANs. I need firewall rules to allow DHCP on the wireless LAN but I don't need them on the wired LAN.

Thanq you very very much. Your solution is working perfectly. Best regards

This is not easily possible in 1.2.3, but some people have edited the DHCP server page to accommodate this (search the forum, you might find some patches) This is already possible in 2.0, and you can set any arbitrary DHCP option number you want.

This has been asked and answered multiple times, really, some searching should have turned it up. The alternative is to make your WIFI interface your LAN and bridge the wired OPT1 port to it instead of the other way around. It's a little trickier to configure, but you don't have to worry about what is or is not plugged in.

well inability to ping your WAN IP from outside isn't an problem per-se, since that is disabled by default.  can you post your interface config, NAT rules, etc…