@johnpoz: Well not so much that its impossible - just how you would do it is 2 segments.  Where each segment has its own dhcp server with its own scope. Can't you just post some info for your "cats" ;) to find that tells them wireless clients are on different segment and to allow 172.16.x.x/23 in their firewalls? With a bridge your going to be under 1 broadcast domain, so all the broadcast traffic of all your clients will be going over your wireless..  With a /22 – I assume there are lots of users, that could be a hit on your wireless performance without any users actually even on the wireless.. Only other issue I could see other than their firewalls would be how do they resolve other hosts, if they broadcast for them - then yeah segments is going to put a nix on that as well and you would have to use dns, wins or IP address or some other way to resolve hosts they want to access that are not on their local segment. Good luck and let us know how it turns out. Yeah, I'm not dealing with savvy users.  (I'm talking about the kind of people who need filesharing, but who's eyes will glaze over if I even say the word firewall). I'll switch over to using a bridge, one DHCP server, and static leases for as many as I can.

@thermo: If your phones are on the same network as your computers then you cannot give them a different option to the computers. If this is problematic in your scenario then you should setup a separate voice vlan exclusively for your phones. But 2.1.0 can do it this way … is only the question if such feature is risky enough to update from stable to beta ;) SNOM telephones can also request per Broadcast SIP configuration (also on wiki pages mentioned).... so done in Gemeinschaft 3.1. There is an init script: https://github.com/amooma/GS3/blob/master/etc/init.d/gs-sip-ua-config-responder which starts the daemon: https://github.com/amooma/GS3/blob/master/opt/gemeinschaft/sbin/gs-sip-ua-config-responder/gs-sip-ua-config-responder so you need only a little change in this daemon to get your data right in ;)

That did it.  Like I said…DNS-Stupid.  At least now I understand NAT Reflection.  :) Thx john.

Going to a larger network is the easy way, I went with a base address of 172.16.0.1 for my pfSense LAN and a net mask of /22 so I had plenty of addresses available and I could assign IPs in groups that made sense. I put the DHCP dynamic assignments at 172.16.3.1 with 250 some addresses available it works for now. If I need more space giving DHCP a larger space is no problem, expansion is as easy as changing the /22 mask to something between /21 and /12 and then adding the newly available addresses to the DHCP dynamic range. Just make sure the base address you pick has enough room above it to meet any future expansion needs, the old class A or B RFC 1918 base addresses work well for that. 10.0.0.0        -  10/8 prefix     172.16.0.0      -  172.16/12 prefix I avoided the whole 198.x.x.x range after I got tired of devices getting a hard reset defaulting to that range or having hard coded addresses in that range and causing conflicts.

If you have your DHCP configured correctly, (failover peer set and sync dhcpd checked) they will not issue leases in use by the other server. Verify your DHCP status shows normal on both units. The DHCP server will show as issued from one of the physical boxes, this does not impact failover, as the other box will issue leases if one is offline.

@cmb: You should be able to use a domain override in that case, that rule doesn't apply to domain overrides. That's much safer than just disabling the DNS rebinding checks entirely, though you can do that under System>Advanced if you really want to. Have I got this right? Just override all DNS queries to the problem domain to…some outside DNS server. I can give that a try in a hurry. DNS rebinding! That's the term for it. I knew I'd read about it somewhere. Probably in The Book. No, I'd rather employ the work-around than disabling DNS rebind checks. Thanks for the tip.

^ as stated your going to need a "smart" or fully managed switch to be able to do vlans, so that you can isolate your different network segments. How many switches do you currently have?  Depending you might be able with just changing our your "core" switch or the upstream switch connected to pfsense that supports vlans and then connect dumb switches downstream as long all devices connected to those switches are to be in the same segment/vlan If not then your going to need switches that support vlans through the building - this allows you to put a device no matter where it sits in the building on whatever vlan you want.

