Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Spoof MAC = connection problems

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 4 Posters 4.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      ryall
      last edited by

      Hi guys,

      I'm trying to set a MAC address on my OPT1 interface, but when I do I can no longer ping any hosts connected to OPT1.

      ping from LAN to OPT1 interface address works.

      ping from LAN to any host on the OPT1 subnet fails.
      ping from PF console to any OPT1 host fails.
      ping from OPT1 host to PF fails.

      If I clear the MAC field and save, everything works.

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        Do you have a Switch in front of the OPT1-Interface?
        After you changed the MAC address it may take some time (usually up to 300 seconds) until it's registered that your IP has a new MAC.

        On a windows-machine connected to the OPT1 subnet do a "arp -a" from a console after you tried to ping your OPT1-Interface.
        Is the MAC-entry the right one?

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • R
          ryall
          last edited by

          For testing purposes i've only got my laptop connected to OPT1, so no switch in between.

          Sorry, I should've said that arp -a from an OPT1 host (the laptop) shows the correct MAC (ie, the spoofed address assigned to OPT1).

          UPDATE:
          Ok things just got more weird, I turned on packet capture in pfsense and pings from OPT1 host work (and vice versa). Turn off packet capture and the pings fail. So pings from OPT1 work when packet capture is on???

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            That's weird…  I believe MAC spoofing has to put the interface into promiscuous mode to function. When you're tcpdump'ing on the interface, it puts the interface into promiscuous mode. Makes it sound like MAC spoofing on OPT interfaces has a bug of some sort. I'll check into it.

            1 Reply Last reply Reply Quote 0
            • R
              ryall
              last edited by

              Thanks cmb,

              Is this a problem on OPT interfaces only? Would there be any point in me trying to set up WAN to act as my OPT1? (I only need spoofing on OPT1)

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                It definitely works fine on WAN. I don't know that anyone has ever really tried it on OPT interfaces, generally that's unnecessary. I'm assuming you must have a OPT Internet connection.

                Can you tell me more about how your OPT interface is setup, to help me try to replicate this?  Is it static IP or DHCP? What is it connected to (Internet or internal network)?

                1 Reply Last reply Reply Quote 0
                • R
                  ryall
                  last edited by

                  Hi cmb,

                  First up, you were right about promiscuous mode. For anyone that has the same problem, I added

                  <shellcmd>ifconfig sk1 promisc</shellcmd>  (sk1 is the IF name)

                  to my config and everything works fine now. Thanks cmb for pointing me in the right direction  ;D

                  cmb:
                  We provide a service for another company in the building, so basically we have a set up like this:

                  [our DMZ]–[our firewall]–-------[their firewall]–[their LAN]

                  OPT1 interface is used for the connection, with both ends using static IP. I guess their firewall filters by MAC because when I switched to pfsense the connection failed. So I spoofed the MAC from our old firewall to OPT1, and that's when the problems above started.

                  1 Reply Last reply Reply Quote 0
                  • H
                    hoba
                    last edited by

                    might also be an old arp cache on their box and the issue maybe would have fixed itself after rebooting the other box or after a timeout or manually cleared arp cache.

                    1 Reply Last reply Reply Quote 0
                    • R
                      ryall
                      last edited by

                      Nope  ;)

                      @ryall:

                      For testing purposes i've only got my laptop connected to OPT1, so no switch in between.

                      Sorry, I should've said that arp -a from an OPT1 host (the laptop) shows the correct MAC (ie, the spoofed address assigned to OPT1).

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        Definitely not a pfSense bug, I messed around numerous times with changing MAC addresses on OPT interfaces and it worked fine every time.

                        It's a hardware or driver bug that doesn't let the card receive packets destined for any MAC address other than the card's own. Putting the NIC into promiscuous bypasses this issue, this is not normally necessary. So the work around posted above is the correct way to do this. It shouldn't be necessary on virtually all installs, so we're not going to change anything related to this.

                        1 Reply Last reply Reply Quote 0
                        • R
                          ryall
                          last edited by

                          If it helps anyone else out, the card that had these issues was a D-Link DGE-530T.

                          Thanks again guys :)

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.