When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface
-
When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface, from the LAN can be ping without problems. This causes that HAPROXY only works with ipv6 from the LAN interface, and is not the scenario that I would like. It also causes the installation of packages to take too long, up to half an hour each package, and only installing by command line, the web installation does not work. This is caused because not manages to access the package repositories through Ipv6, which is predetermined in the WAN interface, and until it manages to download by ipv4, it has been a long time.
I get native Ipv6 through my ISP and that way it was working without problems, in LAN and in WAN, until this update.
The environment is bare metal in production, but there are I have the same problems in virtualized environments under XEN, most have been solved by making a clean installation and generating new configurations from scratch, which is already a huge annoyance with preconfigured snort rules, example. But the most annoying problem with the ipv6 connection from wan follows, from a clean installation, without packages installed.
Thanks and sorry for my english
-
I'm sure it's a bug in version 2.4.4, which came out in a hurry. I reported this and other failures at the site where the bugs were reported and I was told that I should report it through this way. I'm doing it, but I do not see any interest either over here. In Pfsense there is not even a way to install a previous version.
-
I have no problem pinging an IPv6 address from pfSense.
-
@jknott I do have problems. Would someone like to investigate it?
-
@jknott If you tell me what additional information you need, I gladly provide it. The problem arose with this update and in two different environments. All the configuration worked in previous versions of Pfsense for more than a year. I also tried it with the default configuration and with the same result.
-
From WAN:
PING6(56=40+8+8 bytes) 2800:bf0:9fff:xxxx:xxx:xxxx:xxxx:xxxx --> 2606:4700:30::681c:d34--- rebelion.org ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossFrom LAN:
PING6(56=40+8+8 bytes) 2800:bf0:xxxx:xxxx:xxx:xxxx:xxxx:xxxx --> 2606:4700:30::681c:d34
16 bytes from 2606:4700:30::681c:d34, icmp_seq=0 hlim=53 time=96.966 ms
16 bytes from 2606:4700:30::681c:d34, icmp_seq=1 hlim=53 time=97.079 ms
16 bytes from 2606:4700:30::681c:d34, icmp_seq=2 hlim=53 time=96.010 ms--- rebelion.org ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 96.010/96.685/97.079/0.480 ms -
I am seeing the same thing with my SG-3100 applicance running on 2.4.4...
I can ping6 from LAN devices without a problem, but I cannot from a shell on the router.
And same as you, software updates take a long time as the router tries IPv6 first and only when it times out does it try IPv4. -
me too no problems. check your 4th okted, maybe there is something wrong? traceroute?
-
@yellowbrick Thanks for your report. That helped someone ask questions, the questions are important for the discovery, answering only that you do not have the problem is not very helpful. A hug.
-
@pfadmin A huge thank you for your questions. I know you do not have the problem, but I do and I'm not the only one, as you can see in the previous comment.
Traceroue output:
traceroute from wan:
1 2800:bf0:9fff:f110::1 2.702 ms 1.517 ms 2.673 ms
2 2800:bf0:9fff:f100::1 2.790 ms 2.471 ms 2.793 ms
3 fc00:0:0:600::1 1.756 ms 1.622 ms 1.733 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *Traceroute from LAN:
1 2800:bf0:9fff:f111::1 4.482 ms 1.862 ms 3.859 ms
2 2800:bf0:9fff:f100::1 3.641 ms 2.359 ms 2.915 ms
3 fc00:0:0:600::1 1.691 ms 3.023 ms 1.492 ms
4 * * *
5 2800:2a0:10:101:11::211 72.568 ms 77.331 ms 74.598 ms
6 2001:1900:2100::238d 70.480 ms 70.430 ms 72.982 ms
7 2001:1900::3:132 75.741 ms 76.288 ms 75.676 ms
8 2001:1900:4:3::18e 88.305 ms 75.839 ms 70.418 ms
9 2001:41a8:4020::13 84.835 ms 70.486 ms 70.600 ms
10 2001:41a8:4020:2::c2 97.255 ms 97.499 ms 93.197 ms
11 2400:cb00:17:1024::a29e:79b2 96.907 ms
2400:cb00:17:1024::a29e:784d 100.754 ms
2400:cb00:17:1024::a29e:7805 100.615 msAs I said above I tried with the factory settings and the result is the same. The current configuration had no problems and I have not changed it since version 2.4.2.
On 4th okted I would appreciate you explain to me to verify. I do not find information on this on the internet.
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
2606:4700:30::681c:d34
From one of my customer boxes. Comcast connection.
PING6(56=40+8+8 bytes) 2001:558:xxxxxxxxxxxxxxxxxxxx --> 2606:4700:30::681c:d34
16 bytes from 2606:4700:30::681c:d34, icmp_seq=0 hlim=58 time=16.638 ms
16 bytes from 2606:4700:30::681c:d34, icmp_seq=1 hlim=58 time=12.921 ms
16 bytes from 2606:4700:30::681c:d34, icmp_seq=2 hlim=58 time=13.744 ms
16 bytes from 2606:4700:30::681c:d34, icmp_seq=3 hlim=58 time=13.252 ms--- 2606:4700:30::681c:d34 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 12.921/14.139/16.638/1.472 msWorks fine. May be something your ISP is doing??
-
@chpalmer Regarding your question: "Works fine. May be something your ISP is doing???" I can assure you that the problem starts with version 2.4.4. When I have been able to install a previous virtual version, from a snapshot, directly connected to the optical fiber ONT, everything works the way it is expected. I really do not think that event coincides with something the ISP does. I repeat that it worked fine, with the same configuration, before the update to 2.4.4
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
fc00:0:0:600::1
https://en.wikipedia.org/wiki/IPv6_address
fc00::/7 is a ULA
What happens if you use the option -s ?
Usage: traceroute [-adDeFInrSvx] [-f first_ttl] [-g gateway] [-i iface]
[-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr]
[-t tos] [-w waittime] [-A as_server] [-z pausemsecs] host [packetlen][2.4.4-RELEASE][admin@pfsense]/root: traceroute6 -s 2a02:xxxx:xxxx:xxxx::1 2a02:8010:1:0:212:23:3:100
traceroute6 to 2a02:8010:1:0:212:23:3:100 (2a02:8010:1:0:212:23:3:100) from 2a02:xxxx:xxxx:xxxx::1 , 64 hops max, 20 byte packets
1 lo-0.cor2.lond1.ptn.zen.net.uk 10.671 ms 9.486 ms 9.277 ms
2 ae-13.cor2.manc1.ptn.zen.net.uk 17.043 ms 28.985 ms 20.455 ms
3 ae-22.cor1.manc1.ptn.zen.net.uk 16.278 ms 21.254 ms 21.568 ms
4 ae-23.cor1.roch1.ptn.zen.net.uk 20.429 ms 16.365 ms 16.597 ms
5 2a02:8010:0:a00:: 14.285 ms 28.466 ms 15.194 ms
6 2a02:8010:0:207::2 14.772 ms 14.343 ms 14.794 ms
7 cache01.dns.zen.net.uk 15.447 ms !P 14.768 ms !P 14.754 ms !P
[2.4.4-RELEASE][admin@pfsense]/root:Maybe do a packet capture on the WAN and open it in wireshark.
-
@nogbadthebad
from WAN:
traceroute6 -s 2800:bf0:9fff:xxxx:xxx:xxxx:xxxx:xxxx 2a02:8010:1:0:212:23:3:100
traceroute6 to 2a02:8010:1:0:212:23:3:100 (2a02:8010:1:0:212:23:3:100) from 2800:bf0:9fff:xxxx:xxx:xxxx:xxxx:xxxx, 64 hops max, 20 byte packets
1 2800:bf0:9fff:f110::1 2.599 ms 2.243 ms 2.207 ms
2 2800:bf0:9fff:f100::1 2.394 ms 2.369 ms 2.441 ms
3 fc00:0:0:600::1 1.994 ms 1.637 ms 1.683 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *from LAN:
traceroute6 -s 2800:bf0:81c0:xxxx:xxx:xxxx:xxxx:xxxx 2a02:8010:1:0:212:23:3:100
traceroute6 to 2a02:8010:1:0:212:23:3:100 (2a02:8010:1:0:212:23:3:100) from 2800:bf0:81c0:xxxx:xxx:xxxx:xxxx:xxxx, 64 hops max, 20 byte packets
1 2800:bf0:9fff:f111::1 3.459 ms 2.361 ms 3.280 ms
2 2800:bf0:9fff:f100::1 3.107 ms 2.593 ms 2.265 ms
3 fc00:0:0:600::1 1.763 ms 1.724 ms 1.795 ms
4 * * *
5 2800:2a0:10:101:11::211 71.608 ms 76.455 ms 75.247 ms
6 xe-9-2-0.edge2.LosAngeles9.Level3.net 70.580 ms 71.078 ms 70.428 ms
7 * * *
8 NTT-level3-1x10G.Madrid.Level3.net 70.580 ms 77.561 ms 83.484 ms
9 ae-7.r04.miamfl02.us.bb.gin.ntt.net 72.544 ms 72.455 ms 72.457 ms
10 ae-8.r20.miamfl02.us.bb.gin.ntt.net 70.412 ms 70.779 ms 70.630 ms
11 ae-4.r23.asbnva02.us.bb.gin.ntt.net 100.332 ms 99.949 ms 99.625 ms
12 ae-0.r22.asbnva02.us.bb.gin.ntt.net 94.707 ms 100.264 ms 97.873 ms
13 ae-5.r25.nycmny01.us.bb.gin.ntt.net 99.857 ms 100.454 ms 100.296 ms
14 ae-1.r24.nycmny01.us.bb.gin.ntt.net 97.993 ms 99.637 ms 98.212 ms
15 ae-9.r24.londen12.uk.bb.gin.ntt.net 165.782 ms 165.254 ms 169.869 ms
16 ae-8.r02.londen03.uk.bb.gin.ntt.net 166.849 ms 165.433 ms 170.634 ms
17 xe-0-1-0-1-7.r02.londen03.uk.ce.gin.ntt.net 176.106 ms 163.838 ms 164.328 ms
18 ae0.cr1.th-lon.zen.net.uk 189.817 ms 196.175 ms 202.502 ms
19 ae4-0.cr1.wh-man.zen.net.uk 180.254 ms 180.711 ms 214.937 ms
20 ae0-0.dr1.sp-roch.zen.net.uk 183.841 ms 183.225 ms 183.929 ms
21 2a02:8010:0:205::2 176.856 ms 179.267 ms 180.045 ms
22 cache01.dns.zen.net.uk 188.908 ms !P 190.330 ms !P 185.477 ms !P -
@nogbadthebad Please explain the packages you should capture and the way to do it. Thank you
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
@chpalmer I really do not think that event coincides with something the ISP does. I repeat that it worked fine, with the same configuration, before the update to 2.4.4
So if mine and everyone else's works why do you think your issue is a problem caused by pfsense other than "it worked before"?
(Please explain the packages you should capture and the way to do it. Thank you) -
/diag_packet_capture.php
[2.4.4-RELEASE][admin@xxxxxx.xxxxxxx.org]/root: traceroute6 -s 2xxxxxxxxx 2a02:8010:1:0:212:23:3:100
traceroute6 to 2a02:8010:1:0:212:23:3:100 (2a02:8010:1:0:212:23:3:100) from 2001:xxxxxxxxxxxxxxxxxxxx, 64 hops max, 20 byte packets
1 2001:558:600a:cf::1 13.859 ms 9.883 ms 9.237 ms
2 po-107-rur01.tumwater.wa.seattle.comcast.net 9.899 ms 9.964 ms 9.775 ms
3 po-2-rur02.tumwater.wa.seattle.comcast.net 8.105 ms 11.319 ms 9.661 ms
4 be-44-ar01.seattle.wa.seattle.comcast.net 13.879 ms 13.628 ms 13.768 ms
5 be-33650-cr01.seattle.wa.ibone.comcast.net 15.052 ms * 16.749 ms
6 *
be-10847-pe02.seattle.wa.ibone.comcast.net 13.869 ms *
7 ae-31.a00.sttlwa01.us.bb.gin.ntt.net 13.663 ms 15.770 ms 13.494 ms
8 ae-9.r04.sttlwa01.us.bb.gin.ntt.net 14.514 ms 13.721 ms
ae-14.r05.sttlwa01.us.bb.gin.ntt.net 14.077 ms
9 ae-2.r22.sttlwa01.us.bb.gin.ntt.net 13.764 ms 14.382 ms
ae-1.r22.sttlwa01.us.bb.gin.ntt.net 17.675 ms
10 ae-0.r24.nycmny01.us.bb.gin.ntt.net 88.579 ms 101.201 ms 85.140 ms
11 ae-9.r24.londen12.uk.bb.gin.ntt.net 156.562 ms 151.233 ms 150.401 ms
12 ae-8.r02.londen03.uk.bb.gin.ntt.net 153.440 ms 153.703 ms 148.896 ms
13 xe-0-1-0-1-7.r02.londen03.uk.ce.gin.ntt.net 156.026 ms 158.485 ms 158.553 ms
14 ae0.cr1.th-lon.zen.net.uk 158.899 ms 153.132 ms 155.254 ms
15 ae4-0.cr1.wh-man.zen.net.uk 166.248 ms 193.078 ms 166.346 ms
16 ae0-0.dr1.sp-roch.zen.net.uk 164.142 ms 184.691 ms 161.297 ms
17 2a02:8010:0:205::2 173.480 ms 168.982 ms 159.820 ms
18 cache01.dns.zen.net.uk 161.215 ms !P 165.877 ms !P 169.071 ms !P
[2.4.4-RELEASE][admin@xxxxx.xxxxx.org]/root: -
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
So if mine and everyone else's works why do you think your issue is a problem caused by pfsense other than "it worked before"?
I do not understand this question. I think it is not a help, but it can be a difficulty with the interpretation of the language or culture, if not, I do not see how we move forward.
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
So if mine and everyone else's works why do you think your issue is a problem caused by pfsense other than "it worked before"?
I do not understand this question. I think it is not a help, but it can be a difficulty with the interpretation of the language or culture, if not, I do not see how we move forward.
Im trying to reason with you. You obviously have a problem that we do not have. We cannot diagnose your issue because it does not exist for us.
Do you know how to take screen shots and post them?
-
Show us this page.
-
-
@chpalmer Yes I know how to capture screens and publish them
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
I get native Ipv6 through my ISP
This is what you said...
But according to your gateway your ISP is using SLAAC which is a tunneling protocol. This was important to state up front.
I do not have such a connection to test with.
-
@chpalmer Does not use SLAAC. Once I configured it that way and it stayed with that name, which I can not change from the original configuration. When performing a factory configuration, the gateway displays the correct name that is DHCP6.
-
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
I get native Ipv6 through my ISP
What I say is true
-
-
@chpalmer I do not have the slightest interest in telling lies. thanks for your help
-
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
SLAAC which is a tunneling protocol
Can you please refer me to a source that explains your say?
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
SLAAC which is a tunneling protocol
Can you please refer me to a source that explains your say?
Looks like I remembered wrong. Doesn't matter though if your not using it.
On your WAN page.. go down to DHCP6 Client Configuration.. Can you uncheck "only request an IPv6 prefix, do not request an IPv6 address" and try again..
-
@chpalmer I did it now and the result was that ipv6 address was lost in LAN and WAN
-
With a prefix of 64 you can only have global IPv6 addresses on one Interface, either WAN or LAN. If you want to have them on both you need a smaller prefix like 56.
-
@grimson Thank you for your contribution. With that configuration you get ipv6 address in wan and in lan, under Pfsense 2.4.4 there is no ping from wan, yes from LAN. With the same configuration in Pfsense 2.4.3_p1 and earlier, I got ipv6 address in wan and in lan and I could also do piing from wan and from lan
I tried your suggestion of a prefix of 56, the result was that the IPV6 address in LAN was lost. In Wan you get IPV6 address, but it does not ping.
-
@fabianburpf said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
@nogbadthebad Please explain the packages you should capture and the way to do it. Thank you
Diagnostics -> Packet Capture
When I traceroute to the 1st & 2nd hops I get nowhere.
Am I correct in saying your in Latin America ?
Last login: Wed Nov 21 08:17:09 on console
mac-pro:~ andy$ traceroute6 2800:bf0:9fff:f100::1
traceroute6 to 2800:bf0:9fff:f100::1 (2800:bf0:9fff:f100::1) from 2a02:xxxx:xxxx:2::14, 64 hops max, 12 byte packets
1 pfsense-user 1.950 ms 1.806 ms 1.812 ms
2 * * *
^C
mac-pro:~ andy$ traceroute6 2800:bf0:9fff:f110::1
traceroute6 to 2800:bf0:9fff:f110::1 (2800:bf0:9fff:f110::1) from 2a02:xxxx:xxxx:2::14, 64 hops max, 12 byte packets
1 pfsense-user 1.998 ms 1.769 ms 1.782 ms
2 * * *
^C
mac-pro:~ andy$ -
@chpalmer said in When making the update to 2.4.4 it is impossible to ping IPV6 from the WAN interface:
But according to your gateway your ISP is using SLAAC which is a tunneling protocol
SLAAC is not a tunneling protocol. It's the usual way IPv6 works on a LAN to assign prefix and default route.
-
Can't help but... Puh. @fabianburpf please keep in mind that everyone here is a kind voluntary helping you. This is not a paid service and even with paid service you should have more understanding that a answer can take some time...
-
@nogbadthebad Thanks for your accuracy. Yes, from South America. I put the output on the screen of the packet capture, I have the file and I have opened it in wireshark, but I would not like to expose my ip the world. Could be shared by internal or look for something specific in wireshark if it is explained please.
1 2800:bf0:9fff:f100::1 2.548 ms 2.218 ms 3.026 ms
2 fc00:0:0:600::1 1.681 ms 1.596 ms 1.445 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *07:27:06.813502 ARP, Request who-has 186.3.148.114 tell 186.3.148.1, length 46
07:27:06.813641 ARP, Request who-has 186.3.148.117 tell 186.3.148.1, length 46
07:27:07.113379 IP6 fe80::21b:21ff:fe36:8838 > fe80::4682:e5ff:fe9e:5af4: ICMP6, echo request, seq 6215, length 8
07:27:07.115516 IP6 fe80::4682:e5ff:fe9e:5af4 > fe80::21b:21ff:fe36:8838: ICMP6, echo reply, seq 6215, length 8
07:27:07.176381 IP 181.xxx.xxx.xx > 181.xxx.xxx.1: ICMP echo request, id 58440, seq 6159, length 8
07:27:07.178665 IP 181.xxx.xxx.1 > 181.xxx.xxx.xx: ICMP echo reply, id 58440, seq 6159, length 8
07:27:07.446205 ARP, Request who-has 181.199.122.186 tell 181.199.122.161, length 46
07:27:07.645626 IP6 fe80::21b:21ff:fe36:8838 > fe80::4682:e5ff:fe9e:5af4: ICMP6, echo request, seq 6216, length 8
07:27:07.647823 IP6 fe80::4682:e5ff:fe9e:5af4 > fe80::21b:21ff:fe36:8838: ICMP6, echo reply, seq 6216, length 8
07:27:07.708603 IP 181.xxx.xxx.xx > 181.xxx.xxx.1: ICMP echo request, id 58440, seq 6160, length 8
07:27:07.710832 IP 181.xxx.xxx.1 > 181.xxx.xxx.xx: ICMP echo reply, id 58440, seq 6160, length 8
07:27:07.746682 IP 181.xxx.xxx.xx.56353 > 164.73.227.4.123: UDP, length 48
07:27:07.997758 IP 164.73.227.4.123 > 181.xxx.xxx.xx.56353: UDP, length 48
07:27:08.070013 IP 181.xxx.xxx.xx.23758 > 185.61.149.247.8080: tcp 543
07:27:08.177896 IP6 fe80::21b:21ff:fe36:8838 > fe80::4682:e5ff:fe9e:5af4: ICMP6, echo request, seq 6217, length 8
07:27:08.180019 IP6 fe80::4682:e5ff:fe9e:5af4 > fe80::21b:21ff:fe36:8838: ICMP6, echo reply, seq 6217, length 8
07:27:08.211401 IP 181.xxx.xxx.xx > 181.xxx.xxx.1: ICMP echo request, id 58440, seq 6161, length 8
07:27:08.213577 IP 181.xxx.xxx.1 > 181.xxx.xxx.xx: ICMP echo reply, id 58440, seq 6161, length 8
07:27:08.264519 IP 185.61.149.247.8080 > 181.xxx.xxx.xx.23758: tcp 0
07:27:08.451285 ARP, Request who-has 181.199.122.172 tell 181.199.122.161, length 46
07:27:08.475740 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.507132 IP 181.xxx.xxx.xx.38459 > 156.154.70.22.53: UDP, length 58
07:27:08.507570 IP 181.xxx.xxx.xx.14096 > 129.250.35.250.53: UDP, length 58
07:27:08.568845 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 0
07:27:08.573122 IP 129.250.35.250.53 > 181.xxx.xxx.xx.14096: UDP, length 216
07:27:08.573325 IP 181.xxx.xxx.xx.16882 > 156.154.70.22.53: UDP, length 74
07:27:08.576859 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.576871 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 214
07:27:08.606145 IP 156.154.70.22.53 > 181.xxx.xxx.xx.38459: UDP, length 169
07:27:08.606329 IP 181.xxx.xxx.xx.22780 > 156.154.70.22.53: UDP, length 74
07:27:08.669991 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.670024 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.670041 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.670083 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1265
07:27:08.673056 IP 156.154.70.22.53 > 181.xxx.xxx.xx.16882: UDP, length 176
07:27:08.673293 IP 181.xxx.xxx.xx.28889 > 129.250.35.250.53: UDP, length 66
07:27:08.676331 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.676343 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.690703 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 93
07:27:08.705025 IP 156.154.70.22.53 > 181.xxx.xxx.xx.22780: UDP, length 126
07:27:08.705121 IP6 fe80::21b:21ff:fe36:8838 > fe80::4682:e5ff:fe9e:5af4: ICMP6, echo request, seq 6218, length 8
07:27:08.705203 IP 181.xxx.xxx.xx.6664 > 156.154.70.22.53: UDP, length 66
07:27:08.707243 IP6 fe80::4682:e5ff:fe9e:5af4 > fe80::21b:21ff:fe36:8838: ICMP6, echo reply, seq 6218, length 8
07:27:08.737922 IP 129.250.35.250.53 > 181.xxx.xxx.xx.28889: UDP, length 132
07:27:08.738023 IP 181.xxx.xxx.xx > 181.xxx.xxx.1: ICMP echo request, id 58440, seq 6162, length 8
07:27:08.740206 IP 181.xxx.xxx.1 > 181.xxx.xxx.xx: ICMP echo reply, id 58440, seq 6162, length 8
07:27:08.782830 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 51
07:27:08.791498 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 1440
07:27:08.791510 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 50
07:27:08.803703 IP 156.154.70.22.53 > 181.xxx.xxx.xx.6664: UDP, length 82
07:27:08.807853 IP 181.xxx.xxx.xx.60416 > 52.114.74.45.443: tcp 0
07:27:08.828750 IP 181.xxx.xxx.xx.54991 > 156.154.70.22.53: UDP, length 49
07:27:08.829016 IP 181.xxx.xxx.xx.28423 > 129.250.35.250.53: UDP, length 49
07:27:08.883270 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 0
07:27:08.898722 IP 129.250.35.250.53 > 181.xxx.xxx.xx.28423: UDP, length 230
07:27:08.898913 IP 181.xxx.xxx.xx.35970 > 129.250.35.250.53: UDP, length 67
07:27:08.927912 IP 156.154.70.22.53 > 181.xxx.xxx.xx.54991: UDP, length 183
07:27:08.928089 IP 181.xxx.xxx.xx.24595 > 129.250.35.250.53: UDP, length 67
07:27:08.961641 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961654 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961663 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961672 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961692 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961704 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961712 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961721 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961740 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961751 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.961760 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:08.963040 IP 129.250.35.250.53 > 181.xxx.xxx.xx.35970: UDP, length 199
07:27:08.963165 IP 181.xxx.xxx.xx.22772 > 129.250.35.250.53: UDP, length 70
07:27:08.976321 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.976333 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.976343 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.976353 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:08.981977 IP 52.114.74.45.443 > 181.xxx.xxx.xx.60416: tcp 0
07:27:08.995481 IP 129.250.35.250.53 > 181.xxx.xxx.xx.24595: UDP, length 149
07:27:08.995694 IP 181.xxx.xxx.xx.14894 > 156.154.70.22.53: UDP, length 70
07:27:09.027279 IP 129.250.35.250.53 > 181.xxx.xxx.xx.22772: UDP, length 178
07:27:09.027463 IP 181.xxx.xxx.xx.28988 > 129.250.35.250.53: UDP, length 64
07:27:09.067648 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067670 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067686 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067702 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067740 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067749 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067844 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.067854 IP 52.184.162.170.443 > 181.xxx.xxx.xx.44856: tcp 1460
07:27:09.093287 IP 129.250.35.250.53 > 181.xxx.xxx.xx.28988: UDP, length 154
07:27:09.093453 IP 181.xxx.xxx.xx.46553 > 129.250.35.250.53: UDP, length 70
07:27:09.093856 IP 156.154.70.22.53 > 181.xxx.xxx.xx.14894: UDP, length 128
07:27:09.093994 IP 181.xxx.xxx.xx.27185 > 156.154.70.22.53: UDP, length 70
07:27:09.097456 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.097467 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.097478 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.097485 IP 181.xxx.xxx.xx.60416 > 52.114.74.45.443: tcp 0
07:27:09.107050 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.107067 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.107077 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0
07:27:09.107448 IP 181.xxx.xxx.xx.44856 > 52.184.162.170.443: tcp 0 -