Date: Sat, 5 Dec 2020 13:39:31 -0700 From: Gary Aitken <freebsd@dreamchaser.org> To: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: strange tcp behavior; all systems except 1 connect to google compute engine Message-ID: <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org>
next in thread | raw e-mail | index | archive | help
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 ------/
====== request from A to D: ======
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 decode
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 decode
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
====== request from B to D: ======
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 decode
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, ack 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10f8d534-8e2a-169a-388f-5df8a2304fd2>