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

    ARP (?) Requests do not pass WLAN (Bridge) -> LAN

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 2 Posters 3.2k 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.
    • H Offline
      hessie
      last edited by

      Hi !

      I've got a strange problem here.

      LAN is 192.168.0.0/24

      OPT3 is WLAN with the ath driver, so ath0 bridged with LAN.

      I've bought a Powerline Adapter which is configured first time by an application which searches for
      the unconfigured adapter in the LAN probably by an arp request.

      When I run this application from a wireless client on the OPT3 Interface, no adapter is found though its connected and hooked up by wire in LAN.

      When I run the app from a computer connected by wire to LAN, everything works great, the device is found within a second and I can configure it.

      After it is configured and I've assigned an IP to it, I can reach it by IP from OPT3 too, but arp (?) requests still fail.

      Anyone has an idea which protocol/port I must let pass in the firewall rules for this to work ?

      thanks

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

        Did you create firewall rules that allow traffic?

        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
        • H Offline
          hessie
          last edited by

          Yes sure, like this:

          OPT3:
          *  *  *  LAN net  *  *

          LAN:
          *  *  *  OPT3 net  *  *

          I already had a problem with DHCP though these rules were set, a tip from a member adding this rule:
          UDP  *  67 - 68  *  67 - 68  *   
          to OPT3 fixed it.

          Maybe I need something similar for ARP (?) Packets ?

          I'm not sure if thats an arp packet, but for my understanding the software simply sends an arp packet to the broadcast address..

          Everything else is working fine..

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

            ummm.
            Since you bridge WLAN with LAN you should no longer have a "LAN net" and an "OPT3 net".
            You just have one big subnet.
            –> You dont assign an IP on the WLAN-side.

            I would start troubleshooting by having on both interfaces a rule allowing everything, including the source.

            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
            • H Offline
              hessie
              last edited by

              That is exactly the way I have it :)

              Its one big subnet, same IP's, I just call them LAN net and OPT3 net as thats the way pfSense references to the interfaces. You can also just say Interface LAN and OPT3 if that makes it clearer.

              I already have a rule on both interfaces which allow anything.

              The funny thing is, I had this rule all the time, but DHCP stopped working after update to 1.2 (or 1.2.1?) on the OPT3 interface (wlan). After I added the UDP rule which explicitly allows DHCP packets to pass, it worked again.
              Maybe I've got to add something similar for ARP ?

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

                Are you really sure you allow everything?
                I mean a * in the protocol field and not TCP or TCP/UDP.

                Anyway i would update to 1.2.3
                –> http://blog.pfsense.org/?p=377

                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
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.