Thanks Derelict i will give this a go

rob

Maybe option to spoof MAC in VIP could be an option??

It will work in an access control capacity (with squidGuard) but only if you are careful about how they are configured.

They are not compatible with caching or logging on ALIX using NanoBSD

what client, sure you can create suffix search lists.. Is the OS of your client and can point you to the correct method.

I removed that same line and it started working here as well. Apparently using that config directive indicates that dnsmasq should not forward if the query is unresolved.

Thanx Much,
Garth

@kejianshi:

….
Probably had their best two TRS-80s acting as server.

WTx
I remember those !!!!!

Woow, man, thanks. That was a huge 'blast from the past'  ;)

Ok, I will test that.

no worries, thanks for taking the time to walk through it with me!

I don't have any x86 installs to check, but I would imagine that you could likely replace any instance of -amd64 with either -i386 or -i586.  On your PfSense box, hit the console, press 8 to get a shell and then do:

cd /usr/pbi
ls

and see what it's really called.

Some further investigation seems to suggest this is really a problem with our wifi rather than pfsense. We're able to access the host when connected directly into our distribution layer but on wifi we see the connection issues.

Thanks for your reply all the same.

whatever domain you want to use, you can use single label if you want pc1.locadomain - I just am not a fan of it..

As to why something didn't answer broadcast, firewall comes to mind.  if wireless AP isolation comes to mind or just dropped traffic.

pc1.riahc3.mydomain works as well.. The possibilities are pretty much endless.

doing \pc1 should work just fine - again understanding name resolution is the KEY!! To troubleshooting such issues you might run into.  Most clients will use different methods be it windows, os x, linux, bsd, beOS, etc. etc.  You just need to understand what order and which ones your clients use when you want to resolve host names.

I created 3 VLANS.
1 10.0.0x
2 172.16.1.x
3 192.168.1.x

Lan1: 150 static mac addresses + static address (and dynamic adress 10.0.0.200-10.0.0.210)
Lan2: ~50 static mac addresses + static address (and dynamic adress 172.16.1.230-172.16.1.240)
Lan3: DHCP disabled.

In LAN2 any komputer from LAN1 are not configured. Why, when i connect any komputer from LAN1 to LAN2 i get adress from dynamic range adress eg 172.16.1.231
The same situastion is in when i connect computer from LAN2 to Lan1.
I would like to these networks were totally separated. In my opinion it should not be.

thanks for the feedback,

I will continue with my current network structure.

Thanks jimp!

I stuck to just using the allow mac address control and it worked the way I was expecting.  For some reason I got it in my head that the deny unknown clients needed to be checked for mac address control to work.

The results of trying pfSense 2.2 snapshot (pfSense-2.2-DEVELOPMENT-1g-i386-nanobsd-upgrade-20140711-1504.img.gz) are:

The problem is still existent.

The frequency of occurrence seems to be reduced.

The last statement is weak. Due to lack of time my test was run only over 2 sessions each comprising 2 days. Session #1 had no problems, #2 experienced one loss of DHCP lease. Unfortunately I already moved from the respective site and will not return before december. For reason of stability I replaced pfSense with the o.m. combination of a Raspberry Pi and a TP-LINK router. So at present I am not able perform further tests.

colleagues,

I'm willing to let the pfsense, DHCP and DNS control.
In my current network structure use Windows Server as AD and DNS.
The pfSense is behaving very much like DHCP server, and honestly see no problem with leaving the pfSense as a DHCP server.

If anyone has instructions for configuring tinydns in pfsense because I like to test it as the primary DNS server.

Hugs to all

Just a quick update.. I still can't get the system to forward anything other than ICMP requests, but I think I've found something else. It looks like for some reason pfSense is assigning the same adapter name (em0) to both my LAN and GUEST adapters! This would definitely explain what's going on! I'm going to try and find another adapter with a different chipset and report back!