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

    IPhone Tethering to pfSense

    Scheduled Pinned Locked Moved Hardware
    64 Posts 7 Posters 17.8k 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.
    • E
      eiger3970
      last edited by eiger3970

      Yes, the iPhone is capable of providing tethered internet via USB.
      The iPhone tethering worked on other machines previously, however I wanted to triple check before this response.

      There's something in the pfSense configuration I don't know needs to be done?
      According to post 6, point 8, the Default Gateway should be in IPv4, not IPv6 in my case.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Is it giving you an IP address now? You won't have a gateway on the iphone at all until it responds to dhcp.

        1 Reply Last reply Reply Quote 1
        • E
          eiger3970
          last edited by

          OPT1 IP address 0.0.0.0.

          On the iPhone, I do what I do to make the USB tether work on other machines.
          iPhone > passcode > Settings > Hotspot > turn on > Enable USB: yes.

          [2.4.4-RELEASE][root@pfSense.localdomain]/root: netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
0.0.0.0/8          link#1             U        vtnet0
localhost          link#4             UH          lo0
192.168.1.0/24     link#2             U        vtnet1
pfSense            link#2             UHS         lo0

Internet6:
Destination        Gateway            Flags     Netif Expire
localhost          link#4             UH          lo0
fe80::%vtnet0/64   link#1             U        vtnet0
fe80::4063:7cff:fe link#1             UHS         lo0
fe80::%vtnet1/64   link#2             U        vtnet1
fe80::a42d:d5ff:fe link#2             UHS         lo0
fe80::%lo0/64      link#4             U           lo0
fe80::1%lo0        link#4             UHS         lo0
fe80::%ue0/64      link#7             U           ue0
fe80::5cf9:38ff:fe link#7             UHS         lo0
          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hit renew/release on Status > Interfaces after doing that on the phone maybe?

            I would probably run a packet capture on ue0 and hit renew and see it anything is happening.

            Also check the dhcp logs for dhclient entries, you see an error there.

            Steve

            1 Reply Last reply Reply Quote 1
            • E
              eiger3970
              last edited by stephenw10

              pfSense > Diagnostics > Packet Capture > Interface: WAN2 > Start > Status > Interfaces > WAN2 > DHCP: Release > DHCP: renew > Diagnostics > Packet Capture > Interface: WAN > Stop > View Capture.

              16:32:42.061530 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:32:47.074104 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:32:47.074108 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:32:52.105408 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:32:52.105412 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:32:57.155403 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:33:02.175405 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:33:11.088430 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:33:30.070614 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:33:43.170645 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300

              pfSense > Status > System Logs > DHCP > no errors, only data from 20200226.

              Feb 26 20:37:25	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:37:26	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:37:27	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:37:28	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:37:29	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:37:30	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:37:32	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:37:34	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 5
Feb 26 20:37:39	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 10
Feb 26 20:37:49	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 18
Feb 26 20:38:01	dhclient		FAIL
Feb 26 20:38:07	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 12
Feb 26 20:38:19	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7
Feb 26 20:38:26	dhclient	80005	No DHCPOFFERS received.
Feb 26 20:38:26	dhclient	80005	No working leases in persistent database - sleeping.
Feb 26 20:38:26	dhclient		FAIL
Feb 26 20:38:41	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:38:42	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:38:43	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:38:45	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:38:47	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 5
Feb 26 20:38:52	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7
Feb 26 20:38:59	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 15
Feb 26 20:39:14	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 19
Feb 26 20:39:17	dhclient		FAIL
Feb 26 20:39:33	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 9
Feb 26 20:39:42	dhclient	80005	No DHCPOFFERS received.
Feb 26 20:39:42	dhclient	80005	No working leases in persistent database - sleeping.
Feb 26 20:39:42	dhclient		FAIL
Feb 26 20:39:57	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:39:58	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:40:00	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 5
Feb 26 20:40:05	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 5
Feb 26 20:40:10	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 13
Feb 26 20:40:23	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 15
Feb 26 20:40:34	dhclient		FAIL
Feb 26 20:40:38	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 12
Feb 26 20:40:50	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 7
Feb 26 20:40:57	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:40:58	dhclient	80005	No DHCPOFFERS received.
Feb 26 20:40:58	dhclient	80005	No working leases in persistent database - sleeping.
Feb 26 20:40:58	dhclient		FAIL
Feb 26 20:41:13	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:41:14	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:41:15	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 1
Feb 26 20:41:16	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 2
Feb 26 20:41:18	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 5
Feb 26 20:41:23	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 6
Feb 26 20:41:29	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 10
Feb 26 20:41:39	dhclient	80005	DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 17
              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                Hmm, so it looks like the phone is just not responding. Did you test it with a different device?

                Maybe it needs some other setting.

                1 Reply Last reply Reply Quote 1
                • E
                  eiger3970
                  last edited by

                  Yes, the USB tether works fine on other machines.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Hmm, well maybe the fact we are having to force the config index is because it should be triggered to use USB Ethernet some other way and that also starts it's DHCP server.

                    Are you able to connect it to a Linux device and check the logs it produces? Assuming it works there that is...

                    1 Reply Last reply Reply Quote 1
                    • E
                      eiger3970
                      last edited by

                      The logs of the iPhone.
                      I have and can connect to Linux machines, works quite easily.
                      I would have to connect the phone to a Mac to see phone logs.

                      I'm wondering if I should be tethering the phone to the hypervisor/host machine and then the guest machine will receive internet from the hypervisor. This might need a NAT?

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        I meant the logs from Linux to see if the driver there is doing something different when it connects.

                        You could certainly do it via the hypervisor and it might remove some of the other issues as pfSense would not lose its interface entirely when the phone goes away.

                        Steve

                        1 Reply Last reply Reply Quote 1
                        • E
                          eiger3970
                          last edited by eiger3970

                          I turned the phone's hotspot off and on and now pfSense > Dashboard > Interfaces > WAN2 > shows IP 172.20.10.2, however no internet?
                          I ran a packet capture on WAN2 and released and renewed pfSense's DHCP:

                          16:29:41.253535 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1579, length 8
