Not what I was hoping for  :)
But seems reasonable to me, thank you very much!

I can traceroute and use DNS diagnostics on teh web GUI, however any machine (PC, MAC, Net Drives) can not access the internet.  I tried even manually changing the DNS settings to the workstions/desktops to Google DNS 8.8.8.8, that did nothing.  Traffic is not allowed i smy guess.

I've tried restoring from a month old configuration which was saved before the upgrade… no difference.

I'm new tyo pfSense and was not the original installer - I inherited this along with the new client.  Any help here would be greatly apprecioated.  I'm about to try resetting to factory defaults =, test then restore again the configuration.

Erick

@phil.davis:

I wonder if there is an issue here even when using Automatic NAT. Does pfSense correctly add NAT rules for the extra "virtual" subnets that it finds on LAN? You can check that by looking at /tmp/rules.debug and search for "nat". There should be an outbound NAT section that includes references to your 10.0.0.0/16 subnet.

I was using Automatic NAT, and this is what I found (It did not reference the 10.0.0.0/16 network):

cat /tmp/rules.debug | grep 'nat'

no nat proto carp
nat-anchor "natearly/"
nat-anchor "natrules/"
tonatsubnets    = "{ 10.13.0.0/16 127.0.0.0/8  }"
nat on $WAN  from $tonatsubnets port 500 to any port 500 -> 192.168.222.189/32 port 500
nat on $WAN  from $tonatsubnets to any -> 192.168.222.189/32 port 1024:65535

so I did a generic any to any on the WAN adapter, like the attached photo, and it works like a charm now!!

fw_nat_outbound.jpg
fw_nat_outbound.jpg_thumb

We have some sites that have a "real" server (Dell PowerEdge etc) with dual power supply, RAID… that were bought some years ago, and suck 100-125 watts! Plus "ordinary" desktop-size servers that draw around 55 watts. These use way too much power to leave on through 6-9 hour gaps in mains power. Yes, I will be glad to be not dependent on them ASAP.

We are in the process of moving to the Fit-PC3, 9 or 10W. So, along with Alix board pfSense 6W, and a TP-Link (4-port Gb ethernet switch+WiFi AP) 6W, and a front-end ISP device (ADSL modem, WiMax device...) 6-8W, we will be able to keep a core network running for 30W total. With a couple of 80W solar panels and suitable battery/s it can be off the mains completely. This will allow the Windows domain controllers to stay up 24/7 and talk to each other across OpenVPN all night - finally we will be able to sync big files to/from head office at night and so on.

Until that is installed everywhere, I will try the workaround DNS stuff - it sounds like @joako has done it with success.

I've restarted the install from scratch to make sure that there are no errant settings hanging around. I'll write this post as I configure it up.

I have the following NIC setup in VMWare:

VMnet 0 (my main real LAN that goes to the internet), 2 and 3 are mapped to the pfSense router VM, in that order.

Once I install, run the config and set the static IPs on pfSense I get the following:

Any machine on the LAN interface can now see the router and get to the web. They have the following config:

I setup the NIC for the machine in the OPT1 network like so:

Any machine on OPT1 cannot do a jot. There were no firewall rules setup, so I added the following, which replicated the LAN rules, apart from the anti-block for port 80:

Now the LAN subnet can still get to the internet. The OPT1 subnet can ping the router, ping LAN addresses and get to the internet. It also resolves names into the AD DNS.

??? ???

So that's everything that I wanted it to do. It is now working exactly as I wanted. Go figure.

I've just added another OPT2 NIC for the 192.168.102.0 network and followed the same approach and that's working a treat.

Thanks for your help. I think it was down to the reset states. I probably had the right config at some point yesterday, but it didn't register properly as I hadn't done that reset and therefore I had assumed it hadn't worked.

I can get on with the real work now. Thanks again for your help…

The source address field was added on 2.1, but you can get the same effect using advanced options and removing the current domain override. Make sure to remove the current domain override, so the advanced option one will take effect.

server=/domain.com/x.x.x.x@y.y.y.y

domain.com is the domain to override, x.x.x.x is the DNS SERVER IP, and y.y.y.y is your LOCAL source IP.

@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.