Hi, I'm thinking the exact sequence of commands is probably a factor.  Sorry I don't have more detailed logs or config files to diff (I've restored by normal config to get my ADSL working again). Since there were changes in this area for 2.1, perhaps we should ignore this bug for now, unless other users can provide better information. Best wishes for the new year. Martin

Here's how I deal with the incomplete implementation of DHCP Client. Screen shots and old 2.0 patch here: DHCP Client Additional Custom Options Patch http://forum.pfsense.org/index.php/topic,40194.0.html 2.1 patch here: Advanced DHCP Client Options & Config File Override   Protocol Timing   Send Options   Request Options   Require Options   Option Modifiers https://github.com/bsdperimeter/pfsense/pull/275 Optional config override file example from 2.0.1. # Actiontec MI424-WR Router Impersonation # ISP: Frontier FiOS # Router Make: Actiontec # Router Model: MI424WR-GEN2 # Router HW: Rev. F # Router FW: 20.12.2.4 # pfSense 2.0.1 (FreeBSD 8.1) #interface "de1" { interface "{interface}" { # DHCP Protocol Timing Values timeout 60; retry 1; select-timeout 0; initial-interval 1; #bootp-broadcast-always; # Bootp flags: 0x8000 (Broadcast) # DHCP Protocol Options send dhcp-class-identifier "Wireless Broadband Router"; # Option 60 ## Hard Coded Class Identifier send dhcp-client-identifier ""; # Option 61 ## Blank to Prevent Send #send host-name "Wireless_Broadband_Router"; # Option 12 ## Hard Coded Host Name send host-name "{hostname}"; # Option 12 ## Obtained From Web Configurator (WAN Hostname Setting) send domain-name "home"; # Option 15 ## Hard Coded Domain Name # V-I Vendor-specific Information # Option 125 ## Hard Coded MAC #send option-125 "\x00\x00\x0d\xe9\x1f\x01\x06000FB3\x02\x0c00180160EB84\x03\x07MI424WR"; #send option-125 00:00:0d:e9:1f:01:06:30:30:30:46:42:33:02:0c:30:30:31:38:30:31:36:30:45:42:38:34:03:07:4d:49:34:32:34:57:52; # V-I Vendor-specific Information # Option 125 ## Obtained From Web Configurator (WAN MAC Address Spoof Setting) #send option-125 "\x00\x00\x0d\xe9\x1f\x01\x06000FB3\x02\x0c{mac_addr_asciiU}\x03\x07MI424WR"; #send option-125 00:00:0d:e9:1f:01:06:30:30:30:46:42:33:02:0c:{mac_addr_hexU:}:03:07:4d:49:34:32:34:57:52; # Parameter Request List # Option 55 ## Hard Coded Parameter Request List #request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, time-servers, log-servers, default-ip-ttl, interface-mtu, vendor-encapsulated-options, dhcp-requested-address, dhcp-lease-time, dhcp-server-identifier, dhcp-parameter-request-list, dhcp-class-identifier, dhcp-client-identifier, www-server, option-125; request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, time-servers, log-servers, default-ip-ttl, interface-mtu, vendor-encapsulated-options, dhcp-requested-address, dhcp-lease-time, dhcp-server-identifier, dhcp-parameter-request-list, dhcp-class-identifier, dhcp-client-identifier, www-server; require subnet-mask, domain-name-servers, routers; # These are required by the client script "/sbin/dhclient-script"; }

Not directly related to the OP in this thread but it's quite similar: If your upstream DNS does not return NXDOMAIN on failure, but rather returns an IP for its oh-so-helpful (not) search page instead, you can see similar failures to resolve DNS in the expected order. If you resolve host "www.google.com" (no trailing .) and it tacks on the domain, "www.google.com.example.com" and your upstream DNS returns a response record for that, it will use that IP. OpenDNS does this, so their landing page IP 67.215.65.132 may turn up in your DNS responses. DNS needs to see the NXDOMAIN to continue the search, so if you can switch off that option in your upstream DNS that's best, failing that, change to an upstream DNS server that does return proper NXDOMAIN records. Another similar failure can happen if you use wildcard DNS for your domain.

It's working! I installed a new nic in the PCI slot.  I was using the onboard MB nic before for opt1.  apparently it was crap.  Thank you for all your assistance on helping me figure out it was a hardware issue.

If you worked with the other dyndns code, is it somehow possible to trigger the detection of the external WAN address and write that to a file? That whould help, as it could be written to the nsupdate file.

@bradenmcg: In my area, Time Warner will issue up to 3 IPs (free) on my tier of service. How are these IPs allocated? On request by DHCP? Do the requests need to come from different MAC addresses? Perhaps there is a single IP address and you can use an additional two on the same subnet? @bradenmcg: I guess I could work-around by plugging the cable modem into my (managed) switch and using VLANs and OPT interfaces to get the additional IPs without requiring more physical interfaces on the pfSense box… But I'd have to treat them like a multi-WAN setup, which it really isn't - just multiple IPs that I'd like to be able to use as alternate sources / rule options for "WAN." How do you envisage that would work? Without more details of how this "issue up to 3 IPs" happens it is difficult to answer your questions. Will these IPs be very dynamic? If so, what would be the use of using them as "alternate sources for 'WAN'"?

@Nonsense: Ah, I tried the setup quickly, early this morning, when I was in a rush.  I retried it again and discovered that I had neglected to configure the "destination" changes in the rule this morning.  It appears to be working now–I'll find out if it still works the next time I reboot pfSense.  Thanks ptt and johnpoz. :) Bad network admin.  Fixed/hardcoded IPs on clients are bad juju.  pfSense can do DHCP reservations - use them.  DHCP makes your life much easier.  Why do you want your life to be difficult?  ;D

Oh, I overlooked the fact you said it's only attempts that's triggering Snort, I thought you actually had responses going out. Generally the requests will come in at a rate adequate to peg your upstream, which you'd notice, and your states show you aren't actually responding. What you're seeing is just typical Internet noise that you can't do anything about. Usually such attempts are targeted at IPs that are known to be running an open resolver, so if you have a dynamic IP that's recently been assigned to you, it's likely someone else was running an open resolver on that address previously. Sometimes they're just blindly fired though. You just have to ignore things like that, nothing your ISP is going to be able to do or even cares about, and nothing you can do about it. You're blocking it. This is a good example of why I usually don't run Snort on WAN or outside the firewall. Too much noise that you're blocking and hence don't need to care about. Snort generates enough noise without adding a slew of things you're blocking to the list.

OK I will try to make tests. Thanks. I´ve just notice that some firewall rules stop to work after returning to original factory and recover the backup. For example my rule to send all packages on the 443 port to my wan link (to not use loadbalance because access to banks). Thanks and regards

Perhaps you have multiple DHCP servers on your network. Perhaps you have another system with IP address 192.168.1.188

I quit running squid after I reset to defaults, but by that time the disk was full. I ended up reinstalling because I was already at near zero configuration. I am 100% sure that squid was culprit, or my configuration of squid to be exact. I'm guessing I added a digit when I was setting up the amount of disk space it could use for caching.

Does your dhcp server also do NAT for your network, or route your other devices that are on public IPs? pfsense is designed to be your networks gateway/firewall to the internet.  It can be used as just an internal router/bridge/firewall - but by default its going to expect your internet to be on its WAN, and then NAT all your devices to your public IP behind it. I am guessing your dhcp and if it does dns that is maybe a AD DC?  If so it should be behind your gateway/firewall - and you can just have it forward its external dns to pfsense, or outside for public dns.  And all your internal clients would still use it for your internal AD dns, etc.

If you haven't seen it: this might help you: http://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

I fixed this up on 2.1 last week https://github.com/bsdperimeter/pfsense/compare/752c6ca8117e05e6bb74115d2199dab7ff99168d…0a35ca7ccf198cfa6654ccc17741005a58cd6aee

How is this related to pfsense?  If you are having issues with server 2012 you really should be on a windows support board. But if your dc is on 192.168.7 – and then you hand out clients 192.168.50 addresses, how exactly do you think they are going to talk to 7.200 for dns?? If you want  to use .50.x as your range - then change your dc to be on that network, and I would assume your using pfsense as your gateway.  Its lan IP will also have to be on this .50.x network.

How many clients? If you have a lot of clients or a large amount of lease turnover, ALIX may not have enough RAM or space for the DHCP leases file to keep up.

On 2.1 you could (though it would be a bit cumbersome) setup separate DHCP pools and put in the list of MACs on one to allow and deny on the other, and they can have unique DNS servers that way. Of course that would only last until the kids figure out they can hardcode an IP/DNS or spoof their MAC and get around the restrictions. Separating them onto a distinct network is best, assuming they don't have physical access to the gear to switch themselves over to the other network… How much you need to worry about that stuff really depends on how smart/sneaky/crafty the kids are :-)

@esnakk: it seems Win XP "does something wrong" (not following standards/protocols correctly probably), When we connected a test-computer running Mac OS X everything worked fine. Not going to say that MS does everything by the RFC's - but come on XP at one point was what 80+ % something of the market share for OSes..  You can find this sort of info at  http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10 It currently shows still having 35% of the market – that is still a shit load of computers.  If it was doing something wrong that broke networks or didn't work with devices, etc.  It would be a pretty big issue and would of never gotten any significant share of the market.