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

    PfSense doesn't work with 2 wireless adapters on VMware

    Wireless
    2
    14
    6.8k
    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
      hcigmx
      last edited by

      I have pfSense v2.0.1 installed on VM workstation 8. Host machine is Windows 7 Starter edition. There are 2 wireless adapters on the host machine (1 is built-in, another is external USB type). Each of these 2 wireless adapters connects to a different Access Point. I setup VM to use 2 vNIC (each vNIC for each wifi adapter). Inside pfSense, they were set as WAN and LAN.

      Problem is: computers in LAN cannot connect to the Internet. They can get DHCP and ping the LAN-facing pfSense's IP, but can't ping WAN-facing pfSense's IP or the Internet.

      Temporary fix is: connect host computer to the LAN Access Point using cable, change a VM vNIC to the wired adapter. All computers in LAN can then work properly.

      Questions is: why doesn't it work with 2 wireless adapters? why 1 wired and 1 wireless can work, instead?

      Thanks.

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        @hcigmx:

        Problem is: computers in LAN cannot connect to the Internet. They can get DHCP and ping the LAN-facing pfSense's IP, but can't ping WAN-facing pfSense's IP or the Internet.

        Please give the ping command and its response. That will be much more informative than "cannot ping".

        Do computers in LAN get the correct default route so traffic goes to pfSense? (What does traceroute to a public IP address report?)

        Is the pfSense WAN interface UP?
        What does traceroute to a public IP address issued on pfSense console report?

        Can you provide a diagram? I'm having difficulty picturing how you have put this together.

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

          @wallabybob:

          Please give the ping command and its response. That will be much more informative than "cannot ping".

          Command: ping 192.168.102.5

          Pinging 192.168.102.5 with 32 bytes of data:
          Request timed out.
          Request timed out.
          Request timed out.
          Request timed out.

          Ping statistics for 192.168.102.5:
              Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

          Command: ping 192.168.8.1

          Pinging 192.168.8.1 with 32 bytes of data:
          Reply from 192.168.8.1: bytes=32 time=10ms TTL=64
          Reply from 192.168.8.1: bytes=32 time=4ms TTL=64
          Reply from 192.168.8.1: bytes=32 time=5ms TTL=64
          Reply from 192.168.8.1: bytes=32 time=5ms TTL=64

          Ping statistics for 192.168.8.1:
              Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

          @wallabybob:

          Do computers in LAN get the correct default route so traffic goes to pfSense? (What does traceroute to a public IP address report?)

          Yes, they do. Default route assigned by pfSense DHCP is: 192.168.8.1

          Command: tracert www.google.com

          Tracing route to www.google.com [74.125.237.116]
          over a maximum of 30 hops:

          1    *        *        *    Request timed out.
            2    *        *        *    Request timed out.
            3    *        *        *    Request timed out.
            4    *        *

          I show only the first 4 lines. Weirdly, it managed to get DNS resolved. Probably, it's from pfSense's DNS forwarder.

          @wallabybob:

          Is the pfSense WAN interface UP?
          What does traceroute to a public IP address issued on pfSense console report?

          WAN interface is UP, showing IP: 192.168.102.5 on console screen.

          Command: traceroute www.google.com

          traceroute: Warning: www.google.com has multiple addresses; using 74.125.237.116

          traceroute to www.google.com (74.125.237.116), 64 hops max, 40 byte packets
          1  192.168.102.1 (192.168.102.1)  6.005 ms  10.092 ms  8.789 ms
          2  be2-100.bras1wtc.wlg.vf.net.nz (203.109.129.113)  38.511 ms  35.740 ms  38.945 ms
          3  be5-100.ppnzwtc01.wlg.vf.net.nz.129.109.203.in-addr.arpa (203.109.129.114)  40.163 ms  44.112 ms  39.203 ms
          4  gi0-2-0-3.ppnzwtc01.wlg.vf.net.nz.180.109.203.in-addr.arpa (203.109.180.210)  37.802 ms  37.700 ms  39.684 ms
          5  gi0-2-0-3.ppnzwtc02.wlg.vf.net.nz (203.109.180.209)  53.945 ms  42.392 ms  39.566 ms
          6  ggl-router.syd.vf.net.nz.130.109.203.in-addr.arpa (203.109.130.2)  90.141 ms  75.626 ms  69.971 ms
          7  66.249.95.232 (66.249.95.232)  70.180 ms  69.927 ms  70.462 ms
          8  72.14.237.135 (72.14.237.135)  68.940 ms  68.556 ms  68.844 ms
          9  syd01s12-in-f20.1e100.net (74.125.237.116)  69.796 ms *  66.536 ms

          @wallabybob:

          Can you provide a diagram? I'm having difficulty picturing how you have put this together.

          Diagram attached.

          Thanks.

          ![Tuki Network.png_thumb](/public/imported_attachments/1/Tuki Network.png_thumb)
          ![Tuki Network.png](/public/imported_attachments/1/Tuki Network.png)

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            Thanks for the diagram. That was helpful.

            @hcigmx:

            Questions is: why doesn't it work with 2 wireless adapters? why 1 wired and 1 wireless can work, instead?

            pfSense default configuration sets firewall rules on LAN interface to allow traffic to anywhere and rules on other interfaces to block traffic.

            Is your pfSense wired interface called LAN? If so, then you will need firewall rules on the "LAN" WiFi interface to allow traffic to the Internet (anywhere?). After changing the rules you should reset firewall states, see Diagnostics -> States, click on Reset States tab, read explanation then click on Reset button.

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

              @wallabybob:

              pfSense default configuration sets firewall rules on LAN interface to allow traffic to anywhere and rules on other interfaces to block traffic.

              Is your pfSense wired interface called LAN? If so, then you will need firewall rules on the "LAN" WiFi interface to allow traffic to the Internet (anywhere?). After changing the rules you should reset firewall states, see Diagnostics -> States, click on Reset States tab, read explanation then click on Reset button.

              Within pfSense, there is only 1 LAN interface, which has all traffics allowed. Reset States didn't solve it. Switching of LAN adapters from wired to wifi was done in VM setting, so pfSense should not see anything different.

              Today, I tried to make the VM to have 3 adapters, i.e. WAN, LAN-wired, LAN-wifi. Within pfSense, only 2 adapters were enabled. Switching of LAN adapters was done in Interface Assignment. Also tried clean install on 2.1Beta0. On those 3 different ways, they behaved the same, i.e. 2 wifi didn't work, 1 wired 1 wifi worked.

              Further tests were done, and it appears that whenever selected LAN-facing adapter is wifi, it won't work. Local PING on LAN-facing wifi worked, but just didn't want to route.

              So in summary:
              LAN-facing: Wifi didn't work
              LAN-facing: Wired worked
              WAN-facing: either wifi or wired, worked

              I begin to wonder whether LAN-facing wifi adapter connected to AP is unsupported by pfSense. Or, is it problem with VMware? Or, Windows 7 Starter as host machine?

              Thanks.

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

                @hcigmx:

                Within pfSense, there is only 1 LAN interface, which has all traffics allowed. Reset States didn't solve it. Switching of LAN adapters from wired to wifi was done in VM setting, so pfSense should not see anything different.

                Your diagram doesn't show the access the hypervisor has to the NICs. I presume the hypervisor has control at least of the "LAN facing" WiFi NIC.

                I suggest you ping an internet host over the WiFi link and run a packet capture on the pfSense "LAN facing" NIC. Do you see the traffic? If not, you will have to tweak the hypervisor to get the traffic to pfSense (probably need a default route).

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

                  @wallabybob:

                  I suggest you ping an internet host over the WiFi link and run a packet capture on the pfSense "LAN facing" NIC. Do you see the traffic? If not, you will have to tweak the hypervisor to get the traffic to pfSense (probably need a default route).

                  Packet capture on pfSense LAN-facing NIC showed the traffic when ping from a computer over wifi link (192.168.8.8) to internet host: 192.168.8.1 < 192.168.8.8.

                  pfSense LAN-facing NIC was also able to respond to ping from other computers, and vice versa. It was able to issue DHCP leases, as well.

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob
                    last edited by

                    @hcigmx:

                    Packet capture on pfSense LAN-facing NIC showed the traffic when ping from a computer over wifi link (192.168.8.8) to internet host: 192.168.8.1 < 192.168.8.8.

                    Sorry, by "internet host" I meant a public IP address (e.g. 74.125.237.116, www.google.com).

                    Unless I completely misunderstood your diagram 192.168.8.1 is the (private) IP address of your pfSense LAN facing NIC. You have already reported you get responses to pings directed to that address.  I'm much more interested in whether pfSense even sees packets directed to the public IP addresses for which you don't get a response!

                    @wallabybob:

                    I presume the hypervisor has control at least of the "LAN facing" WiFi NIC.

                    Is this presumption correct?

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

                      @wallabybob:

                      Sorry, by "internet host" I meant a public IP address (e.g. 74.125.237.116, www.google.com).

                      That's the result from LAN-facing capture when I ping to public IP.

                      @wallabybob:

                      I presume the hypervisor has control at least of the "LAN facing" WiFi NIC.
                      Is this presumption correct?

                      No, LAN-facing is vNIC bridged from host's wifi adapter.

                      1 Reply Last reply Reply Quote 0
                      • W
                        wallabybob
                        last edited by

                        @hcigmx:

                        @wallabybob:

                        Sorry, by "internet host" I meant a public IP address (e.g. 74.125.237.116, www.google.com).

                        That's the result from LAN-facing capture when I ping to public IP.

                        If you ping 74.125.237.116 from a system on your WiFi and, by the time that gets into pfSense the destination IP address of 74.125.237.116 becomes a 192.168.x.x address that address transformation is the problem. It is not a pfSense problem.

                        It is a pity you didn't post more of the packet capture output, especially the decode of the packets. That would at least give confirmation the snippet you posted is a PING and not some other traffic between WiFi client and pfSense.

                        @hcigmx:

                        @wallabybob:

                        I presume the hypervisor has control at least of the "LAN facing" WiFi NIC.
                        Is this presumption correct?

                        No, LAN-facing is vNIC bridged from host's wifi adapter.

                        This answer is inconsistent - by hypervisor I meant the OS hosting the pfSense virtual machine. In that case the correct answer would be one of:
                        1. Yes, the LAN-facing is vNIC bridged from host's wifi adapter; OR
                        2. No, the LAN facing WiFi NIC is "passed through" from host OS to pfSense VM.

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

                          @wallabybob:

                          If you ping 74.125.237.116 from a system on your WiFi and, by the time that gets into pfSense the destination IP address of 74.125.237.116 becomes a 192.168.x.x address that address transformation is the problem. It is not a pfSense problem.

                          It is a pity you didn't post more of the packet capture output, especially the decode of the packets. That would at least give confirmation the snippet you posted is a PING and not some other traffic between WiFi client and pfSense.

                          When PING from 192.168.8.8 to 74.125.237.24 (www.google.co.nz IP), package capture showed:
                          with filter set to 192.168.8.8: showed blank
                          with filter set to 74.125.237.24: showed blank
                          with no filter: showed nothing on PING traffic, but some ARP packets requesting LAN broadcast traffics to be directed to 192.168.8.3 (LAN Access Point).

                          When PING from 192.168.8.8 to 192.168.8.1, package capture showed:
                          with filter set to 192.168.8.8: showed PING traffic
                          with filter set to 192.168.8.1: showed PING traffic
                          with no filter: showed PING traffic

                          @wallabybob:

                          This answer is inconsistent - by hypervisor I meant the OS hosting the pfSense virtual machine. In that case the correct answer would be one of:
                          1. Yes, the LAN-facing is vNIC bridged from host's wifi adapter; OR
                          2. No, the LAN facing WiFi NIC is "passed through" from host OS to pfSense VM.

                          Sorry, didn't understand hypervisor. The answer is 1: vNIC brigded from host's wifi adapter. I did try to pass through to VM, but wifi adapter not supported (Ralink RT5370).

                          1 Reply Last reply Reply Quote 0
                          • W
                            wallabybob
                            last edited by

                            @hcigmx:

                            When PING from 192.168.8.8 to 74.125.237.24 (www.google.co.nz IP), package capture showed:
                            with filter set to 192.168.8.8: showed blank
                            with filter set to 74.125.237.24: showed blank
                            with no filter: showed nothing on PING traffic, but some ARP packets requesting LAN broadcast traffics to be directed to 192.168.8.3 (LAN Access Point).

                            Then you will have to look outside pfSense - for some reason pfSense is not seeing your pings.

                            @hcigmx:

                            I did try to pass through to VM, but wifi adapter not supported (Ralink RT5370).

                            The TP-Link WN321G is available retail near me for under AUS$10. I have used them with pfSense where it is supported by the run driver. It might be a more effective use of your time to get such a device and give pfSense exclusive use of it than to continue messing around trying to figure out what Windows is doing to your traffic.

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

                              @wallabybob:

                              Then you will have to look outside pfSense - for some reason pfSense is not seeing your pings.

                              I will. It's down to only host, VMware and AP.

                              @wallabybob:

                              It might be a more effective use of your time to get such a device and give pfSense exclusive use of it than to continue messing around trying to figure out what Windows is doing to your traffic.

                              Learning is a lifelong journey, and this problem gives an opportunity to learn more. Should the solution be found, it can contribute to knowledge growth of self and others.

                              Thanks so much for the time and efforts you have spared for me. I appreciate the troubleshooting process that we had gone through together. Your approach has been great and I commend you on this.

                              1 Reply Last reply Reply Quote 0
                              • W
                                wallabybob
                                last edited by

                                @hcigmx:

                                Switching of LAN adapters from wired to wifi was done in VM setting, so pfSense should not see anything different.

                                I have no experience with VMware but I suspect that in the VMware environment you have somehow failed to adjust something crucial when making that change.

                                Can you do a packet capture in VMware to verify VMware is seeing the ping traffic over WiFi? Can you trace where it goes then?

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post