PF possibly causing weird SSL issues ?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

PF possibly causing weird SSL issues ?

Bob Smith
Hi,

I'm wracking my brains here.   I have just replaced <old commercial firewall> with one based on OpenBSD 6.3 PF. Nothing else has changed on the network, just the firewall.

Lots of "stuff" that used to work (e.g. various nightly pushes of data to "the cloud") have suddenly stopped working after the new firewall was put in place.

It seems to be down to some sort of weird handling of SSL by PF ?  I can't see why it should be OpenBSD, and yet I also can't see why it cannot be OpenBSD, given nothing else has changed.

The reason I say this is because of what I see if I take troubleshooting down to its most basic level :

This:
wget -O bp_linux.tar.gz https://github.com/Azure/blobporter/releases/download/v0.6.15/bp_linux.tar.gz
Fails with:
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.

And yet this (ironically !) :
wget https://cdn.openbsd.org/pub/OpenBSD/6.3/amd64/install63.iso
Works fine.

Similarly, this :
openssl s_client -connect github-production-release-asset-2e65be.s3.amazonaws.com:443 -servername github-production-release-asset-2e65be.s3.amazonaws.
com
Returns:
no peer certificate available
No client certificate CA names sent

And yet this :
openssl s_client -connect google.com:443 -servername google.com
Shows SSL certs OK  !

My PF is simple as follows (there is no NAT here, its fully routable) :
match in all scrub (no-df random-id)
block drop
set block-policy drop
set syncookies always
pass from <my_admin_net> to any flags S/SA modulate state (pflow)

DNS and everything else is working fine.

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Christer Solskogen-3
On Tue, Sep 18, 2018, 23:04 Tim Jones <
[hidden email]> wrote:

> Hi,
>
> I'm wracking my brains here.   I have just replaced <old commercial
> firewall> with one based on OpenBSD 6.3 PF. Nothing else has changed on the
> network, just the firewall
>

Check the time and date.
And enable ntpd if you already haven't.
Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Bob Smith
> Check the time and date.
> And enable ntpd if you already haven't.

Time and data are fine.

NTP already runs extensively on this network, so setting it up on OpenBSD instances was a subconcious nobrainer. ;-)

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Richard Toohey
In reply to this post by Bob Smith
On 09/19/18 09:02, Tim Jones wrote:

> Hi,
>
> I'm wracking my brains here.   I have just replaced <old commercial firewall> with one based on OpenBSD 6.3 PF. Nothing else has changed on the network, just the firewall.
>
> Lots of "stuff" that used to work (e.g. various nightly pushes of data to "the cloud") have suddenly stopped working after the new firewall was put in place.
>
> It seems to be down to some sort of weird handling of SSL by PF ?  I can't see why it should be OpenBSD, and yet I also can't see why it cannot be OpenBSD, given nothing else has changed.
>
> The reason I say this is because of what I see if I take troubleshooting down to its most basic level :
>
> This:
> wget -O bp_linux.tar.gz https://github.com/Azure/blobporter/releases/download/v0.6.15/bp_linux.tar.gz
> Fails with:
> OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> Unable to establish SSL connection.
>
> And yet this (ironically !) :
> wget https://cdn.openbsd.org/pub/OpenBSD/6.3/amd64/install63.iso
> Works fine.
>
> Similarly, this :
> openssl s_client -connect github-production-release-asset-2e65be.s3.amazonaws.com:443 -servername github-production-release-asset-2e65be.s3.amazonaws.
> com
> Returns:
> no peer certificate available
> No client certificate CA names sent
>
> And yet this :
> openssl s_client -connect google.com:443 -servername google.com
> Shows SSL certs OK  !
>
> My PF is simple as follows (there is no NAT here, its fully routable) :
> match in all scrub (no-df random-id)
> block drop
> set block-policy drop
> set syncookies always
> pass from <my_admin_net> to any flags S/SA modulate state (pflow)
>
> DNS and everything else is working fine.
>
(Not an expert, just suggesting some things that might provoke
inspiration.  Hopefully.  But probably stuff already tried/eliminated.)

Are you sure it's pf?  If you disable pf (if that's an option here) -
any difference?

If you take the rules out and then introduce them one-by-one - is there
one that seems to break things?

What do the pf logs show?

Are you trying the commands on the firewall or an (OpenBSD?) machine
behind the firewall?

[OpenBSD machine]---[OpenBSD firewall]---[the internet]

(Anything to do with LibreSSL versus OpenSSL?)

If you try those commands on another OpenBSD machine at a different
location, do they work?

They work here (on a snapshot), so that does suggest they should work in
general so yes, maybe the ruleset or pf.

