SSL traffic fails to respond from WAN interface

What do your logs say?  Country Blocking affecting it?  I just had that issue myself, on vacation in Florida and I use Country Blocking.  I could connect but couldn't copy any files from my NAS over SSL VPN.  For some reason, the IP in Florida appears as an IP in India?  I had blocking 'From' India enabled.  Disabed it and VPN works fine now.  /shrug.

Are you seeing anything in firewall logs?  If it's failover, are you testing it with your main line still established, or only on the failover?

Just thorwing out some ideas on this one, failover connections aren't my thing with UTM. 

Hi and welcome to the UTM Community!

I can't see whether you're talking about inbound or outbound traffic.

Cheers - Bob

Maybe an MTU problem with the LTE link?

Hi All

Thanks for all the feedback.

@jprusch checked MTU values are correct. Remember non SSL traffic works fine.

@BAlfson: Inbound traffic from WAN on LTE interface

@Amodin: Country blocking disabled. I disabled IPS also in my testing. Nothing on firewall logs - only shows the incoming packet (the "ClientHello" packet of the TLS handshake - but no response sent back to client as below):

~ ❯❯❯ openssl s_client -connect A.B.C.D:4444 -debug -msg -showcerts
CONNECTED(00000005)
write to 0x7f8a234c5520 [0x7f8a23825e03] (196 bytes => 196 (0xC4))
0000 - 16 03 01 00 bf 01 00 00-bb 03 03 40 28 e7 ca 50   ...........@(..P
0010 - f0 81 c1 a0 c3 e4 e3 26-b9 95 32 cc 3c 51 1c 7d   .......&..2.<Q.}
0020 - 91 ac 0b 50 23 d7 0a e5-06 6f 18 00 00 5c c0 30   ...P#....o...\.0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 9f 00 6b 00 39   .,.(.$.......k.9
0040 - cc a9 cc a8 cc aa ff 85-00 c4 00 88 00 81 00 9d   ................
0050 - 00 3d 00 35 00 c0 00 84-c0 2f c0 2b c0 27 c0 23   .=.5...../.+.'.#
0060 - c0 13 c0 09 00 9e 00 67-00 33 00 be 00 45 00 9c   .......g.3...E..
0070 - 00 3c 00 2f 00 ba 00 41-c0 11 c0 07 00 05 00 04   .<./...A........
0080 - c0 12 c0 08 00 16 00 0a-00 ff 01 00 00 36 00 0b   .............6..
0090 - 00 02 01 00 00 0a 00 08-00 06 00 1d 00 17 00 18   ................
00a0 - 00 23 00 00 00 0d 00 1c-00 1a 06 01 06 03 ef ef   .#..............
00b0 - 05 01 05 03 04 01 04 03-ee ee ed ed 03 01 03 03   ................
00c0 - 02 01 02 03                                       ....
>>> TLS 1.2 Handshake [length 00bf], ClientHello
    01 00 00 bb 03 03 40 28 e7 ca 50 f0 81 c1 a0 c3
    e4 e3 26 b9 95 32 cc 3c 51 1c 7d 91 ac 0b 50 23
    d7 0a e5 06 6f 18 00 00 5c c0 30 c0 2c c0 28 c0
    24 c0 14 c0 0a 00 9f 00 6b 00 39 cc a9 cc a8 cc
    aa ff 85 00 c4 00 88 00 81 00 9d 00 3d 00 35 00
    c0 00 84 c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 00
    9e 00 67 00 33 00 be 00 45 00 9c 00 3c 00 2f 00
    ba 00 41 c0 11 c0 07 00 05 00 04 c0 12 c0 08 00
    16 00 0a 00 ff 01 00 00 36 00 0b 00 02 01 00 00
    0a 00 08 00 06 00 1d 00 17 00 18 00 23 00 00 00
    0d 00 1c 00 1a 06 01 06 03 ef ef 05 01 05 03 04
    01 04 03 ee ee ed ed 03 01 03 03 02 01 02 03

where A.B.C.D is the WAP IP of the LTE interface. No response received after above transmission and it times out.

If i issue the same command to the Fibre WAN IP, i get the response and handshake completes successfully and can login web admin from there.

If i were to connect using http instead (non ssl) to the same port (WebAdmin) then I get a response as expected below:

~ ❯❯❯ curl -v http://A.B.C.D:4444
*   Trying A.B.C.D...
* TCP_NODELAY set
* Connected to A.B.C.D (A.B.C.D) port 4444 (#0)
> GET / HTTP/1.1
> Host: A.B.C.D:4444
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 400 Bad Request
< Date: Sat, 17 Sep 2022 08:17:50 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=0; includeSubDomains;
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; connect-src 'self' wss:;
< X-Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; connect-src 'self' wss:;
< X-Webkit-CSP: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; connect-src 'self' wss:;
< Content-Length: 483
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
 Instead use the HTTPS scheme to access this URL, please.<br />
</p>
<p>Additionally, a 400 Bad Request
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
* Closing connection 0

Yesterday I switched the LTE router to another one, BUT STILL having this issue! 

Are you talking about the WAN link where you checked your MTU?

I was talking about MTU on the transfer net.

And yes, I know that http works fine. I had this effect with https only, believe me.