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

    Connected to wireless interface, yet cannot ping it

    Wireless
    2
    8
    3.9k
    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.
    • D
      dm9876
      last edited by

      Hi team

      I have setup a pfSense system (1.2-RC4) with D-Link DWL-G510 Wireless NIC on opt2. This is a supported card http://madwifi.org/wiki/Compatibility/D-Link

      Everything else with the pfSense box is working OK (connect from LAN to internet on WAN etc).

      The Wireless interface is configured as an Access point. WPA-PSK. My WinXP Spk2 machine authenticates and connects fine. It even gets an IP etc via DHCP (client gets 192.168.10.190, Access Point IP is 192.168.10.1)

      first problem is that I cannot ping 192.168.10.1 from 192.168.10.190.

      If I run a packet capture from the pfSense box, I can see the ICMP echo requests coming from 192.168.10.190 yet it is not responding.

      (Note: not sure that it affects things at this level, but I have setup firewall rule to allow the WIFI subnet to access the WAN (with or without this makes no difference).

      Any ideas?

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

        The WLAN is a OPTx:

        @http://forum.pfsense.org/index.php/topic:

        If you want to have Internet access from multiple LAN subnets (on various OPTx interfaces) enable Advanced outbound NAT.
        You need to create a rule for every subnet you want NAT'ed.
        Alternatively you can change the source of single existing rule from LAN to "any" thus NAT'ing everything.
        This might create a problem for FTP with multiWAN
        more here: http://forum.pfsense.org/index.php/topic,7096.msg40810.html#msg40810

        Could you post a screenshot of your rule you created on the WLAN interface here?

        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
        • D
          dm9876
          last edited by

          Hi Gruens,

          I would have thought I'd need to be able to ping the interface (ie have IP working on it) before worrying about NAT and access to the WAN network.

          Never the less I added the rule and still I cannot ping the 192.168.10.1 interface.

          Here is the NAT rules

          pfSense_Nat_config.jpg
          pfSense_Nat_config.jpg_thumb

          1 Reply Last reply Reply Quote 0
          • D
            dm9876
            last edited by

            Here are some additional screen shots of the config.

            The only thing that seems a little strange to me is the DHCP leases where it shows the address which is given to the wireless client as expired?? the client shows the lease as still active (as expected).

            If there are not any great ideas I suppose I will simplify the config as much as possible to see where its going wrong. Static IP, no Encryption etc.

            Thanks

            Dean

            arp_table.jpg
            arp_table.jpg_thumb
            DHCP_config_on_WIFI_interface.jpg
            DHCP_config_on_WIFI_interface.jpg_thumb
            DHCP_leases.jpg
            DHCP_leases.jpg_thumb
            Firewall_Rules_WIFI.jpg
            Firewall_Rules_WIFI.jpg_thumb
            Interfaces_Optional_2_WIFI.jpg
            Interfaces_Optional_2_WIFI.jpg_thumb
            Status_Interfaces.jpg
            Status_Interfaces.jpg_thumb
            status_Wireless.jpg
            status_Wireless.jpg_thumb

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

              Your firewall rule is wrong.
              Destination WAN-Interface means EXACTLY THAT

              You allow right now only access to the IP of your WAN.

              Your rule should look something like that:

              Source: "WLAN-subnet" –> or in the case of bridging "LAN-subnet"
              Destination: *

              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
              • D
                dm9876
                last edited by

                Fantastic, all working now. I miss understood thinking that was allowing anything going via the WAN rather than specifically the ip of the WAN interface itself.

                So I have setup as you described but with a rule before it that is blocking anything coming from WIFI headed for LAN subnet.

                Thanks again.

                Dean

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

                  If you want to filter from WLAN to LAN you also need to enable the filtering of bridges.

                  Advanced –> "Enable filtering bridge"

                  Also make sure that your rules have the right order
                  --> http://forum.pfsense.org/index.php/topic,7001.0.html

                  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
                  • D
                    dm9876
                    last edited by

                    In my case WIFI and LAN are different subnets so I think it should be OK (ie routed not bridged).

                    Thanks for the link to the other topic, some useful tips in there

                    Dean

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