Static IP Assigned Host Receiving IP Address From Other Interface
-
I have 2 networks set up on 2 different NIC ports on a 4 port NIC card. The 2 networks are as follows:
LAN - 192.168.163.1/24
IOT - 192.168.160.1/24The IOT interface was just configured and enabled a couple of days ago. The LAN was configured a long time ago and has always worked well. But I am having an issue with one of the hosts on the LAN interface.
The LAN DHCP has a server on it that is configured to have a static IP address of 192.168.163.25 assigned to it. Pfsense is currently showing that that server is online, but in addition the DHCP server for the IOT network is handing the server an additional IP address (192.168.160.101) out of the IOT DHCP pool. In both cases the MAC address indicated for the issued IP addresses is identical.
I've tried the following to resolve it:
-
Rebooting pfsense several times. The results are mixed. If I clear out the wrong IP address from the ARP table, then delete the incorrect DHCP lease, and reboot pfsense, only the correct static IP address is shown as online after the reboot and the other IP address does not appear in Status/DHCP Leases. But at some later time the wrong IP lease is reassigned and when that happens the server is no longer available on the correct network.
-
I've deleted the static mapping for the server in the LAN's DHCP server, then recreated it, then rebooted. I get the same results as indicated in the paragraph above when I reboot.
I really don't have any idea what is going on. I tried uploading pictures of my DHCP settings but I keep getting a server parsing error but here they are typed out (anything not shown is either unchecked or blank):
LAN DHCP Settings
Enable: Checked
Deny Unknown Clients: Checked
Subnet: 192.168.163.0
Subnet Mask: 255.255.255.0
Available Range: 192.168.163.1 -192.168.163.250
Range: 192.168.163.100 - 192.168.163.254
Gateway: 192.168.163.1Static Mapping
Mac Address: 00:15:5d:a3:0a:00
Client Identifier: RDServer1
IP Address: 192.168.163.25
Hostname: RDS1
Description: RDServer1
DNS Servers: 192.168.163.10 note: this is a windows domain AD Server which forwards to pfsense for non AD addresses)IOT DHCP Settings
Enable: Checked
Deny Unknown Clients: Checked
Subnet: 192.168.160.0
Subnet Mask: 255.255.255.0
Available Range: 192.168.160.1 -192.168.160.250
Range: 192.168.160.100 - 192.168.160.254
Gateway: 192.168.163.1Thanks in advance for any help.
-
-
@dma_pf said in Static IP Assigned Host Receiving IP Address From Other Interface:
The LAN DHCP has a server on it that is configured to have a static IP address of 192.168.163.25 assigned to it. Pfsense is currently showing that that server is online, but in addition the DHCP server for the IOT network is handing the server an additional IP address (192.168.160.101) out of the IOT DHCP pool. In both cases the MAC address indicated for the issued IP addresses is identical.
Just to verify I understood correctly:
So you're saying, that your Server RDS1 gets a LAN IP via DHCP (static mapping) correctly AND gets a IOT address on top of that therefore getting two IPs? Do the logs show that, too? E.g. do you see the DHCPxyz Command on LAN and IOT doing that?
-
@JeGr said in Static IP Assigned Host Receiving IP Address From Other Interface:
So you're saying, that your Server RDS1 gets a LAN IP via DHCP (static mapping) correctly AND gets a IOT address on top of that therefore getting two IPs? Do the logs show that, too? E.g. do you see the DHCPxyz Command on LAN and IOT doing that?
@JeGr Thank you very much for your help. Yes that is correct. Here is a portion of the DHCP logs filtered by the MAC address of the server. Please note that I mistyped the host name in my original posting...it is VM1RDS1 and not RDS1.
Aug 27 05:07:28 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 05:07:28 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 06:07:28 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 06:07:28 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 06:23:51 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 06:23:51 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 07:15:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 07:15:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 08:15:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 08:15:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 09:15:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 09:15:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 09:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 via em0 Aug 27 09:43:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 09:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em3: wrong network. Aug 27 09:43:39 dhcpd DHCPNAK on 192.168.160.101 to 00:15:5d:a3:0a:00 via em3 Aug 27 10:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 via em0 Aug 27 10:43:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 11:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 via em0 Aug 27 11:43:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 12:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 12:43:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 13:43:39 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 13:43:39 dhcpd DHCPACK on 192.168.160.101 to 00:15:5d:a3:0a:00 (VM1RDS1) via em0 Aug 27 14:19:37 dhcpd DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 via em3: wrong network. Aug 27 14:19:37 dhcpd DHCPNAK on 192.168.160.101 to 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPDISCOVER from 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPOFFER on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPREQUEST for 192.168.163.25 (192.168.163.1) from 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPACK on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 15:19:39 dhcpd DHCPREQUEST for 192.168.163.25 from 00:15:5d:a3:0a:00 via em3 Aug 27 15:19:39 dhcpd DHCPACK on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 16:19:39 dhcpd DHCPREQUEST for 192.168.163.25 from 00:15:5d:a3:0a:00 via em3 Aug 27 16:19:39 dhcpd DHCPACK on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 17:19:39 dhcpd DHCPREQUEST for 192.168.163.25 from 00:15:5d:a3:0a:00 via em3 Aug 27 17:19:39 dhcpd DHCPACK on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 17:30:08 dhcpd DHCPRELEASE of 192.168.163.25 from 00:15:5d:a3:0a:00 via em3 (not found) Aug 27 17:35:16 dhcpd DHCPDISCOVER from 00:15:5d:a3:0a:00 via em3 Aug 27 17:35:16 dhcpd DHCPOFFER on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3 Aug 27 17:35:16 dhcpd DHCPREQUEST for 192.168.163.25 (192.168.163.1) from 00:15:5d:a3:0a:00 via em3 Aug 27 17:35:16 dhcpd DHCPACK on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3
As you can see, the IOT (em0) DHCP handed the server an IP lease from the pool at 192.168.160.101. The LAN (em3) DHCP also handed out an IP of 192.168.163.25 from the static mapping.
I can't figure out why the IOT DHCP would respond to the server's discovery request if the IOT DHCP is set to Deny Unknown Clients. My assumption would that when Deny Unknown Clients is enabled, when the IOT DHCP server receives a discovery request from a host it will look at its static mappings. If the IOT DHCP server finds a matching MAC address in its static mappings it would extend an IP offer to the host. If no static mapping is found for the MAC address then no IP offer is made.
I'm certainly not a networking expert, so my assumption in the last paragraph on how Deny Unknown Clients works might be all wrong. But the net goal is to have clients with static mappings get their IP address from the DHCP server to which those mappings are tied.
-
Pretty much the only way that can happen is if you have broadcast domain leakage between those two networks. Are they both on the same switch? How is is that switch configured?
DHCPREQUEST for 192.168.160.101 from 00:15:5d:a3:0a:00 via em3: wrong network. Aug 27 14:19:37 dhcpd DHCPNAK on 192.168.160.101 to 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPDISCOVER from 00:15:5d:a3:0a:00 via em3 Aug 27 14:19:37 dhcpd DHCPOFFER on 192.168.163.25 to 00:15:5d:a3:0a:00 via em3
It is not unusual (in fact it is expected) to see entries like that if that if 00:15:5d:a3:0a:00 moves from the em0 to the em3 broadcast domain.
-
@Derelict Yes, they are both going to the same switch. It is a 24 port managed switch and I have 3 interfaces from my 4 port NIC running into it.
IOT (em0) is in port 1
VLANS (em1) is in port 2
LAN (em3) is in port 24The VM1RDS1 server with the issue is a Hyper-V machine that resides in a Windows Server 2012 host (DMA01FS). DMA01FS has 2 distinct NIC's in it that are teamed. Those NIC's are in ports 21 and 22. Here are some pictures on how the ports are assigned/tagged:
Overview Of VLANS on Switch
VLAN1 Configuration
VLAN166 Configuration
VLAN167 Configuration
PVID Configuration
Configuration Options On Switch
I hope that helps. Can you shed any light on my understanding of how the Deny Unknown Clients works? Am I correct that even if the discovery requests are broadcasting on the same switch and would hit the IOT interface in pfsense, wouldn't the IOT DHCP realize it does not have a static mapping for the VM1DRS1 server and therefore know it shouldn't issue an IP from its pool?
I really appreciate your help. Up to now everything on my network has been on the LAN network. This is my first experience in working with multiple lan/vlan networks. So this is a new experience for me so thanks for your help. The ultimate goal is to separate my business, home and IOT networks and add a wifi guest network.
-
The only way DHCP server will respond is if it receives the request. The only way it receives the request is if the switch sends it.
Ports 1 and 24 are both in VLAN1 (the same broadcast domain) so they will both be receiving broadcast traffic from all VLAN1 devices.
I don't know what asymmetric VLAN is there. Do you know you need it?
-
@Derelict said in Static IP Assigned Host Receiving IP Address From Other Interface:
The only way DHCP server will respond is if it receives the request. The only way it receives the request is if the switch sends it.
Ports 1 and 24 are both in VLAN1 (the same broadcast domain) so they will both be receiving broadcast traffic from all VLAN1 devices.
That was my understanding. But I'm still not clear why the IOT DCHP issued an IP address if the Deny Unknown Clients was enabled. Shouldn't it have declined an offer from a host whose MAC address was not in a static mapping in the IOT DHCP?
Would the solution/best practices then be to create 2 additional vlans on the switch, one for the LAN Network and then another for the IOT network? Then assign the various host ports to the appropriate networks? Am I correct in assuming that all of the ports would be untagged as the networks in pfsense are not vlans? If so, it leads me to 2 questions.
The first relates to how to let a device on the IOT network access a device on the LAN network. I have two tablets assigned to the IOT network that need to access a media server that is on the LAN network. I was able to accomplish that in the existing setup by creating an outbound NAT rule in pfsense from the IOT network to the LAN network. Am I correct to assume that this would be the correct way to accomplish this if the networks are divided on the switch?
The second question relates to how I would direct different wireless devices to the appropriate network. There's a couple of laptops that need to access the LAN network over wifi and a bunch of IOT wifi devices. Would I just create 2 different SSID's, one connecting to the LAN and the other to the IOT networks?
I'll research the asymmetrical vlans question.
-
Results are unpredictable with two DHCP servers that are not specifically designed to server the same broadcast domain being on the same broadcast domain. You will need to fix your switching before doing anything else.