16:29:41.254302 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1579, length 8
16:29:41.794815 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1580, length 8
16:29:41.795543 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1580, length 8
16:29:42.318548 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1581, length 8
16:29:42.319277 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1581, length 8
16:29:42.859812 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1582, length 8
16:29:42.860532 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1582, length 8
16:29:43.401119 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1583, length 8
16:29:43.401873 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1583, length 8
16:29:43.918606 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1584, length 8
16:29:43.919366 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1584, length 8
16:29:44.459820 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1585, length 8
16:29:44.460529 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1585, length 8
16:29:45.001220 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1586, length 8
16:29:45.001877 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1586, length 8
16:29:45.518565 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1587, length 8
16:29:45.519381 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1587, length 8
16:29:46.049059 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1588, length 8
16:29:46.049776 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1588, length 8
16:29:46.568677 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1589, length 8
16:29:46.569426 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1589, length 8
16:29:47.109973 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1590, length 8
16:29:47.110758 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1590, length 8
16:29:47.651276 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1591, length 8
16:29:47.652016 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1591, length 8
16:29:48.181561 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1592, length 8
16:29:48.182337 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1592, length 8
16:29:48.718567 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1593, length 8
16:29:48.719342 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1593, length 8
16:29:49.259824 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1594, length 8
16:29:49.260599 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1594, length 8
16:29:49.785768 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1595, length 8
16:29:49.786541 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1595, length 8
16:29:50.318557 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1596, length 8
16:29:50.319340 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1596, length 8
16:29:50.859828 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1597, length 8
16:29:50.860607 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1597, length 8
16:29:51.401151 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1598, length 8
16:29:51.401926 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1598, length 8
16:29:51.918886 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1599, length 8
16:29:51.919665 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1599, length 8
16:29:52.459833 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1600, length 8
16:29:52.460594 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1600, length 8
16:29:53.001153 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1601, length 8
16:29:53.001907 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1601, length 8
16:29:57.281694 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:29:59.341982 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
16:29:59.383330 IP 172.20.10.1.67 > 172.20.10.2.68: UDP, length 300
16:29:59.391820 ARP, Request who-has 172.20.10.2 tell 172.20.10.2, length 28
16:29:59.883076 ARP, Request who-has 172.20.10.1 tell 172.20.10.2, length 28
16:29:59.883793 ARP, Reply 172.20.10.1 is-at 7e:f9:38:ee:ce:64, length 28
16:29:59.883836 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1614, length 8
16:29:59.884565 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1614, length 8
16:30:00.418535 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 47792, seq 1615, length 8
16:30:00.419221 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 47792, seq 1615, length 8
16:30:00.800191 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 0, length 8
16:30:00.800921 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 0, length 8
16:30:01.320464 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 1, length 8
16:30:01.321142 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 1, length 8
16:30:01.853541 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 2, length 8
16:30:01.854420 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 2, length 8
16:30:02.394845 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 3, length 8
16:30:02.395598 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 3, length 8
16:30:02.918806 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 4, length 8
16:30:02.919570 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 4, length 8
16:30:03.449284 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 5, length 8
16:30:03.449999 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 5, length 8
16:30:03.968633 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 6, length 8
16:30:03.969444 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 6, length 8
16:30:04.509950 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 7, length 8
16:30:04.510678 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 7, length 8
16:30:05.051238 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 8, length 8
16:30:05.052120 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 8, length 8
16:30:05.568613 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 9, length 8
16:30:05.569395 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 9, length 8
16:30:06.109993 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 10, length 8
16:30:06.110784 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 10, length 8
16:30:06.651241 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 11, length 8
16:30:06.651907 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 11, length 8
16:30:07.171143 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 12, length 8
16:30:07.171940 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 12, length 8
16:30:07.712493 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 13, length 8
16:30:07.713222 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 13, length 8
16:30:08.253743 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 14, length 8
16:30:08.254494 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 14, length 8
16:30:08.768615 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 15, length 8
16:30:08.769382 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 15, length 8
16:30:09.309920 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 16, length 8
16:30:09.310669 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 16, length 8
16:30:09.851250 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 17, length 8
16:30:09.851977 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 17, length 8
16:30:10.392516 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 18, length 8
16:30:10.393279 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 18, length 8
16:30:10.918515 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 19, length 8
16:30:10.919171 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 19, length 8
16:30:11.432195 IP 172.20.10.2 > 172.20.10.1: ICMP echo request, id 24226, seq 20, length 8
16:30:11.432847 IP 172.20.10.1 > 172.20.10.2: ICMP echo reply, id 24226, seq 20, length 8
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Ok, that looks good. The ICMP traffic is all the gateway monitoring pings. The DHCP traffic looks correct.

                            Try running a pcap that excludes ICMP and the attempt to connect out. You might set more than 100 packets to capture it all.

                            Steve

                            1 Reply Last reply Reply Quote 1
                            • E
                              eiger3970
                              last edited by eiger3970

                              This is the best I could work out for a command for now?

                              [2.4.4-RELEASE][admin@pfSense.localdomain]/root: tcpdump -i ue0 not icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ue0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:46:09.537033 IP 172.20.10.2.45637 > 172.20.10.1.domain: 46894+ A? 0.pfsense.pool.ntp.org. (40)
