Date: Tue, 23 Apr 2019 22:01:43 -0400 From: John Johnstone <jjohnstone.nospamfreebsd@tridentusa.com> To: freebsd-questions@freebsd.org Subject: Re: openvpn Message-ID: <bc7c0afb-1950-26db-5e9f-78e8c6d7c2ec@tridentusa.com> In-Reply-To: <9DABDBEC-B532-46F6-B09E-A65ED4EF5A1A@mail.sermon-archive.info> References: <0A8436BD-EFB8-4A54-B920-329096B89C5B@mail.sermon-archive.info> <b7487e60-7ffd-1bd8-4078-9eef315ce87b@tridentusa.com> <9DABDBEC-B532-46F6-B09E-A65ED4EF5A1A@mail.sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/23/2019 8:36 PM, Doug Hardie wrote: >> Might be difficult to arrange but testing from some hardware besides a phone would help; being able to run tcpdump on the external device side. This would allow verifying the 3-way TCP handshake at the client side. > > As I indicated, tcpdump has been use on all connections. The connections are established and data is sent. The client just ignores it. Or, that's what it appears. If the client seems to be ignoring what is coming from the web server that means that either the web server isn't sending what it should be or the client isn't behaving as it should or as you're suggesting, packets aren't transiting through OpenVPN as they should. It's a lot of work but comparing what's seen at the server with what's seen at the client should reveal something. Wireshark with Analyze > Follow > TCP Stream can make things stand out a bit more than tcpdump. It may take a packet by packet comparison to determine where things are going wrong. Maybe trying other connections / protocols such as ssh / telnet through a VPN connection might reveal some kind of pattern to the problem. - John J.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc7c0afb-1950-26db-5e9f-78e8c6d7c2ec>