John,
Wow, good one dude! Turning off tcp timestamps on the client instantly
fixed it. So I guess I bring this to Checkpoint Support and see what they
say, THAT should be fun.
Thanks!
On Tue, May 14, 2019 at 3:02 AM John Fawcett wrote:
> On 14/05/2019 01:27, Wietse Venema wrote:
> > Wietse Ven
On 14/05/2019 01:27, Wietse Venema wrote:
> Wietse Venema:
>> If you look at the non-VPN captures, then you will see the following:
>>
>> - In one trace, we see a client ACK 138, followed by a client packet
>> with "." (data 443:446, ACK 138, and a timestamp field
>> tht is unlike those of al o
On 14/05/2019 01:27, Wietse Venema wrote:
> Wietse Venema:
>> If you look at the non-VPN captures, then you will see the following:
>>
>> - In one trace, we see a client ACK 138, followed by a client packet
>> with "." (data 443:446, ACK 138, and a timestamp field
>> tht is unlike those of al o
Wietse Venema:
> If you look at the non-VPN captures, then you will see the following:
>
> - In one trace, we see a client ACK 138, followed by a client packet
> with "." (data 443:446, ACK 138, and a timestamp field
> tht is unlike those of al other packets in the stream).
>
> - In the other
Wietse Venema:
> fhare:
> > Hello list,
> >
> > Bit of a weird one here. I have hosts at AWS sending mail across a
> > Checkpoint VPN to my main private relay server (it basically serves to relay
> > mail to O365 for in house applications). The problem is that the sending
> > client never receive
fhare:
> Hello list,
>
> Bit of a weird one here. I have hosts at AWS sending mail across a
> Checkpoint VPN to my main private relay server (it basically serves to relay
> mail to O365 for in house applications). The problem is that the sending
> client never receives BYE from server after QUIT.
