Hi All - Since my last post, I restarted snort BUT with the "block offenders" checkbox unchecked.  Having this checked wreaked havoc on my system.  I have been running smoothly for 32 hrs. I decided to keep SBS running DNS and DHCP. WAN = DHCP from Comcast LAN = Static 192.168.20.0 LAN DHCP = 192.168.20.2 SBS 2003 Server     IP Addresses excluded 192.168.20.1 through 192.168.20.9     IP Addresses excluded 192.168.20.100 through 192.168.20.238 DNS Server (General Setup) = 192.168.20.2 with none selected Thanks to all who replied - Brad

Pretty sure ISC dhcpd's method of assigning IPs has never changed, it's worked the way you describe it as working currently for at least 15 years, back when I started using it. Our config of it has never changed. Maybe you had reservations setup? Or something different at least, not sure what that could be. Short of assigning reservations, or changing the method you use for distributing load, don't think there's an alternative there.

None of that is indicative of someone trying to get into your network. dnsmasq re-reads /etc/hosts whenever a system inside your network gets a DHCP lease or renews one, as it has to do to maintain correct name resolution. Nothing there is unusual aside from having two dhclient PIDs though that can be normal in some unusual circumstances (like two NICs plugged into the cable modem to pull multiple IPs).

Just as a follow up, I submitted this change for review and it has been committed in github. https://github.com/bsdperimeter/pfsense/pull/69 It should appear in the next release of pfSense.

Good call Wallabybob.Thanks I just configured the trunk port. For the people who uses Cisco switch, I am pasting trunk port configurations #configure terminal #interface interface_id #switchport mode trunk #switchport trunk encapsulation {isl | dot1q} #end #show interface interface-id switchport #copy running-config startup-config

Enable NAT reflection. (check the doc wiki)

@cmb: Sure, you can add/remove fields there, just use javascript to show/hide as needed. I believe that's already done for some other providers, or at a minimum it's done in other areas of the GUI. CMB, I redid my implementation a created a new pull request: https://github.com/bsdperimeter/pfsense/pull/71 I hope that i implemented it in correct way this time, or i will give up  ::) Have a nice weekend Edson

netbios broadcast for names would use be udp port 137 yes..  So yeah if you want to resolve netbios names via broadcast then the broadcast address and that port would have to be open ;) xp and 7 still use this port.  This is the name service part of NBT, used for name registration and resolution. Yes MS awhile back added SMB over TCP which uses 445.  But I am not 100% up to speed how the name resolution works over that, I believe its more dns based using that port.  I don't believe it ever does broadcast over that port for resolution. I requested info on what package you installed sure, so I could duplicate what you have done if you were still having problems getting it to work.  But I personally don't have any need for it. I have been out of the windows support arena for a few years now, more just pure networking last few years.  So I am loosing some of my windows based info that use to be right off the top of my head. And since your working no need for me to install it ;)

We've had a few buglets like that over the years. Is that forwarder entry the only entry in the list? Usually with that kind of bug it has an issue removing the last item in the list, but adding/deleting additional entries works normally.

@trunix: Hmmm, the name registration propagation delay was something I hadn't considered.  Are we talking seconds, minutes or hours? If I recall correctly, one of the FAQ style pages on Dyn.com or OpenDNS.com suggested it could be of the order of minutes rather than hours. But I think that was for name changes to propagate to their own servers. It could take longer for changes to become visible in other servers.

Not a simple one really. Easiest would be to backup your config.xml, edit out the old dhcpd config for opt1, then restore it.

oh that's right, dhcrelay has to bind to the interface facing the server as well, and it doesn't support tun interfaces apparently.

Thanks, I just PM you regarding this issue. I will reply on this thread as soon as we get official response from RIPE regarding reverse DNS.

To sort by IP change the following line in /usr/local/www/services_dnsmasq_edit.php:       return strcasecmp($a['host'], $b['host']); to         return !ip_less_than($a['ip'], $b['ip']); This will sort by IP in increasing order.  Allowing a list of multiple names to be entered for the same IP is trickier because they will need to be exploded into an array, then checked individually against the existing names, which may also be a list which may need to be exploded if not stored as an array already, and checked. I don't understand the underlying data structure well enough to be sure that I'm not going to damage it by changing the 'host' element to a linear array or a space delineated list of elements.  Fortunately, space is not a valid host name component (look at the mess created by GNU make because it can't figure out if a file name has a space in it).  Nor am I confident about editing such a list.  Is there any overall guide to the data structure used by pfSense? Thanks, Andrew

I see now from interfaces_staticarp_configure($if_)_ that staticarp actually has nothing to do with dhcpd whatsoever.  It simply cribs the MAC & IP pairs from the dhcpd configuration and uses them after issuing: ifconfig $if staticarp arp -d -i $if -a which disables ARP discovery on interface $if, flushes all the existing entries, and then repopulates the ARP table with: arp -s $ip $mac Which can totally bone you if you have not prepared by entering any MAC & IP pairs.  Other than the cryptic warning, I think it would be nice to explain that this has nothing to do with DHCP, and means disabling ARP discovery for that interface.  Perhaps in the Note: or in pop-up help. But all that still doesn't explain why IP addresses must be used instead of the FQDN? Andrew

@hexcentric1: several LAN clients simply do not acquire a dhcp address from pfSense, while others do. The main problem is some routers will not acquire an address, and some PCs and Macs will not acquire an address. Does pfSense see the DHCP request from the systems which don't acquire an address? (See Status -> System Logs and click on DHCP tab)

@cmusicfan05: I checked off those two options you suggested. ("Register DHCP leases in DNS forwarder" and "Register DHCP static mappings in DNS forwarder") It is not clear to me if enabling those registrations enables registration of already existing DHCP leases and DHCP static mappings OR registration of NEW DHCP leases and NEW DHCP static mappings. That said, host overrides and DHCP static mappings in DNS forwarder work for me in pfSense 2.0.1 and 2.1. If you are trying the name lookup on Windows system please post the output of the Windows shell command ipconfig /all

I added another dns-server patch to the bug reported here: http://redmine.pfsense.org/issues/1768 This fixes a problem with local domains not being setup correctly for dnscache. Dynamic DHCP leases still do not get registered with DNS though.