19:46:09.765420 IP 172.20.10.1.domain > 172.20.10.2.45637: 46894 4/0/0 A 162.159.200.123, A 103.126.53.123, A 220.158.215.21, A 13.55.50.68 (104)
19:46:09.775543 IP 172.20.10.2.45125 > 172.20.10.1.domain: 24414+ AAAA? 0.pfsense.pool.ntp.org. (40)
19:46:09.842782 IP 172.20.10.1.domain > 172.20.10.2.45125: 24414 0/1/0 (95)
19:49:19.918225 ARP, Request who-has 172.20.10.1 tell 172.20.10.2, length 28
19:49:19.918900 ARP, Reply 172.20.10.1 is-at 7e:f9:38:ee:ce:64 (oui Unknown), length 28
19:50:28.529027 IP 172.20.10.2.28831 > 172.20.10.1.domain: 9581+ A? 0.pfsense.pool.ntp.org. (40)
19:50:28.717703 IP 172.20.10.1.domain > 172.20.10.2.28831: 9581 4/0/0 A 103.38.121.36, A 103.126.53.123, A 162.159.200.123, A 61.68.38.238 (104)
19:50:28.735163 IP 172.20.10.2.19977 > 172.20.10.1.domain: 37657+ AAAA? 0.pfsense.pool.ntp.org. (40)
19:50:28.737947 IP 172.20.10.1.domain > 172.20.10.2.19977: 37657 0/1/0 (95)
19:54:52.532912 IP 172.20.10.2.31905 > 172.20.10.1.domain: 54338+ A? 0.pfsense.pool.ntp.org. (40)
19:54:52.930417 IP 172.20.10.1.domain > 172.20.10.2.31905: 54338 4/0/0 A 116.66.161.4, A 13.55.50.68, A 220.158.215.20, A 129.250.35.250 (104)
19:54:52.940835 IP 172.20.10.2.20605 > 172.20.10.1.domain: 8304+ AAAA? 0.pfsense.pool.ntp.org. (40)
19:54:52.945359 IP 172.20.10.1.domain > 172.20.10.2.20605: 8304 0/1/0 (95)
                              1 Reply Last reply Reply Quote 0
                              • GertjanG
                                Gertjan
                                last edited by Gertjan

                                That's a partial ntp discussion, loading the list with peers from the default "0.pfsense.pool.ntp.org" pool.

                                edit : wait ..... you are really using an iPhone, the 'USB cable' as a networked WAN device ? Interesting.

                                No "help me" PM's please. Use the forum, the community will thank you.
                                Edit : and where are the logs ??

                                E 1 Reply Last reply Reply Quote 1
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  Looks like it's querying DNS on the phone. We've yet to see anything other than the phone's local IP as the destination.

                                  Does pfSense still have some other gateway it's using?

                                  You can specify that gateway of you go to Diag > Ping, say, and ping something external. You should see that in a packet capture.

                                  Steve

                                  1 Reply Last reply Reply Quote 1
                                  • E
                                    eiger3970
                                    last edited by eiger3970

                                    VM pfSense Interfaces are:
                                    WAN (the old Ethernet connection via the hypervisor), currently showing IP address 0.0.0.0.
                                    LAN (the current and working local area network), currently showing IP address 192.168.1.170.
                                    WAN2 (the USB passthrough from the hypervisor to VM pfSense), currently showing IP address 0.0.0.0.

                                    The hypervisor has the VM pfSense Hardware with a network device configured as:
                                    net0 virtio=ma:ca:dd:re:ss:00,bridge=vmbr0
                                    net1 virtio=ma:ca:dd:re:ss:01,bridge=vmbr1

                                    vmbr0 was the WAN to the previous internet cable provider.
                                    vmbr1 is the LAN interface.

                                    I pinged 1.1.1.1 and the packet capture output is:

                                    00:08:09.210929 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:09.210933 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:09.210937 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:14.260926 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:19.310932 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:24.390930 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
