DHCP Not Assigning Correct IP on LAN
-
Hello all, I couldn't find a resolution in my searching through the forum so Im posting this issue in the hopes that someone here has the answer.
Recently Ive started having problems with connectivity on my network. I have been running PFSense for nearly a year without issue and now my machines are having problems with IP address assignment on my LAN.
My xbox 360 will not initially receive the correct IP on the network. I have to go into network connections and reset the network to factory defaults and then it will refresh the IP to the correct format of 192.168.1.*, otherwise its initially an ip on an entirely different subnet.
I also have a NAS that will not recieve the correct ip through DHCP
I also have several pcs connected to the LAN via a dd-wrt router that is configured as an access point and a DHCP forwarder. When I initially connect to this I am forced to do and ipconfig /renew to get a valid ip that will give me access to the internet and the LAN if I do not do this I cannot access either.
Any help with this issue is greatly appreciated.
I have included my settings below I hope this is enough information.
I have the 1.2.3-RELEASE with LAN, WAN, and DMZ as the connections.
LAN Settings
– No Bridge
-- IP Settings 192.168.1.112 / 24-RULES
– RULE1
Proto/*
Source/LAN net
Port/*
Destination/*
Port/*
Gateway/*
Schedule/
Description/Default LAN -> anyLAN DHCP Server Settings
Subnet 192.168.1.0
Subnet mask 255.255.255.0
Available range 192.168.1.0 - 192.168.1.255
Range 192.168.1.10 to 192.168.1.100WAN Settings
-Set To Default Settings
– DHCP
-- Disable the userland FTP-Proxy application
-- Block private networks-RULES
– RULE1
Proto/*
Source/RFC 1918 networks
Port/*
Destination/*
Port/*
Gateway/*
Schedule/
Description/Block Private NetworksDMZ Settings
– Static
-- No Bridge
-- IP Settings 192.168.2.111 / 24-RULES
–RULE1
Proto/*
Source/*
Port/*
Destination/LAN net
Port/*
Gateway/*
Schedule/
Description/Block DMZ from LAN--RULE2
Proto/*
Source/DMZ net
Port/*
Destination/!LAN net
Port/*
Gateway/*
Schedule/
Description/Block DMZ from LANDMZ DHCP Server Settings
Subnet 192.168.2.0
Subnet mask 255.255.255.0
Available range 192.168.2.0 - 192.168.2.255
Range 192.168.2.10 to 192.168.2.100 -
otherwise its initially an ip on an entirely different subnet.
I've seen a number of bits of Microsoft gear assign themselves an IP address on a subnet assigned to Microsoft (and beginning 169….) when they don't get a reply to a DHCP request.
I don't recall the details, but there are some contexts where enabling DHCP server on an interface is insufficient, its also necessary to have firewall rules allowing DHCP traffic. Have you checked the firewall log to see if your forwarded DHCP requests are being blocked by the firewall? Have you checked the DHCP log to see if any forwarded DHCP requests are seen by the DHCP server?
-
I've seen a number of bits of Microsoft gear assign themselves an IP address on a subnet assigned to Microsoft (and beginning 169….) when they don't get a reply to a DHCP request.
Actually the 169.254.x.x range doesn't belong to Microsoft. This is a special subnet that all DHCP clients may fall back to when they can't get a lease. See RFC3330:
169.254.0.0/16 - This is the "link local" block. It is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.
I'd start with a packet capture in this instance. Is the DHCP server receiving the request? Is it sending a reply?
My Xbox gets a lease without issue from Pfsense 1.2.3 release BTW, but I don't have a DMZ setup.
One thing I've seen interfere with some poor DHCP clients that don't retry long enough is a managed switch with spanning tree that puts the port into blocking mode for ~ 30 seconds.
-
I've had another look at this. There is a problem in your LAN firewall rules. When a system is powered up it doesn't have a IP address so the source IP address in the DHCP request will be 0.0.0.0 which is not on your LAN. Hence the DHCP request won't match your first rule.
Have you checked your firewall logs to see if DHCP requests are being blocked?
Did you upgrade your pfSense software recently? What version are you now running?
-
I've had another look at this. There is a problem in your LAN firewall rules. When a system is powered up it doesn't have a IP address so the source IP address in the DHCP request will be 0.0.0.0 which is not on your LAN. Hence the DHCP request won't match your first rule.
Strangely, there is no user-created rule required to do this. This goes to a minor nit of mine. I was working with siproxd last night, and after turning it off discovered a hidden rdr was still active. I hope that in pfsense 2.0 there's an advanced view of the pf rules that is available. I don't mind that parts of it are managed by the GUI, but I'd still like to see them (and I think ultimately we'd want to have every rule exposed for manipulation by advanced users?)
Over the weekend I did a fresh install of 1.2.3-RELEASE. I didn't have any reason to touch the rules on the LAN interface, so they appear just as the OP's default rule does in his web interface. But in reality, there are quite a few hidden rules:
# grep \$lan /tmp/rules.debug pass in quick on $lan proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server on LAN" pass in quick on $lan proto udp from any port = 68 to 192.168.0.1 port = 67 label "allow access to DHCP server on LAN" pass out quick on $lan proto udp from 192.168.0.1 port = 67 to any port = 68 label "allow access to DHCP server on LAN" pass out quick on $lan proto icmp keep state label "let out anything from firewall host itself" pass in quick on $lan from 192.168.0.0/24 to any keep state label "USER_RULE: Default LAN -> any" #Only the very last rule in the above is shown by the web interface. But they are all active. I used pfctl to check that:
# pfctl -s rules | grep -i bge0 pass in quick on bge0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server on LAN" pass in quick on bge0 inet proto udp from any port = bootpc to 192.168.0.1 port = bootps keep state label "allow access to DHCP server on LAN" pass out quick on bge0 inet proto udp from 192.168.0.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server on LAN" block drop in on ! bge0 inet from 192.168.0.0/24 to any block drop in on bge0 inet6 from fe80::211:11ff:febd:64b4 to any pass out quick on bge0 proto icmp all keep state label "let out anything from firewall host itself" pass out quick on bge0 all flags S/SA keep state label "let out anything from firewall host itself" pass in quick on bge0 inet from any to 192.168.0.1 flags S/SA keep state label "anti-lockout web rule" pass in quick on bge0 inet from 192.168.0.0/24 to any flags S/SA keep state label "USER_RULE: Default LAN -> any" pass in quick on bge0 inet proto tcp from any to 127.0.0.1 port = ftp-proxy flags S/SA keep state label "FTP PROXY: Allow traffic to localhost" pass in quick on bge0 inet proto tcp from any to 127.0.0.1 port = ftp flags S/SA keep state label "FTP PROXY: Allow traffic to localhost" # -
I've had another look at this. There is a problem in your LAN firewall rules. When a system is powered up it doesn't have a IP address so the source IP address in the DHCP request will be 0.0.0.0 which is not on your LAN. Hence the DHCP request won't match your first rule.
Sorry, this shouldn't be a problem. I checked against the pfSense book last night and firewall rules to allow DHCP traffic are need on bridged interfaces so I need them on my home network where a wireless LAN is bridged with a wired LAN and I want DHCP service on both wireless and wired LANs. I need firewall rules to allow DHCP on the wireless LAN but I don't need them on the wired LAN.