On Wednesday, August 15, 2018, 12:40:29 AM GMT+2, Tom Eastep <teas...@shorewall.net> wrote: > The only thing that I see is heavy upload traffic to port 80 at IP > address 31.216.144.11. > > There are no ARP packets in the entire pcap file, so it isn't a problem > of the upstream router not being able to determine the L2 address of > your gateway. Given that the echo-request packets are being sent, that > is about the only thing that your gateway could be involved in that > would result in dropped incoming echo-reply packets. > > There are also some retransmissions of TCP packets going on, but that > isn't all that unusual. > > I think that the next step I would take would be to pick a destination > "closer" to your gateway; use 'traceroute' to determine the IP address > of the router that is a couple of hops from your gateway and ping that. > If you don't see packet loss in those pings, then the problem is likely > beyond that router.
Thanks for helping out. I noticed that whichever interface I use to run "traceroute" (enp9s4 for ISP1, enp9s5 for ISP2, enp9s6 for ISP3) I always get an unknown and unpingable private IP address at hop #2 (192.168.144.1): # traceroute -n -i enp9s6 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.101.1 0.378 ms 0.521 ms 0.657 ms 2 192.168.144.1 5.366 ms 5.435 ms 5.437 ms [...] The modem/router's LAN IPv4 address is 192.168.101.1, and is pingable from the Shorewall gateway. I checked the modem/router's configuration for anything related to 192.168.144.*, but found nothing. I ran this on the gateway: # nmap -vv -Pn -e enp9s6 192.168.144.1 Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-16 09:02 CEST Initiating Parallel DNS resolution of 1 host. at 09:02 Completed Parallel DNS resolution of 1 host. at 09:02, 13.04s elapsed Initiating SYN Stealth Scan at 09:02 Scanning 192.168.144.1 [1000 ports] SYN Stealth Scan Timing: About 15.45% done; ETC: 09:05 (0:02:50 remaining) SYN Stealth Scan Timing: About 30.00% done; ETC: 09:05 (0:02:22 remaining) SYN Stealth Scan Timing: About 44.55% done; ETC: 09:05 (0:01:53 remaining) SYN Stealth Scan Timing: About 59.55% done; ETC: 09:05 (0:01:22 remaining) SYN Stealth Scan Timing: About 74.65% done; ETC: 09:05 (0:00:51 remaining) Completed SYN Stealth Scan at 09:05, 202.83s elapsed (1000 total ports) Nmap scan report for 192.168.144.1 Host is up, received user-set. All 1000 scanned ports on 192.168.144.1 are filtered because of 1000 no-responses Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 216.03 seconds Raw packets sent: 2000 (88.000KB) | Rcvd: 2 (484B) Anyway, the hops after the second one are usually different when I run "traceroute" several times. For instance, if I run "traceroute -n -i enp9s6 www.shorewall.net" several times I get different IP addresses from hop #3 onwards until I reach 63.135.54.24. Same thing for www.fltk.org or www.gentoo.org. Somehow, whenever I run "traceroute -n -i enp9s6 8.8.8.8" I always get the same IP addresses at least for hops #3 and #4 (out of a total of 10). In any case, none of these hosts with these IP addresses reply to ping requests ("ping -n -I enp9s6 HOP_IP_ADDR"). In other words, when trying to access Google's primary DNS server at 8.8.8.8, the only pingable IP addresses in the path are 8.8.8.8 itself and the modem/router's LAN IP addr. at 192.168.101.1. I guess I need to ask my ISP to allow ICMP traffic for these intermediate routers. Looking back at the traceroute results for shorewall.net, I notice that hop #6 is the first pingable IP address even though it's not always the same. I can also confirm by geoIP db lookup that it belongs to my ISP. So I wrote it down and waited until I detected another packet loss event. When it happened, I pinged that host to find out that it behaved just like in my previous trace to 8.8.8.8 (ie. echo requests leave the shorewall gateway but there are missing replies). Also, this is what happens when I run a traceroute to shorewall: # traceroute -n -i enp9s6 www.shorewall.net (63.135.54.24), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 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 * * * Another try shortly after shows this: # traceroute -n -i enp9s6 www.shorewall.net (63.135.54.24), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * 4.35.175.6 198.850 ms 12 206.130.130.241 197.610 ms * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * # ping -n -I enp9s6 192.168.101.1 shows no packet loss (modem/router's LAN IP address) So, if I understood you properly, it seems that my network issue might be anywhere between my shorewall gateway and one of my ISP's closest routers (hop #6 in my traceroute example to www.shorewall.net above). Thanks, Vieri ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
