**More details**

Prior to the above change, both VPN peers were restarted numerous times. The pfSense versions were 2.4.4-RELEASE and eventually one was upgraded to 2.4.5-RELEASE. None of those mattered. The IPSEC VPN configuration was also deleted and re-done a few times, also with no effect.


This system is hosted in AWS. The two pfSense VPN peers are in two different VPCs, and the test server in the same VPC as the first peer. The target webserver is in a third VPC in a separate AWS account connected via an AWS TGW. The VPN Peers connect via the internet to each other.
Both pfSense servers are Netgate images.

Test scenario is as follows:
TestServer --> VPNTest --> VPNProduction --> TGW --> TargetWebServer
This didn't work until the tunnel address types were changed from Address {IP} to Network {IP}/32

The test scenario was simplified by byppassing the VPN to determine whether the VPN was the problem.
TestServer --> --> TGW --> TargetWebServer
This worked perfectly every time.



**Testing**
The basic test in the problem scenario is done using this:
curl --verbose --insecure https://targetIP:port/test

The client interacts with the target webserver, receiving the initial data and responding to the client, and the client in turn sends more data, till the server's "hello" response doesn't reach the client.


The webserver eventually times out with this error:
"client timed out (110: Connection timed out) while SSL handshaking"



**Test responses.**
curl --tls-max 1.2 --insecure --verbose https://TargetWebServerIP:8520/test

The client shows this:

*   Trying TargetWebServerIP...
* TCP_NODELAY set
* Connected to TargetWebServerIP (TargetWebServerIP) port 8520 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):


With the Phase 2 Tunnel types set to Address, the client stopped at the above point.

When the one or more Phase 2 Tunnel types changed to Network IP/32, the client would show the above and continue with this:
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:

.... etc.