Ok, so it took awhile until I ran into this again, but here are my results. It does seem to be TTL related, as it did resolve itself around the 5 minute mark, however there are still issues that may need to be looked at. The nslookup queries from below are not the only tests I ran, so any delayed results as mentioned previously should most certainly have resulted in a correct response later. Both upstream dns servers configured on the pfsense device returned correct results, albeit slightly newer. I didn't manage to grab a sniff of the traffic before the issue corrected itself, but I will make sure I do that first thing the next time this pops up. C:\Users\Mikuki>nslookup Default Server:  UnKnown Address:  10.20.20.1 > mail.google.com Server:  UnKnown Address:  10.20.20.1 Non-authoritative answer: Name:    googlemail.l.google.com Address:  2607:f8b0:400a:801::1016 Aliases:  mail.google.com > server 8.8.8.8 Default Server:  google-public-dns-a.google.com Address:  8.8.8.8 > mail.google.com Server:  google-public-dns-a.google.com Address:  8.8.8.8 Non-authoritative answer: Name:    googlemail.l.google.com Addresses:  2607:f8b0:400a:800::1016           173.194.33.21           173.194.33.22 Aliases:  mail.google.com > server 10.20.20.1 Default Server:  [10.20.20.1] Address:  10.20.20.1 > mail.google.com Server:  [10.20.20.1] Address:  10.20.20.1 Non-authoritative answer: Name:    googlemail.l.google.com Address:  2607:f8b0:400a:801::1016 Aliases:  mail.google.com > set type=aaaa > mail.google.com Server:  [10.20.20.1] Address:  10.20.20.1 Non-authoritative answer: Name:    googlemail.l.google.com Address:  2607:f8b0:400a:801::1016 Aliases:  mail.google.com > set type=a > mail.google.com Server:  [10.20.20.1] Address:  10.20.20.1 Non-authoritative answer: Name:    mail.google.com >

Yep, I did that code for 2.1 a while ago and it works. To get that feature you can: Upgrade to 2.1 then change your Dynamic DNS provider name to "No-IP (free)"; or Look at the code in https://github.com/bsdperimeter/pfsense/pull/436 and backport it to your 2.0.n system; or as you say, change dynamic DNS provider.

Random guess: If any of you had the OpenVPN tap fix package installed, it didn't work properly on 2.0.3 (until the version I just uploaded), so if you had a tap VPN with a blank tunnel network, it was really misrouting most of the internet causing traffic to fail. If that was in use on your system, remove the package and install it again, and it should be OK again.

Final followup… I found zabbix-proxy2(2.x) wasn't backward compatible with zabbix-server(1.8.x) so I ended up removing zabbix-proxy2 and re-installing zabbix-proxy1, this caused the fping issue again. So: pkg_info | grep fping pkg_delete -f fping-2.4b2_1 fetch http://files.pfsense.org/packages/8/All/fping-3.4.tbz pkg_add fping-3.4.tbz For some reason, "/usr/local/etc/rc.d/zabbix_proxy.sh restart" did not work correctly, so use stop and start separately. Sorted.

Here are my settings for DNS-O-Matic Disable - unchecked Service type - DNS-O-Matic Interface to monitor - WAN Hostname - all.dnsomatic.com MX - blank Username - DNS-O-Matic login name Password - DNS-O-Matic password Description - anything you'd like here

I have exactly the same issue with No-IP (using ADSL with 24h disconnect). Upon the scheduled disconnect the logfile looks like this Apr 21 02:14:13 pfsense php: : DynDns: updatedns() starting Apr 21 02:14:13 pfsense php: : DynDns debug information: XXX.XXX.31.201 extracted from local system. Apr 21 02:14:13 pfsense php: : DynDns: Current WAN IP: XXX.XXX.31.201 Cached IP: XXX.XXX.25.7 Apr 21 02:14:13 pfsense php: : DynDns debug information: DynDns: cacheIP != wan_ip.  Updating. Cached IP: XXX.XXX.25.7 WAN IP: XXX.XXX.31.201 Apr 21 02:14:13 pfsense php: : DynDns: DynDns _update() starting. Apr 21 02:15:28 pfsense php: : DynDns: DynDns _checkStatus() starting. Apr 21 02:15:28 pfsense php: : DynDns: Current Service: noip but the cached IP within the GUI shows in red and is in fact the old IP given by the ISP. When checking the dashboard I can see that "Current WAN IP" is correct within the logfile, but somehow pfsense doesn't manage to update to the new IP properly.

Going to Interfaces->LAN and changing the /24 to /23 gave me the additional range I need. No idea it was so easy. If you do have any IPSec entries, take note that you should modify them before hand as expanding your network breaks the connectivity. Off to finish fixing them. Thanks for the help.

Did the restart thing several times, played with tftp and bootp settings on the 'LAN' I guess I have no choice but to diagnose through packet capture but it is clear that pFSense is responding to a request that it should not so the PXE boot / TFTP load process fails, I'm just really short on free time to play with this and have had no choice but to configure a Microsoft DHCP / DNS until such time as I can get back to this - the PXE / TFTP process now works correctly so pFSense is definitely the problem. As you can imagine this is brutally hard to diagnose and keep a system live whilst doing so.

Thank you man… sometimes it's the little things that get you :) anyway, one thing leads to another... I have a question... how do I act as a man-in-the-middle? can I make pfSense, at least at the DNS level, to reply to PING requests without actually contacting the address. I got the idea when I was asleep ;D and also when I noticed how I sometimes get PING replies (usually unrealistically low time) when I know for a fact that the connection is down

Aha that basically takes dnsmasq configuration options. Thanks! Although the pertinent question still remains, why would you allow it to listen on the WAN by default?