I've not got wget installed, but can achieve the same request with ftp e.g.

$ ftp
https://github.com/Azure/blobporter/releases/download/v0.6.15/bp_linux.tar.gz
Trying 192.30.255.112...
Requesting
https://github.com/Azure/blobporter/releases/download/v0.6.15/bp_linux.tar.gz
Redirected to
https://github-production-release-asset-2e65be.s3.amazonaws.com/74929278/e5e4422c-58f2-11e8-9582-3447e8bc9081?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20180919%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20180919T043531Z&X-Amz-Expires=300&X-Amz-Signature=d99e4c16a020810445620a2dc532f53e192ea382bff9785059d2f886981defb7&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dbp_linux.tar.gz&response-content-type=application%2Foctet-stream
Trying 54.231.81.40...
Requesting
https://github-production-release-asset-2e65be.s3.amazonaws.com/74929278/e5e4422c-58f2-11e8-9582-3...

What do you get if you try ftp instead of wget?

$ openssl s_client -connect
github-production-release-asset-2e65be.s3.amazonaws.com:443 -servername
github-production-release-asset-2e65be.s3.amazonaws.com
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore
CyberTrust Root
...


Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Joseph Mayer
In reply to this post by Bob Smith
On Wednesday, September 19, 2018 8:26 AM, Tim Jones <[hidden email]> wrote:

> > Check the time and date.
> > And enable ntpd if you already haven't.
>
> Time and data are fine.
>
> NTP already runs extensively on this network, so setting it up on OpenBSD instances was a subconcious nobrainer. ;-)

Tim,

The malbehavior you are seeing, is it from programs running on your
OpenBSD instance or from programs running on computers located behind
your OpenBSD NAT/PF?

OpenBSD's NAT/PF should be agnostic to system time configuration. SSL
clients depend on system time for cert validation. The SSL error you
reported here does not look like being of that kind however.

Please share your dmesg, pf.conf and any other relevant conf? (Why did
you not already)

Joseph

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Marc Peters-3
In reply to this post by Bob Smith
On Tue, Sep 18, 2018 at 09:02:23PM +0000, Tim Jones wrote:

> My PF is simple as follows (there is no NAT here, its fully routable) :
> match in all scrub (no-df random-id)
> block drop
> set block-policy drop
> set syncookies always
> pass from <my_admin_net> to any flags S/SA modulate state (pflow)
>

Can you try your setup with a default pf.conf (you can find it in /etc/examples). If this works, then try adding the rules you've got one by one to see, if and which one is causing your troubles.

hth,
Marc

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Stuart Henderson
In reply to this post by Bob Smith
On 2018-09-18, Tim Jones <[hidden email]> wrote:

> Hi,
>
> I'm wracking my brains here.   I have just replaced <old commercial firewall> with one based on OpenBSD 6.3 PF. Nothing else has changed on the network, just the firewall.
>
> Lots of "stuff" that used to work (e.g. various nightly pushes of data to "the cloud") have suddenly stopped working after the new firewall was put in place.
>
> It seems to be down to some sort of weird handling of SSL by PF ?  I can't see why it should be OpenBSD, and yet I also can't see why it cannot be OpenBSD, given nothing else has changed.
>
> The reason I say this is because of what I see if I take troubleshooting down to its most basic level :
>
> This:
> wget -O bp_linux.tar.gz https://github.com/Azure/blobporter/releases/download/v0.6.15/bp_linux.tar.gz
> Fails with:
> OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
> Unable to establish SSL connection.
>
> And yet this (ironically !) :
> wget https://cdn.openbsd.org/pub/OpenBSD/6.3/amd64/install63.iso
> Works fine.
>
> Similarly, this :
> openssl s_client -connect github-production-release-asset-2e65be.s3.amazonaws.com:443 -servername github-production-release-asset-2e65be.s3.amazonaws.
> com
> Returns:
> no peer certificate available
> No client certificate CA names sent
>
> And yet this :
> openssl s_client -connect google.com:443 -servername google.com
> Shows SSL certs OK  !
>
> My PF is simple as follows (there is no NAT here, its fully routable) :
> match in all scrub (no-df random-id)
> block drop
> set block-policy drop
> set syncookies always
> pass from <my_admin_net> to any flags S/SA modulate state (pflow)
>
> DNS and everything else is working fine.
>
>

