Strange behaviour with MAC passthrough



  • Hello,

    My setup on the captive portal net is this:

    [pfsense box nic]–-[wlan AP (access point)]   [wlan AP in client mode]–-[TV]

    • additional laptops connecting to the pfsense box through the wlan AP.

    The TV obviously gets no connectivity to the oustside world unless I let it pass through the captive portal. But, this is the strange thing: If I enter the TV’s MAC, it doesn’t work. If I enter the TV’s wlan AP’s MAC though, it works, even if the TVs MAC isn’t entered. I really don’t understand why? The calls comes from the TV, so, shouldn’t the TV be the ones that should be let throght?

    Entering the TV and the TV AP’s mac addresses for static DHCP works as a charm.

    Thanks,
    Floddy



  • Only one MAC can be seen from any one wireless client, so what your second WLAN box is doing is translating the source MAC to its own MAC. It leaves the MAC within DHCP requests alone, basically acting as a DHCP relay of sorts, which is why it gets its own IP. That’s typical behavior in such scenarios.



  • Ah, ok, that explains it.

    Does that apply only to APs in client mode, or the other “regular” AP as well, like the one connected directly to the pfsense box?

    For example, I have a laptop with windows firewall rules that lets smb traffic through, but only if it’s from my regular computer. But, if one would just play with the thought that windows firewall could filter on mac instead of IP addresses; would that work, or would it just see the APs mac?

    Thanks,
    Floddy



  • Only applies to devices behind a wireless device in client mode. In a typical AP scenario with multiple clients, those clients all retain their real MAC address.


  • Rebel Alliance Developer Netgate

    There are some APs out there that work in a bridge mode where they don’t forward on the client’s MAC. I have a couple of them, EDIMAX somethingorother model. It’s impossible to use more than one client from behind it in AP client mode from what I could tell.


Locked
 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy