Unable to impersonate 802.1x authenticated device

Installing and Using OpenWrt
1

Hi all,
I’ve noticed a change in behavior when attempting to impersonate an 802.1X authenticated device in OpenWrt 24.x compared to 23.05.5.

Test cases:
OpenWrt SNAPSHOT Raspberry Pi 5
OpenWrt 24.10.1 Raspberry Pi 5
OpenWrt SNAPSHOT Raspberry Pi 4
OpenWrt 24.10.1 Raspberry Pi 4
OpenWrt 23.05.5 Raspberry Pi 4
OpenWrt 23.05.5 Raspberry Pi 3

Setup

The OpenWrt Raspberry Pi sits in-between the supplicant, and the authenticator, like this:

802.1x capable device -> eth1 - Raspberry Pi - eth0 -> Authenticator

In 23.05.5, both the Pi 4 and 3 the following approach allowed the impersonating device to take over the DHCP lease of the original device:

Bridge Mode

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        list ports 'eth1'
        option ipv6 '0'
        option promisc '1'

config interface 'lan'
        option device 'br-lan'
        option proto 'none'

Impersonation Mode

config device
        option name 'eth0'
        option ipv6 '0'
        option promisc '1'
        option macaddr '<MAC of impersonated device on eth1>'

config interface 'lan0'
        option device 'eth0'
        option proto 'dhcp'

To switch between the two modes:

cp networkmode_bridge /etc/config/network
/etc/init.d/network restart

Behavior

  • OpenWrt 23.05.5: The impersonating device would inherit the IP address of the original device.
  • OpenWrt 24.x (tested on 24.03 and SNAPSHOT): The impersonating device receives a new DHCP lease instead of assuming the existing one.

These are the only logs I have from the failing setup

Tue Oct 21 20:24:29 2025 daemon.notice netifd: Network device 'eth0' link is up
Tue Oct 21 20:24:29 2025 daemon.notice netifd: Interface 'lan0' has link connectivity
Tue Oct 21 20:24:29 2025 daemon.notice netifd: Interface 'lan0' is setting up now
Tue Oct 21 20:24:29 2025 kern.info kernel: [  758.422327] macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Tue Oct 21 20:24:29 2025 daemon.notice netifd: lan0 (6575): udhcpc: started, v1.36.1
Tue Oct 21 20:24:29 2025 daemon.notice netifd: lan0 (6575): udhcpc: broadcasting discover
Tue Oct 21 20:24:29 2025 daemon.notice netifd: lan1 (6269): udhcpc: broadcasting discover
Tue Oct 21 20:24:32 2025 daemon.notice netifd: lan1 (6269): udhcpc: broadcasting discover
Tue Oct 21 20:24:32 2025 daemon.notice netifd: lan0 (6575): udhcpc: broadcasting discover
Tue Oct 21 20:24:35 2025 daemon.notice netifd: lan0 (6575): udhcpc: broadcasting discover
Tue Oct 21 20:25:01 2025 daemon.notice netifd: lan0 (6575): udhcpc: broadcasting select for 10.155.100.4, server 10.155.100.1
Tue Oct 21 20:25:01 2025 daemon.notice netifd: lan0 (6575): udhcpc: lease of 10.155.100.4 obtained from 10.155.100.1, lease time 3600
Tue Oct 21 20:25:01 2025 daemon.notice netifd: Interface 'lan0' is now up

I don't have a functioning 802.1x network for testing right now, so I will be unable to get new logs until I get that fixed. I skimmed the changes between the two versions, but a lot of it is above my head. If anyone has questions, insights or has seen similar behavior, I’d appreciate your input.
Thanks!

2

What do you mean by the phrase "assuming the existing one"?

Is your DHCP server another OpenWrt device?

  • If not, how is this related to OpenWrt?
  • If so, can we see the configurations?
3

Updated the post. I can see how that wasn't clear, sorry.
Switching from bridge mode to impersonate mode once the 802.1x device is authenticated, eth0 now gets a new DHCP assignment instead of taking over the already authenticated one.

4

You were clear, my questions remain:

What do you mean by "already authenticated one"?

Can we see the OpenWrt's configurations for DHCP, etc.?

I think that will clear confusion.

Are you saying something else is broken with this setup unrelated to the OpenWrt?

5

The connection from the supplicant to the internal network is "already authenticated", before impersonation. Then when switching modes, it is no longer authenticated, where I want it to remain authenticated.

There is only the one OpenWrt device mentioned, where functionality I was using has changed between versions, which prompted me to ask this question.

No. All I mean by this is that I don't have access to a network I can use for testing this right now.

Thanks for getting back to me!

6

Since you're describing non-standard steps (i.e., purposely trying to trick/circumvent network authentication), it's important to understand you clearly.

I'll try once more for clarification - what OS is running on the DHCP server?

Are you sure?

I see 3 devices (at least).

  • To be clear, how do you physically remove the orginal device from the network?
  • Is the orginal device running OpenWrt?
  • How do you test switching OpenWrt versions?
  • Have you tried the order vice versa (23-to-24 and 24-to-23)?
7

In the chain of devices used, there is only one OpenWrt device at a time, yes.

I don't. It is only disconnected in the sense that the sofware bridge 'br-lan' allowing traffic to and from the device is removed from /etc/config/network.

No. The device I am trying to impersonate in my test case is a Windows device.

I build all images with the Image builder.

If you are referring to up/downgrading, then no. I use the Image Builder to flash "fresh" images for each device, and OS version.

8

So you never unplug the Windows device?

I meant in the context of swapping devices.

Please explain physically how you swapped the Windows device for 23 to 24 and then 24 to 23 (i.e., vice versa, as I was suggesting).

(It never ceases to amaze me how users find non standard activities to perform, perhaps you can explain the practical nature of this exercise as well.)

I also wonder if any documented changes occurred in this software. :thinking:

9

English is not my native language, so please excuse me if I seem uncooperative.

Physically, no, it remains plugged in to the Pi.

Then I don't understand "switching openwrt versions". Sorry.

I don't understand swapping the Windows device. Sorry.

Here is the brain dump behind it :smiley:

the openwrt is dual interface based on RPI models (cm4/cm5/rpi4/rpi5). it is running openwrt 24.10 in bridge mode and place inline between windows device and an internal network.
The windows device is enrolled in 802.1x authentication and authenticates successfully when the device is plugged inline with both 23.05 and 24.10 and the device successfully forwarding back and forth 802.1x frames (with the manual patch in Openwrt's kernel). MACSEC (802.1ae) is NOT supported and i am showcasing that without macsec 802.1x is insecure and therefore by spoofing the MAC address of the windows device and switch to only one Active port (eth0) cutting the windows device off the network on Openwrt 23.05 it is possible to continue working as authenticated with 802.1x - i.e the network does not register that a cable has been unplugged and re-plugged but with 24.10 the Cisco device on the internal network sends a new 802.1x request which ends up failing because the openwrt has cut the connection to the windows device at that time.

Did you find anything specific? I seem to be unable to find anything I deem relevant, which might not be the correct approach :slight_smile: