When the firewall allows a connect through it also constructs a temporary rule specific to that connection, to allow the back traffic. I don't know the details of how windows explorer discovers the shares. Its possible the server attempts to create a new connection (or more) back to the client. These new connections would be blocked by the rule I suggested. If you have logging on the OPT1 rule then any attempt by the Windows server to establish a "back connection" to the LAN should appear in the firewall log and the information logged will allow you to add firewall rules to allow these back connections. But I don't recall reading a description of the security policy for OPT1; you might want something much more relaxed.

I tested it by looking at the Bandwidthd report :)  when I add them as individuals, the report has the names.  When I used the domain as the exception, it listed the IP and said to config DNS to resolve the IP. I am sure I tried rebooting the box, but I will try again and report back.

@ampwifi: I was wondering if dhcpd will remove the broadcast from the available ips or do I have to exclude it? I wouldn't tempt fate. Even if you experiment and find dhcpd does remove genuine broadcast addresses for the available list I would be cautious about expecting that behaviour to continue into the future. I haven't tried this: its possible the WEB GUI will prevent you including a genuine broadcast address in your DHCP range.

Add an example address or two, then download a config backup from Diagnostics > Backup/Restore. Edit that config.xml file and you'll see where they go and what format they need to be in, and then you can script something (perl, php, some other macro language) to put in your list in the proper format. When you're done, restore the backup and it should have all the entries.

Yes, it is unchecked.

Okay, thank you for a quick reply jimp.

If you can still reproduce the same problem on a 2.0 snapshot, then it may be worth reporting, but so many things have changed with 2.0 (especially with bridging) that it's hard to say if that can still happen.

