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

    PfSense-on-a-stick Unacceptable MAC Address Issues

    Scheduled Pinned Locked Moved General pfSense Questions
    8 Posts 4 Posters 1.4k 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.
    • P Offline
      pf123user
      last edited by

      Having issues with my ISP's ONT box and Cable Modem binding to the physical MAC of the switch vs. the VLAN MAC address coming from pfSense. Switch is Cisco SG300-10/28 (have tried both).

      As an unacceptable solution, if we lose power or alternatively, three times now the ISP has had outages which released/purged the MAC address; I have been booting to Ubuntu Live CD via USB thumb drive, plugging in the WANs each to the pfSense interface with the correct MAC address, powering down the Ubuntu Live CD and restarting pfSense. Things then work but this is a 30-minute process. I'd like to be able to push the pfSense MAC address out to my ISP in a way that the ISP never sees the switch's MAC. I know that the ISP's are seeing the switch's MAC because they tell me that they see my public IPs binding to the switch's MAC address.

      Is there a workaround or a setting in pfSense that would force the VLAN to override the switch MAC address? The SG300 series is a fairly low-level Cisco SMB switch (rebranded Linksys) and I've had no luck trying to tweak settings on the switch.

      Thanks for any advice or help.

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        It's your switch's fault.  Is it in layer 3 mode?

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • jahonixJ Offline
          jahonix
          last edited by

          Your switch has to talk to your ISP in order for them to sees those MAC address. Simple routing doesn't do that.
          Did you turn on DHCP snooping accidentally or is/are the switches IP address(es) requested by DHCP? Make all of them static.

          1 Reply Last reply Reply Quote 0
          • jahonixJ Offline
            jahonix
            last edited by

            Why is your switch in L3 mode if it only has one IP?

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

              The modem is probably seeing STP traffic from the switch and taking that source MAC as its authorized MAC. Not sure what features that switch has, but maybe you can disable STP entirely, or at least on the port your modem is plugged into.

              1 Reply Last reply Reply Quote 0
              • jahonixJ Offline
                jahonix
                last edited by

                SG300 switches usually have RSTP enabled by default. Awesome idea, Chris!

                1 Reply Last reply Reply Quote 0
                • jahonixJ Offline
                  jahonix
                  last edited by

                  I think I can follow you but I don't see if that could be a problem. It's late over here…
                  Try disabling STP/RSTP/MSTP on the "WAN" ports as per cmb's advise and test it.

                  1 Reply Last reply Reply Quote 0
                  • jahonixJ Offline
                    jahonix
                    last edited by

                    It's sufficient to disable it on the ports that represent your WAN to the modem.

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