Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Dec 2020 17:28:43 -0800
From:      Michael Sierchio <kudzu@tenebras.com>
To:        freebsd@dreamchaser.org
Cc:        FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: strange tcp behavior; all systems except 1 connect to google compute engine
Message-ID:  <CAHu1Y70N8huvGw73FHo-kwd7nZ1H2j+RMj-6=ePayCQP_5b9bg@mail.gmail.com>
In-Reply-To: <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org>
References:  <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Are you blocking ICMP? I.e., preventing path MTU discovery in TCP?

On Sat, Dec 5, 2020 at 12:43 PM Gary Aitken <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 o=
ne
> running ubuntu 18.04.  I used to be able to connect to the 16.04 system o=
k.
> 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 genera=
l
> 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 ha=
ve
> 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 ------/
>
> =3D=3D=3D=3D=3D=3D request from A to D: =3D=3D=3D=3D=3D=3D
> This request fails, appearing to never be answered by D
>
> On C, tcpdump for packets containing D:
>
> # tcpdump -flnt -i xl0 | grep 35.230.53.86
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decod=
e
> listening on xl0, link-type EN10MB (Ethernet), capture size 262144 bytes
> IP 216.239.38.108.53 > 66.109.141.57.60651: 9207*- 2/0/1 CNAME
> xbiologix.net., A 35.230.53.86 (76)
> IP 66.109.141.62.35750 > 35.230.53.86.443: Flags [S], seq 971626487, win
> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1232709
> 117 ecr 0], length 0
> IP 66.109.141.62.10842 > 35.230.53.86.443: Flags [S], seq 214222135, win
> 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 7281528
> 60 ecr 0], length 0
>
> On D, tcpdump for packets containing A,B,C network prefix
>
> $ sudo tcpdump -flnt -i ens4 | grep 66.109.141.62
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decod=
e
> listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
> IP 66.109.141.62.13157 > 10.138.0.3.443: Flags [S], seq 2711450222, win
> 65535, options [mss 1400,nop,wscale 6,sackOK,TS val 42776192
> 42 ecr 0], length 0
> IP 66.109.141.62.53250 > 10.138.0.3.443: Flags [S], seq 2613495290, win
> 65535, options [mss 1400,nop,wscale 6,sackOK,TS val 38547428
> 01 ecr 0], length 0
>
> =3D=3D=3D=3D=3D=3D request from B to D: =3D=3D=3D=3D=3D=3D
> This works.
> Note that reporting address for D is an internal google network addr.
>
> On C, tcpdump for packets containing D:
>
> # tcpdump -flnt -i xl0 | grep 35.230.53.86
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decod=
e
> listening on xl0, link-type EN10MB (Ethernet), capture size 262144 bytes
> IP 216.239.38.108.53 > 66.109.141.57.60842: 59730*- 1/0/1 A 35.230.53.86
> (58)
> IP 66.109.141.60.55462 > 35.230.53.86.443: Flags [S], seq 3127908816, win
> 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], len
> gth 0
> IP 35.230.53.86.443 > 66.109.141.60.55462: Flags [S.], seq 2165521777, ac=
k
> 3127908817, win 65320, options [mss 1400,nop,nop,sackOK,n
> op,wscale 7], length 0
>
> On D, tcpdump for packets containing A,B,C network prefix:
> $ sudo tcpdump -flnt -i ens4 | grep 66.109.141
> IP 66.109.141.60.55110 > 10.138.0.3.80: Flags [S], seq 438717762, win
> 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length
> 0
> IP 10.138.0.3.80 > 66.109.141.60.55110: Flags [S.], seq 77401776, ack
> 438717763, win 65320, options [mss 1420,nop,nop,sackOK,nop,wsc
> ale 7], length 0
> IP 66.109.141.60.55110 > 10.138.0.3.80: Flags [.], ack 1, win 257, length=
 0
> IP 66.109.141.60.55111 > 10.138.0.3.443: Flags [S], seq 3129142493, win
> 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], lengt
> h 0
> IP 10.138.0.3.443 > 66.109.141.60.55111: Flags [S.], seq 833868082, ack
> 3129142494, win 65320, options [mss 1420,nop,nop,sackOK,nop,
> wscale 7], length 0
>
> Thanks for any clues,
>
> Gary
>
>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe@freebsd.org"
>


--=20

"Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is =
no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mah=C4=81bh=C4=81rata



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?CAHu1Y70N8huvGw73FHo-kwd7nZ1H2j+RMj-6=ePayCQP_5b9bg>