Date: Wed, 9 Dec 2020 11:53:26 -0700 From: Gary Aitken <freebsd@dreamchaser.org> To: Michael Sierchio <kudzu@tenebras.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org>, tech-lists@zyxst.net Subject: Re: strange tcp behavior; all systems except 1 connect to google compute engine Message-ID: <e390a22b-7a9d-b487-97bf-2cb70c212770@dreamchaser.org> In-Reply-To: <CAHu1Y70N8huvGw73FHo-kwd7nZ1H2j%2BRMj-6=ePayCQP_5b9bg@mail.gmail.com> References: <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org> <CAHu1Y70N8huvGw73FHo-kwd7nZ1H2j%2BRMj-6=ePayCQP_5b9bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <freebsd@dreamchaser.org
> <mailto:freebsd@dreamchaser.org>> 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 ------/
<snip>
>
> "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e390a22b-7a9d-b487-97bf-2cb70c212770>