From owner-freebsd-questions@freebsd.org Wed Dec 9 18:57:35 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C40584AC8CF for ; Wed, 9 Dec 2020 18:57:35 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Received: from nightmare.dreamchaser.org (ns.dreamchaser.org [66.109.141.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "dreamchaser.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CrmWf5rNnz3kwT for ; Wed, 9 Dec 2020 18:57:34 +0000 (UTC) (envelope-from freebsd@dreamchaser.org) Received: from breakaway.dreamchaser.org (breakaway [192.168.151.122]) by nightmare.dreamchaser.org (8.15.2/8.15.2) with ESMTP id 0B9IvOF6015420; Wed, 9 Dec 2020 11:57:24 -0700 (MST) (envelope-from freebsd@dreamchaser.org) Reply-To: freebsd@dreamchaser.org Subject: Re: strange tcp behavior; all systems except 1 connect to google compute engine To: Michael Sierchio Cc: FreeBSD Mailing List , tech-lists@zyxst.net References: <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org> From: Gary Aitken Message-ID: Date: Wed, 9 Dec 2020 11:53:26 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (nightmare.dreamchaser.org [192.168.151.101]); Wed, 09 Dec 2020 11:57:25 -0700 (MST) X-Rspamd-Queue-Id: 4CrmWf5rNnz3kwT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@dreamchaser.org designates 66.109.141.57 as permitted sender) smtp.mailfrom=freebsd@dreamchaser.org X-Spamd-Result: default: False [-3.30 / 15.00]; HAS_REPLYTO(0.00)[freebsd@dreamchaser.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[dreamchaser.org]; SPAMHAUS_ZRD(0.00)[66.109.141.57:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.109.141.57:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:21947, ipnet:66.109.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 18:57:35 -0000 On 12/8/20 6:28 PM, Michael Sierchio wrote: > > Are you blocking ICMP? I.e., preventing path MTU discovery in TCP? Thanks for the reply ( hmmm, perhaps. I'm allowing anything out, but only 3 and 11 in. Doing a little re-education ... looks like that would be type 3 anyway, which was already allowed. Also, other machines (B) on the same network as the requesting one that fails (A) succeed. A fbsd --------\ C fbsd firewalll/gateway -- Google cloud -- D ubuntu B ms-win-10 ---/ The machine where the request arrives (D) has all icmp allowed as far as I can tell from the GCE admin page: default-allow-icmp ingress iprange 0.0.0.0 In any case, allowing all icmp types at the requesting end (C) seems to have no affect. The destination machine D still gets the request but does not answer. It seems unlikely the issue is just MTU, as the failure occurs with the first request packet not being answered during initial protocol negotiation, and those packets are small. I don't know what the unanswering machine is using for a packet filter, unfortunately. While I see the incoming HTTP request packet, there is no record of it in either of the two apache2 logs, access.log and error.log. I think I probably need to redirect this to a ubuntu list. On 12/8/20 5:40 PM, tech-lists wrote: > I'm not an expert, but I'd just like to say that I get the exact same issues > if I fail to account for jumbo frames and overhead at the handover point of my > connection, which is fibre. Can you tell if the web-server is not answering the initial request, or just that the page never displays on the other end? > All my interfaces are jumbo-capable. I have a dmz (nothing on it right now > apart from my NATting router) and an edgerouter lite 3 device running > OpenBSD 6.8 and pppoe. On the pppoe config I have MTU 1500. On the ethernet > I have MTU 1520. If I were to set the ethernet interface equal or less > than the pppoe interface, then I can't access some sites and these > include all the common search engines. No mss clamping is set in pf.conf. Interesting, thanks. Unfortunately I don't think that's the issue since the packets never leave the web-server machine. I haven't looked at the DSL modem but I'm pretty sure it's not the problem, given the response never leaves the web server machine. Gary > On Sat, Dec 5, 2020 at 12:43 PM Gary Aitken > wrote: > > I'm trying to debug a situation where tcp conversation started from a > single fbsd machine in my home/work network are ignored by a google > compute engine running ubuntu. I get the same behavior from two > different systems, one a long established system running ubuntu 16.04 > and another newly minted one running ubuntu 18.04. I used to be able > to connect to the 16.04 system ok. If I request an SSH session on D > from machine A using the console interface for the account on GCE, > the console session shows up on machine A just fine. But if I > attempt to visit the home web page I get no response, and I get no > response if I attempt to set up an SSH session from an xterm on > machine A. > > There are no special firewall rules on machine D (either one); the > general rules set up when the VM was created allowing HTTP, HTTPS, > and SSH access are there with no further holes/blocks. > > The internal machines have private IP addrs, but a non-private IP > addr (66.109.141.62) is specifically mapped to A by ipfw rules in C. > B is mapped to a specific IP addr used for all other internal > machines (66.109.141.60), and C has a specific IP addr > (66.109.141.57). > > Since I see the request to open a connection at D, I *think* it > should have nothing to do with my internal firewall rules; but I > can't think of what could be preventing machine D from responding. > > So... what could be preventing machine D from answering a request by > machine A, when a similar request from B or C works? > > Topology: > > A fbsd 11.4 REL --\ C fbsd firewalll/gateway -- Google cloud -- D > ubuntu B ms-win-10 ------/ > > "Well," Brahmā said, "even after ten thousand explanations, a fool > is no wiser, but an intelligent person requires only two thousand > five hundred." > > - The Mahābhārata