IPhone Tethering to pfSense
-
Oh wow!
pfSense GUI > Interfaces > Interface Assignments > shows Available network ports: ue0I will try to follow a GUI guide now for the final setup.
Yes, the USB device is an iPhone 5C.
'It' needs to be using index 3...is it referring to the iPhone or pfSense?
-
Ok, pfSense reboot needs the setup run each time. I won't be rebooting the router much, so that's ok, until perhaps the kernel module if_ipheth.ko udates the code?
I.e.:
usbconfig -d ugen4.2 set_config 3.So, running the GUI:
pfSense 2.4.4-RELEASE-p2 > Interfaces > Assignments > Add ue0 (Ma:cA:dd:re:ss:00) > OPT1 ue0 appears > Save > Interfaces > OPT1 > General Configuration > Enable: tick Enable interface > IPv4 Configuration Type: DHCP > Save > Apply Changes > System > Routing > Gateways > OPT1_DHCP should be Default > pfSense shell: netstat -r > Enter > problem as ue0 is in Internet 6 and not in Internet? -
If it helps, here are my network topologies from Ethernet modem to USB modem.
Ethernet modem:
USB modem:
Perhaps the USB modem topology needs the net0 = vmbr1 to be updated to OPT1 = vmbr1?
-
Ok great if config index 3 works you can have that set every time at boot using a usb quirk
https://www.freebsd.org/cgi/man.cgi?query=usb_quirkAdd to /boot/loader.conf.local:
hw.usb.quirk.0="0x05ac 0x12a8 0 0xffff UQ_CFG_INDEX_3"
There real issue with this type of setup is that if the phone switches off or is unplugged or in some other way is no longer present and you reboot pfSense it will fail to boot. It will stop at the interfaces assign screen because it has ue0 in it's config and it isn't there.
Steve
-
Thank you, that works after a reboot.
I updated file /boot/loader.conf, there was not file /boot/loader.conf.local.So, the final thing is configuring pfSense GUI to pass data.
Interfaces > Assignments > OPT1 ue0 (53:f9:38:33:18:4f).
Interfaces > OPT > Enabled interface. IPv4 Configuration Type: DHCP.
System > Routing > Gateways > OPT1_DHCP is Default (IPv4).
Dashboard > Interfaces > OPT1 > green up arrow with IP 0.0.0.0. -
Yeah, you will have to create the .local file but you should put both lines in there. The standard loader.conf file can be overwritten by changes in pfSense.
If it's not pulling an IP address that would seem to be some setting in the iphone. Is tethering actually enabled there?
Does it work as a wireless hotspot?Steve
-
Oh, thank you.
Done.Tethering is enabled. No wifi on the hypervisor.
I'll check the hardware tomorrow.[2.4.4-RELEASE][admin@pfSense.localdomain]/boot: 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
-
Yeah just to check the iphone is capable of doing this. Maybe connect it to something else, a laptop.
-
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. -
Is it giving you an IP address now? You won't have a gateway on the iphone at all until it responds to dhcp.
-
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
-
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
-
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
-
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.
-
Yes, the USB tether works fine on other machines.
-
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...
-
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?
-
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
-
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
-
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