DNS dynamic updating no go on second lan interface (wireless)
-
Well here is the problem. Our current environment we have a Windows Server 2003 box running as DNS and DHCP server. Now on the main LAN interface everything is working perfectly. The problem we are having is clients are unable to perform dynamic dns updates on a seperate interface from LAN (The second interface is for all wireless traffic). In the arp tables and the dhcp server table, you see the clients registering, but not the full hostname, just the computer name, so instead of brianscomputer.wireless.tribalfiles.net, it's registering just brianscomputer. When we route traffic between the different subnets first, it functions correctly, so i'm definitely missing something within the pfsense config. I hope this hasn't been answered before because i spent all day search for a similar problem on the forums. Hopefully i'm just an idiot and missing something simple here.
Thanks again all…
-
What system is providing DHCP for the second subnet (the wireless one) and what DNS do these clients use?
-
The same Windows Server 2003 box we have in our lan zone. We use the dhcp relay option within pfsense.
Regular dns is fine, as far as resolving ip address to domain names for websites, etc.
The lan subnet is 10.1.1.x
the wireless subnet is 172.20.1.x -
Can you show us an ipconfig /all from one of the clients?
-
Absolutely.
Windows IP Configuration
Host Name . . . . . . . . . . . . : briansdesktop
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : wireless.tribalfiles.netEthernet adapter Wireless Network Connection:
Connection-specific DNS Suffix . : wireless.tribalfiles.net
Description . . . . . . . . . . . : Linksys Wireless-B USB Network
Adapt
er v2.8
Physical Address. . . . . . . . . : xx:xx:xx:xx:xx:xx
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 172.20.1.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.20.1.1
DHCP Server . . . . . . . . . . . : 10.1.1.10
DNS Servers . . . . . . . . . . . : 10.1.1.10
Lease Obtained. . . . . . . . . . : Sunday, October 14, 2007
6:45:56 PM
Lease Expires . . . . . . . . . . : Sunday, October 21, 2007
6:45:56 PM -
I think your clients are missing the primary dns suffix. Not sure why they don't get it assigned currently but you probably could fix it by hand when editing the advanced settings on the clients tcp/ip protocol, dns tab.
One thing that you might want to try is setting the domain at system>general correctyl, save the settings of the dhcp-relay on the webgui again and release and renew the leases on the client. Does that help?
-
Unfortunately not..
The lan clients see basically the exact same output of ipconfig /all, as far as dns suffix search list and connection specific dns suffix, but no primary dns suffix and it works perfectly… Now we can fix the problem by going into the tcp/ip settings, dns tab, and select the option to "use this connections dns suffix in dns registration". Then it works normally, but we are trying to avoid having to go to each clients computer and make this change..
-
Maybe it's a problem with your dhcp server then?
-
So there is no missing rule or anything that would be needed to make this possible?
-
Don't think this is rule related but my client gets the primary dns suffix assigned from our dhcpserver at work which is a windows box.
-
really? i was always under the impression that the primary dns suffix was an option that was configured only on the client end, although im probably wrong, but i do not see this as an configurable option on the server side.. I know it gets the dns suffix from the DNs domain name option..
-
Do you have anymore suggestions for me hoba, or anyone else.. I'm almost positive it's not related to the primary dns suffix (not to doubt your expert advise). It handles fine when communicating through a cheap router, i.e. linksys, etc. Only acts screwy when passing through pfsense to talk to the lan interface.