That commit has been reverted due to breaking working things, as already noted on another thread.

Most (like 99%) DHCP clients do provide a hostname. Only a few of them show up in the table once expired though. So, only a few of the hostnames provided are remembered. Not a big deal, just a strange detail.

SOLVED: Turns out the issue was on my Win2K8 R2 machine. I had placed both DHCP scopes under a superscope which is not required when using VLANs. I moved the two scopes out of the superscope and now I am obtaining the correct IP addresses from the DHCP server.

@wallabybob:

@phil.davis:

So I am not sure why it does not work for you.

Perhaps because when pfSense WAN interface has private IP address it doesn't closely track the real public address, polling checkip.dyndns.org only once a day at 1am if I reall correctly.

Good thought - I forgot to say that I edit the cron job /usr/bin/nice -n20 /etc/rc.dyndns.update so it runs/checks every 5 minutes. (Install Cron package so you can make persistent edits to cron jobs like this) That gives ~5 minute response time to changes of public IP on my ADSL front-end.

He has a crazy setup - did you get away from the 3G connection yet?  And get a real connection?

Let me TV in again and will get it fixed up.  Send me the info, its a friday - hopefully pretty light at work today I should be able to find time.

Hi again,

I think I have tracked down my misconfiguration.

When I converted this network to VLANS the vSwitch in vmware lost it's "accept promiscuous packets" setting.  After going in and setting VLAN A interface (this is the one openvpn is assigned to) to accept promiscuous packets then the packets began to flow as I remembered before switching to this VLAN configuration.

Apologies for the false alarm.

Yes? Configure two separate DHCP pools?

All fixed, thanks, there was some good tips here.

I had configured the alix radio to have a clone interface and I left that disabled. problem was that the firewall still blocked that interface. You must either fully config with IP, DHCP, firewall rules etc or completely remove the clone. The randomness must have been the clone grabbing the packets with sometimes the main WIFI getting them

also had to add a firewall rule to allow UDP 68/67 from 0000 to 255.255.255.255, strange as I didn't need to do that on the LAN.

I don't think this is the original posters problem, problem sounded the same but in the end mine was specific to wifi, not the second interface

You'd best do this on a dedicated Linux or Windows server, assuming the DHCP relay functionality works fine.

What do you mean by "unable"?

If it's anything like Workstation, you just choose the physical adapter and a VMnet to bridge in the standalone network configuration tool.

You should consult the manual for a more definitive explanation than my guess: Untagged ports means switch doesn't send VLAN tags and doesn't expect to see VLAN tags on received frames on those ports and Tagged ports means ports on which the switch includes VLAN tags on output and expect VLAN tags on input frames. Therefore I expect you should make port 1 Tagged on VLAN 10 and port 2 Untagged on VLAN 10.

@rider641:

Indeed, after obtaining an IP address using DHCP, the device loses it after a few minutes and never seem to get a new address.

Sound like a device problem: what sort of device - phone? tablet? PC runinig …?\

What does the pfSense DHCP log say around the time a device "loses" its allocated IP address? What does the corresponding device log report?

Well I have not internal DNS server, I use those provided by ISPs I have three different ISP with different DNS Servers, If I manually configure IP in my laptop with each of these ISP and change LAN rules to send all traffic from my laptop through respective ISP gateway the domain resolves correctly.

If I put pfsense as DNS server in manual configuration It resolves wrong.

My question is what could I check in order to verify how dns is working?

Thanks.

On GitHub, BSDperimeter changed to pfSense a while ago. So the link is now:
https://github.com/pfsense/pfsense/commit/8d8f00903f5fe8992cc84ea2cbbc778492038957

"All I am really trying to do is create a DNS entry for our upstream proxy so if the IP changes in the future we just have to edit our DNS entry rather than manually change the proxy settings on the clients."

For the ability to point clients of one type or another to some distant server with a changeable IP, consider using some sort of dynamic DNS service at the server side.  In your case the proxy server side.  Thats how most people handle servers with dynamic IPs.

@jimp:

Manually naming them won't be an option.

On 2.1 they do include the actual interface name, now, so they're easier to interpret.

Interface name would be perfect  :D

@jimp:

pfSense 2.1+HAproxy-devel + Browser SNI support will let you distinguish based on the hostname, but that's probably as close as you'll get.

Thanks for the replies, guys. Also, the information regarding SNI.

The NAT rule along with a Firewall rule permitting this is currently working for external users. But I will definitely look into HAproxy and its features as an option for the future.