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

Connected to wireless interface, yet cannot ping it

Scheduled Pinned Locked Moved Wireless
8 Posts 2 Posters 3.9k 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.
  • D
    dm9876
    last edited by Jan 25, 2008, 6:45 AM

    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
    • G
      GruensFroeschli
      last edited by Jan 25, 2008, 7:04 AM

      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 Jan 27, 2008, 2:00 AM

        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 Jan 27, 2008, 2:38 AM

          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
          • G
            GruensFroeschli
            last edited by Jan 27, 2008, 2:44 AM

            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 Jan 27, 2008, 2:54 AM

              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
              • G
                GruensFroeschli
                last edited by Jan 27, 2008, 3:04 AM

                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 Jan 27, 2008, 6:12 AM Jan 27, 2008, 6:01 AM

                  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
                  1 out of 8
                  • First post
                    1/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received