Thanks for the updated information. I felt as if I was thrown in the deep end of the swimming pool when I started in networks. The learning curve seemed very steep.

An ongoing frustration I have with the reporting on this issue is that I have to keep asking for the same information. Two examples:

I asked for the IP addresses of the pfSense interfaces. I can't see them ALL on your diagram.

I asked for the ssh command you have been using to access the mail server.

Because the pfSense box on your diagram didn't have the interface names close to the box it took me a while to see them. It looks to me that WAN is rl0, OPT1 is rl1 and LAN is bfe0. Correct?

Realtek interfaces, especially the early rl interfaces, have a reputation for poor quality. Does your pfSense system log report anything involving rl0 or rl1?

There are two paths from client PCs to the mail server. Do you get different results for your ssh session depending on which path you use? (Try ssh to the mail server LOCAL IP address, ssh 10.10.0.146 and ssh to the mail server "public" IP address, ssh 69.29.44.19). Does either session last more than two minutes after login?

On the mail server, what brand and model of NICs are used? (post output of shell command lspci) Is there anything in the system log reporting any event on the nterfaces? Hopefully you don't have old generation Realteks there.

That was a known issue with 1.2.x, but has been fixed a long time ago in 2.0.

1.2.x won't be receiving any more updates, 2.0 is right around the corner.

@jimp:

For machines with static IPs, there is no way to automatically determine their hostname.

Well, this answers my question. Thank you.

Turns out with my old cable modem from Road Runner (ISP), each modem mac address would continue to fetch the same IP address.

With a new modem it fetches an IP address based on the mac address of the device attached to the cable modem.
Using the Settings > WAN interface an alternate MAC address in this setting will pull down a new IP address from the ISP.

Once again pfSense is doing its job without issue.

Hope this helps anyone as easily confused as I.

Hi Jimp,
  You were correct.  One of our ISP's was returning no results for every record our pfsense requested.  I switched the DNS server to a different machine and that resolved the issue.

Ah ok. I was, as you say reading it as a reservation as up until this point my experience had been building DHCP on Windows servers and the odd home router setup where that's generally how DHCP static assignments within your given range would work.

Thanks for clearing that up.
:-)

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.