From owner-freebsd-questions@freebsd.org Sat Dec 5 20:43:41 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 C7D584A7939 for ; Sat, 5 Dec 2020 20:43:41 +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 4CpM3w6MrWz4g3S for ; Sat, 5 Dec 2020 20:43:40 +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 0B5KhWwI093258 for ; Sat, 5 Dec 2020 13:43:32 -0700 (MST) (envelope-from freebsd@dreamchaser.org) To: FreeBSD Mailing List Reply-To: freebsd@dreamchaser.org From: Gary Aitken Subject: strange tcp behavior; all systems except 1 connect to google compute engine Message-ID: <10f8d534-8e2a-169a-388f-5df8a2304fd2@dreamchaser.org> Date: Sat, 5 Dec 2020 13:39:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (nightmare.dreamchaser.org [192.168.151.101]); Sat, 05 Dec 2020 13:43:32 -0700 (MST) X-Rspamd-Queue-Id: 4CpM3w6MrWz4g3S 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.22 / 15.00]; HAS_REPLYTO(0.00)[freebsd@dreamchaser.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.109.141.57:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.109.141.57:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.917]; DMARC_NA(0.00)[dreamchaser.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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: Sat, 05 Dec 2020 20:43:41 -0000 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