00:08:34.042525 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
                                    1 Reply Last reply Reply Quote 0
                                    • E
                                      eiger3970 @Gertjan
                                      last edited by eiger3970

                                      @Gertjan Yes, however I'm wondering if it is easier to have the hypervisor be the WAN (instead of a USB passthrough to the vm pfSense router).
                                      Just a bit confused on the whole setup.

                                      The phone USB internet works fine on other computers.

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        You probably need to toggle the hotspot again if it has no IP address. That last pcap just shows no response to pfSense's DHCP requests. Interesting that it's also failing to pull an IP on the main WAN though. Makes me wonder of this is something the hypervisor is doing. Can you test it bare metal on anything?

                                        Steve

                                        1 Reply Last reply Reply Quote 1
                                        • E
                                          eiger3970
                                          last edited by eiger3970

                                          I toggled the phone by opening the welcome screen > Settings > Mobile > Hotspot > turned off and on > selected USB only > phone indicates it is connected to hotspot.

                                          pfSense then shows the Dashboard Interfaces with WAN2 IP 172.20.10.2, which is the phone.
                                          However no traffic?

                                          12:12:48.093151 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:07.432580 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:08.440452 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:09.493191 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:11.566071 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:15.443262 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:22.000205 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
12:13:31.193173 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 42:63:7c:e4:6c:e3 (oui Unknown), length 300
^C
76 packets captured
76 packets received by filter
0 packets dropped by kernel

                                          Bit confused, as plugging into this computer I'm posting from, Internet via phone USB works.

                                          1 Reply Last reply Reply Quote 0
                                          • E
                                            eiger3970
                                            last edited by eiger3970

                                            I rebooted pfSense.

                                            WAN2 interface shows as n/a.

                                            Opened iPhone > mobile data and hotspot on (but not connected) > had to select Trust. Turned hotspot off, then on, then selected USB only (not wifi).

                                            pfSense > shell > ifconfig shows interface ue0.
                                            pfSense > shell > /boot/loader.conf.local has same code:
                                            kern.cam.boot_delay=10000
                                            kern.ipc.nmbclusters=”1000000”
                                            kern.ipc.nmbjumbop=”524288”
                                            kern.ipc.nmbjumbo9=”524288”
                                            if_ipheth_load=”YES”
                                            hw.usb.quirk.0=”0x05ac 0x12a8 0 0xffff UQ_CFG_INDEX_3”
                                            autoboot_delay=”3”

                                            pfSense > shell > netstat -r > ue0 is an Internet6 gateway.

                                            pfSense Dashboard Interfaces still shows:
                                            WAN, green arrow up, 10Gbase-T <full-duplex>, 0.0.0.0
                                            LAN, green arrow up, 10Gbase-T <full-duplex>< 192.168.1.170
                                            WAN2, green arrow up, blank, n/a.

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