This feels like it might be an MTU related problem, especially likely
if the connection is going via pppoe or a tunnel - you may need "scrub
(max-mss ##)".

The way Google's TLS server handshake is setup, it fits in pppoe without
fragmentation, most other sites do not this.

Otherwise try simplifying pf.conf (one change at a time and test):
disable syncookies and change "modulate state" to "keep state", maybe
also the random-id scrub. ("syncookies always" in PF doesn't make a
lot of sense to me except for testing, especially if only allowing
inside->outside traffic, I think "adaptive" would be more usual if
using this feature).


Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Bob Smith

> This feels like it might be an MTU related problem, especially likely
> if the connection is going via pppoe or a tunnel - you may need "scrub
> (max-mss ##)".
>
> The way Google's TLS server handshake is setup, it fits in pppoe without
> fragmentation, most other sites do not this.
>
> Otherwise try simplifying pf.conf (one change at a time and test):
> disable syncookies and change "modulate state" to "keep state", maybe
> also the random-id scrub. ("syncookies always" in PF doesn't make a
> lot of sense to me except for testing, especially if only allowing
> inside->outside traffic, I think "adaptive" would be more usual if
> using this feature).



Thanks Stuart. These sound possibly more likely than some of the other suggestions (e.g. wrong date/time or bad pf rules ... I'm not that silly).

The connection is not going via PPPoE or tunnel.  The immediate next hop is an OpenBSD based BGP router  (where, incidentally I can't replicate this SSL issue, but the router is not (yet) running 6.3 either).  The OpenBSD router box is then plugged into large carrier routers.  So it all this is not hanging off the end of some random DSL line !

The reason I've got "syncookies always" is because there are various internet exposed services (e.g. webservers) sitting behind this PF instance, and as far as I can gather syncookies is recommended as a good thing (tm) for these sort of applications ?  This PF instance is very much a majority out->in instance.

But at the same time I'm also unclear as to what the impact of syncookies is on states ?  The man page talks of "continue the connection with synproxy in place", which in my mind implies "synproxy state" ?

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Claudio Jeker
On Wed, Sep 19, 2018 at 10:00:28AM +0000, Tim Jones wrote:

>
> > This feels like it might be an MTU related problem, especially likely
> > if the connection is going via pppoe or a tunnel - you may need "scrub
> > (max-mss ##)".
> >
> > The way Google's TLS server handshake is setup, it fits in pppoe without
> > fragmentation, most other sites do not this.
> >
> > Otherwise try simplifying pf.conf (one change at a time and test):
> > disable syncookies and change "modulate state" to "keep state", maybe
> > also the random-id scrub. ("syncookies always" in PF doesn't make a
> > lot of sense to me except for testing, especially if only allowing
> > inside->outside traffic, I think "adaptive" would be more usual if
> > using this feature).
>
>
>
> Thanks Stuart. These sound possibly more likely than some of the other
> suggestions (e.g. wrong date/time or bad pf rules ... I'm not that
> silly).
>
> The connection is not going via PPPoE or tunnel.  The immediate next hop
> is an OpenBSD based BGP router  (where, incidentally I can't replicate
> this SSL issue, but the router is not (yet) running 6.3 either).  The
> OpenBSD router box is then plugged into large carrier routers.  So it
> all this is not hanging off the end of some random DSL line !
>
> The reason I've got "syncookies always" is because there are various
> internet exposed services (e.g. webservers) sitting behind this PF
> instance, and as far as I can gather syncookies is recommended as a good
> thing (tm) for these sort of applications ?  This PF instance is very
> much a majority out->in instance.

This is a very bad advise you got. Syncookies should only be used in
exterme situations because the they do lose some of the additional
information that is part of the SYN packet. "syncookies always" is only
there for testing but should not be used in production.

Syncookies are a way to preserve resources on the firewalls and servers
when they are attacked by simple SYN floods. This works because the
syncookie allows to respond to SYN packets without creating any kind of
internal state (which is normally required to finish the 3-way handshake).
All the data that would normally be stored in the state has to be
compressed into a few bits of the syncookie and so especially data like the
MSS is not stored at full precision.

> But at the same time I'm also unclear as to what the impact of
> syncookies is on states ?  The man page talks of "continue the
> connection with synproxy in place", which in my mind implies "synproxy
> state" ?

Syncookies are similar to synproxy but unlike synproxy they don't create
state on the initial SYN (only on the ACK sent back as repsonse to the
syncookie). It does similar to synproxy only open the backend connection
once the 3-way handshake is finished.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Stuart Henderson
In reply to this post by Bob Smith
On 2018/09/19 10:00, Tim Jones wrote:

>
> > This feels like it might be an MTU related problem, especially likely
> > if the connection is going via pppoe or a tunnel - you may need "scrub
> > (max-mss ##)".
> >
> > The way Google's TLS server handshake is setup, it fits in pppoe without
> > fragmentation, most other sites do not this.
> >
> > Otherwise try simplifying pf.conf (one change at a time and test):
> > disable syncookies and change "modulate state" to "keep state", maybe
> > also the random-id scrub. ("syncookies always" in PF doesn't make a
> > lot of sense to me except for testing, especially if only allowing
> > inside->outside traffic, I think "adaptive" would be more usual if
> > using this feature).
>
>
>
> Thanks Stuart. These sound possibly more likely than some of the other suggestions (e.g. wrong date/time or bad pf rules ... I'm not that silly).
>
> The connection is not going via PPPoE or tunnel.  The immediate next hop is an OpenBSD based BGP router  (where, incidentally I can't replicate this SSL issue, but the router is not (yet) running 6.3 either).  The OpenBSD router box is then plugged into large carrier routers.  So it all this is not hanging off the end of some random DSL line !

Is there one OpenBSD BGP router or more, and is PF running there too?
(Basically check with tcpdump on various interfaces along the way that
the packets you expect to receive from the TLS server/s you're
connecting to aren't being dropped somewhere - if there are paths
to/from "the internet" going via multiple stateful firewalls you
can have problems with asymmetric traffic if you're not careful).

> The reason I've got "syncookies always" is because there are various internet exposed services (e.g. webservers) sitting behind this PF instance, and as far as I can gather syncookies is recommended as a good thing (tm) for these sort of applications ?  This PF instance is very much a majority out->in instance.
>
> But at the same time I'm also unclear as to what the impact of syncookies is on states ?  The man page talks of "continue the connection with synproxy in place", which in my mind implies "synproxy state" ?
>

Synproxy is meant to protect the backend server under syn flood, I'm not
an expert on this but AIUI there are often on-host mechanisms like syn
cache so this isn't needed as much these days except for hosts with
particularly vulnerable TCP stacks (though I'd probably use a TCP relay
for those instead as it gives more isolation).

PF's syncookies are instead to protect the PF state table on the firewall.
No state table entry is created until the client has correctly answered
SYN+ACK avoiding PF states from most blind spoofed SYNs. Using them also
requires synproxy (PF already answered the SYN so the source will see
this as "connection open" at that point, the end destination won't see
anything until the client sends a valid SYN+ACK and the firewall commits
resources to it, it's not until that point when the server first sees a
[proxied] syn to bring up the connection).

For monitoring/debugging under normal conditions I don't like the
"accept connection before the server has seen anything" behaviour so
adaptive generally makes sense to me though it's wise to test the
"adverse conditions" behaviour first (and for that, "always" allows
doing so without actually flooding the firewall with SYNs).

Anyway in your current situation I would be cutting down things which
make not-entirely-necessary changes to packets one by one until the
cause of the problem shows itself..

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Stuart Henderson
In reply to this post by Bob Smith
On 2018/09/19 10:00, Tim Jones wrote:
> The reason I've got "syncookies always" is because there are various
> internet exposed services (e.g. webservers) sitting behind this PF
> instance, and as far as I can gather syncookies is recommended as a good
> thing (tm) for these sort of applications ? This PF instance is very
> much a majority out->in instance.

Oh, also: syncookies have been used for years as an "on host" mechanism
for syn protection on some OS (as part of the TCP stack, not part of the
firewall/filter) - advice you get about using them in that situation
isn't directly applicable to using them on an intermediate firewall.

Maybe we need "(intended for testing only)" next to "syncookies always"
in PF docs ..

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Bob Smith
In reply to this post by Claudio Jeker

> This is a very bad advise you got. Syncookies should only be used in
> exterme situations because the they do lose some of the additional
> information that is part of the SYN packet. "syncookies always" is only
> there for testing but should not be used in production.
>

Thank you Claudio.  Message received. "syncookies always" has now been removed from my pf.conf (has not fixed the current problem, but at least you've made me confident I've avoided a potential future problem !).

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Bob Smith
In reply to this post by Stuart Henderson


>
> Is there one OpenBSD BGP router or more, and is PF running there too?
> (Basically check with tcpdump on various interfaces along the way that
> the packets you expect to receive from the TLS server/s you're
> connecting to aren't being dropped somewhere - if there are paths
> to/from "the internet" going via multiple stateful firewalls you
> can have problems with asymmetric traffic if you're not careful).

Currently only one (this is an edge node for something, there are plans to add a second router soon, but has not happened yet).

PF is running on the OpenBSD router, but a very small and basic ruleset just to keep undesirables away from the localhost SSH and BGPD, the rest of the traffic is sent straight through (i.e. PF is running default "pass no state" instead of default drop).

Not that asymmetric traffic is the problem here, but if it were, surely I would be seeing broader problems, not just this relatively small and confined one ?

I will try some more experiments with tcpdump later.

Reply | Threaded
Open this post in threaded view
|

Re: PF possibly causing weird SSL issues ?

Bob Smith
In reply to this post by Stuart Henderson
I've just done a tcpdump. About to look at it myself, but maybe eyes on list will spot the issue (if any) quicker than my tired eyes.

198.51.100.167 is me (RFC5737 obfuscated)
52.216.65.232 is amazon (I used the IP to rule out any possible DNS issues even though I've triple checked the DNS is working perfectly)

# From a server behind the firewall
> openssl s_client -connect 52.216.65.232:443 -servername github-production-release-asset-2e65be.s3.amazonaws.com
CONNECTED(00000003)
140007268579136:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:252:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 240 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1537377960
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
# INTERNAL INTERFACE
$ doas tcpdump -i vlan178  'host 198.51.100.167 and 52.216.65.232'
tcpdump: listening on vlan178, link-type EN10MB
18:25:57.268855 myserver.example.com.32792 > s3-1-w.amazonaws.com.4433: . ack 630647770 win 29200 (DF)
18:26:00.298134 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: S 4238555681:4238555681(0) win 29200 <mss 1460,sackOK,timestamp 1612824367 0,nop,wscale 7> (DF)
18:26:00.298147 s3-1-w.amazonaws.com.https > myserver.example.com.54112: S 3428578097:3428578097(0) ack 4238555682 win 0 <mss 1460> (DF) [tos 0x10]
18:26:00.298384 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: . ack 1 win 29200 (DF)
18:26:00.373869 s3-1-w.amazonaws.com.https > myserver.example.com.54112: . ack 1 win 1 (DF) [tos 0x10]
18:26:00.580732 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:00.788730 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:01.204744 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:02.036771 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:03.700700 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:06.996828 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:11.410370 s3-1-w.amazonaws.com.4433 > myserver.example.com.32792: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]
18:26:13.652796 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: P 1:2(1) ack 1 win 29200 (DF)
18:26:20.474809 s3-1-w.amazonaws.com.https > myserver.example.com.54112: P 1:8(7) ack 1 win 14600
18:26:20.475044 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: . ack 8 win 29200 (DF)
18:26:20.475294 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: FP 2:241(239) ack 8 win 29200 (DF)
18:26:20.475296 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: R 242:242(0) ack 8 win 29200 (DF)
18:26:20.550879 s3-1-w.amazonaws.com.https > myserver.example.com.54112: . ack 1 win 14600
18:26:20.550892 s3-1-w.amazonaws.com.https > myserver.example.com.54112: . ack 1 win 14600
18:26:20.551002 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: R 4238555682:4238555682(0) win 0 (DF)
18:26:20.551126 myserver.example.com.54112 > s3-1-w.amazonaws.com.https: R 4238555682:4238555682(0) win 0 (DF)
# EXTERNAL INTERFACE
$ doas tcpdump -i em1 'host 198.51.100.167 and 52.216.65.232'
tcpdump: listening on em1, link-type EN10MB
18:26:00.298424 198.51.100.167.54112 > 52.216.65.232.https: S 3428578097:3428578097(0) win 0 (DF) [tos 0x10]
18:26:00.373822 52.216.65.232.https > 198.51.100.167.54112: S 4188089135:4188089135(0) ack 3428578098 win 0 <mss 1432>
18:26:00.373863 198.51.100.167.54112 > 52.216.65.232.https: . ack 1 win 29200 (DF) [tos 0x10]
18:26:20.474775 52.216.65.232.https > 198.51.100.167.54112: P 1:8(7) ack 1 win 14600 (DF)
18:26:20.475060 198.51.100.167.54112 > 52.216.65.232.https: . ack 8 win 29200
18:26:20.475311 198.51.100.167.54112 > 52.216.65.232.https: FP 2:241(239) ack 8 win 29200
18:26:20.475323 198.51.100.167.54112 > 52.216.65.232.https: R 242:242(0) ack 8 win 29200
18:26:20.550857 52.216.65.232.https > 198.51.100.167.54112: . ack 1 win 14600 (DF)
18:26:20.550858 52.216.65.232.https > 198.51.100.167.54112: . ack 1 win 14600 (DF)
18:26:20.551018 198.51.100.167.54112 > 52.216.65.232.https: R 3428578098:3428578098(0) win 0
18:26:20.551140 198.51.100.167.54112 > 52.216.65.232.https: R 3428578098:3428578098(0) win 0