"Quote from: cookiemonster on June 12, 2025, 11:31:23 PMMy thinking was along your last comment, that the arp broadcast will be made right to the whole domain, reaching OPN as well as other on the L2 so VLAN would be the thought in my head.Yup, I think writing this down cleared it up in my head enough for me to figure that OPNsense can't help with this, at least until I can get the client on its own VLAN. Thanks!
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#1
25.1, 25.4 Production Series / Re: Work around bad client -- block packets coming from IP and MAC combination?
June 13, 2025, 02:43:47 AM #2
25.1, 25.4 Production Series / Work around bad client -- block packets coming from IP and MAC combination?
June 12, 2025, 08:51:10 AM
I have a bad client device (hardware, closed-source) which is causing issues on my network, and I'm trying to use OPNsense to work around it.
The client only supports DHCP (a static IP address cannot be configured). However, when it starts up, before it connects via DHCP, it first connects using the static IP address 192.168.1.1. It will sit on this address for around a minute before issuing the DHCP request and switching to the IP in the DHCP response.
This causes problems with another client on the network which legimately owns 192.168.1.1. When the bad client starts up, the legitimate client loses connectivity with other devices on the network, until the bad client switches to the DHCP address. This causes long-running connections from the legitimate client to other network clients to be dropped and need to be re-established.
I'm a bit rusty on this, but I believe this is due to the bad client announcing that it owns 192.168.1.1, causing other clients on the network to update their ARP tables. I've tried using the 'Neighbors' function in OPNsense to assign both the legitimate and bad clients the correct combination of IP and MAC addresses, but this doesn't fix connectivity being lost to other clients on the network -- my understanding is this is because this setting can't control the ARP tables of other devices on the network, only the ARP table within OPNsense itself.
My next idea is to use the firewall to block any communications that originate from the MAC address of the bad client *and* the reserved IP address. This would presumably block it from announcing its ownership of 192.168.1.1 to the rest of the network, not block the DHCP request (as that doesn't originate from an IP?), and not block the device when it moved to the correct IP. However, I'm not sure how to configure the OPNsense firewall to do this -- I can see how to block the IP (which would also block the legitimate client), or block the MAC (which would block the bad client even when it tried to switch to DHCP), but not how to block only packets that match both criteria. Can anyone offer any guidance?
I'd also welcome any advice on alternative approaches to fix this. Things I'd rather not do:
Things I can't currently do:
Edit: Hmm, I'm thinking that even if I can do that firewall block, other network clients on the same L2 network segment are still going to hear the ARP announcement and start talking to the bad client. Maybe this isn't fixable at the firewall/router level, at least without VLANs?
The client only supports DHCP (a static IP address cannot be configured). However, when it starts up, before it connects via DHCP, it first connects using the static IP address 192.168.1.1. It will sit on this address for around a minute before issuing the DHCP request and switching to the IP in the DHCP response.
This causes problems with another client on the network which legimately owns 192.168.1.1. When the bad client starts up, the legitimate client loses connectivity with other devices on the network, until the bad client switches to the DHCP address. This causes long-running connections from the legitimate client to other network clients to be dropped and need to be re-established.
I'm a bit rusty on this, but I believe this is due to the bad client announcing that it owns 192.168.1.1, causing other clients on the network to update their ARP tables. I've tried using the 'Neighbors' function in OPNsense to assign both the legitimate and bad clients the correct combination of IP and MAC addresses, but this doesn't fix connectivity being lost to other clients on the network -- my understanding is this is because this setting can't control the ARP tables of other devices on the network, only the ARP table within OPNsense itself.
My next idea is to use the firewall to block any communications that originate from the MAC address of the bad client *and* the reserved IP address. This would presumably block it from announcing its ownership of 192.168.1.1 to the rest of the network, not block the DHCP request (as that doesn't originate from an IP?), and not block the device when it moved to the correct IP. However, I'm not sure how to configure the OPNsense firewall to do this -- I can see how to block the IP (which would also block the legitimate client), or block the MAC (which would block the bad client even when it tried to switch to DHCP), but not how to block only packets that match both criteria. Can anyone offer any guidance?
I'd also welcome any advice on alternative approaches to fix this. Things I'd rather not do:
- Throw the bad client in the trash (although it probably deserves it!)
- Change the IP address of the legitimate owner of 192.168.1.1
Things I can't currently do:
- Put the bad client in its own VLAN (I don't have the hardware to do this in the location where the client is).
Edit: Hmm, I'm thinking that even if I can do that firewall block, other network clients on the same L2 network segment are still going to hear the ARP announcement and start talking to the bad client. Maybe this isn't fixable at the firewall/router level, at least without VLANs?
Pages1