@Cry: Did you remember to power the cable modem off before you connected the pfSense host? If I recall correctly, I have seen reports that it is necessary to power of the cable modem for sufficiently long for power supply capacitors to drain and force a cold restart. A momentary power dip may not be sufficient. @subar: My internet connection is a DHCP Comcast cable connection through a Scientific Atlanta 2100 DSL modem. Did you mean "cable modem" rather than "DSL modem"? Have you looked in the system logs for traces of dhclient activity (see web GUI Status -> System logs? (dhclient is the application that talks to a DHCP server to get configuration information.) Here's an example of a dhclient report on my WAN interface Dec 27 06:09:24 dhclient[4423]: connection closed Dec 27 06:09:24 dhclient[4423]: connection closed Dec 27 06:09:24 dhclient[4423]: exiting. Dec 27 06:09:24 dhclient[4423]: exiting. Dec 27 06:09:24 dhclient[10226]: DHCPREQUEST on udav0 to 255.255.255.255 port 67 Dec 27 06:09:25 dhclient[10226]: DHCPREQUEST on udav0 to 255.255.255.255 port 67 Dec 27 06:09:25 dhclient[10226]: DHCPACK from 192.168.37.21 Dec 27 06:09:26 dhclient[10226]: bound to 192.x.y.z -- renewal in 129600 seconds. I think I've seen reports that in some (as yet ill defined) circumstances dhclient in pfSense 1.2.3 exits and doesn't restart, leaving the system with nothing actively requesting DHCP configuration so none is provided.

Ok, thanks!

finally found it, for all port forwards i just created a NAT rule that would auto generate the firewall rule….. well turns out i did that for the VPN which was crashing the DHCP server over and over when people tried to connect to the VPN, even when i turned it off. Been running fine for over a week now with no problems and plenty of normal traffic on the VPN. just thought i'd close the loop on this one incase someone else ever bone head's it too.

I made the CoreSwitch on the Client-site be the DHCP Relay and everything workes flawless. This is acceptable for me, however, since I am going to rely on pfSense for a big data center / outsourcing project with several sites attached in the future, I would appreciate if someone can point me to what happened here. I am otherwise very happy with this product but this leaves a bad feeling without knowing what was going on. The articel (http://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F) explaines to me why a static route was needed to get the packets into the tunnel (even though I would be very appreciative for more details on this "issue", which seems to be by design), but I don't really get why the packets go into the tunnel and disappear on the way back. Also, is there a way to debug traffic inside the ipsec-tunnel? Probably not using a packet sniffer since the traffic is encrypted, but is there some other, possible ipsec related, logfile etc. to tell me when and why packets get dropped and for what reason?

Okay, I have logged some more on this issue. The appliance we use (from applianceshop.eu) is using the network cards: VIA VT6105M Rhine III 10/100BaseTX, 3 of them. Every hour this passes by in the system logs: Dec 6 09:54:43 dhclient[57082]: bound to xx.xx.xx.xx -- renewal in 3600 seconds. Dec 6 10:54:43 dhclient[57082]: DHCPREQUEST on vr1 to 195.130.132.102 port 67 Dec 6 10:54:43 dhclient[57082]: SENDING DIRECT ... Dec 6 10:55:36 dhclient[57082]: DHCPREQUEST on vr1 to 195.130.132.102 port 67 Dec 6 10:55:36 dhclient[57082]: SENDING DIRECT Dec 6 10:55:50 dhclient[57082]: DHCPREQUEST on vr1 to 255.255.255.255 port 67 Dec 6 10:55:50 dhclient[57082]: DHCPACK from 81.82.zz.zz Dec 6 10:55:51 dhclient[57082]: bound to xx.xx.xx.xx -- renewal in 3600 seconds. Dec 6 11:55:50 dhclient[57082]: DHCPREQUEST on vr1 to 195.130.132.102 port 67 Dec 6 11:55:50 dhclient[57082]: SENDING DIRECT ... Dec 6 11:56:33 dhclient[57082]: DHCPREQUEST on vr1 to 195.130.132.102 port 67 Dec 6 11:56:33 dhclient[57082]: SENDING DIRECT Dec 6 11:56:52 dhclient[57082]: DHCPREQUEST on vr1 to 255.255.255.255 port 67 Dec 6 11:56:52 dhclient[57082]: DHCPACK from 81.82.zz.zz Dec 6 11:56:52 dhclient[57082]: bound to xx.xx.xx.xx -- renewal in 3600 seconds. On a similar setup (same provider) but with Linux and using the parameter "supersede dhcp-server-identifier 255.255.255.255;", I see this: Dec  6 12:04:29 fw dhclient: DHCPREQUEST on eth4 to 255.255.255.255 port 67 Dec  6 12:04:29 fw dhclient: DHCPACK from 81.82.zz.zz Dec  6 12:04:29 fw dhclient: bound to yy.yy.yy.yy -- renewal in 3592 seconds. Any workaround to get the same behaviour on pfsense 1.2.3 ? Cheers, Kristof.

how can pfsense auto update opendns with out i manual update it, i need pfsense auto update the ip every change of ip in router with out i do any thing and what the use of wildcards? thanks

Some alternative 4 port PCI cards: lan1641 and lan1741 from http://www.soekris.com If buying second hand a card with Intel PRO/100 (fxp) NICs would probably be a good choice. I think a number of the major computer suppliers have produced multi-port network cards with Intel chips under their own brand (HP, COMPAQ etc). A cheap (US$40) 5 port VLAN capable switch is the RB250G: http://routerboard.com/pricelist.php?showProduct=101 I have no experience with any of the above products.

@ashrocks: but there is no way i can put a MAC address and assign a static IP for that drive to be accessed from my computer which is on the same network. My home network has four computers wired to a switch which is wired to the LAN port of my pfSense box. Each of the four gets an IP address from DHCP running on pfSense and the IP address is keyed off their MAC address. @ashrocks: I don't know if that network drive sends out a DHCP request. Its probably overdue that you found out if the drive is supposed to get IP configuration from DHCP (or can be configured to do so). If the drive doesn't send a DHCP request then I don't know how pfSense will give it an IP address based on its MAC address. If the drive is supposed to send a DHCP request then you should be able to see the DHCP request logged in the DHCP log on pfSense (unless you are running a fairly recent snapshot build of 2.0 BETA) or in a packet trace.