This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL traffic fails to respond from WAN interface

Hi all

I have just provisioned a new WAN interface (LTE router) as a failover WAN at a site with latest UTM.

Any traffic from this WAN that hits an SSL endpoint on UTM or LAN (incl. WebAdmin, SSL VPN, SSH & other HTTPS servers) simply times out.

Any traffic hitting a HTTP service works just fine. Settings all the same. 

If I replace the LTE WAN with the fiber WAN, it works perfectly fine.

Netcat shows successful TCP handshake and connection, but no data is returned.

EDIT: just setup a netcat listen (nc -vvv -lkt 6666) on an internal LAN server, NATed the ports, tested 2-way "telnet" communications - works perfectly)

Nothing helpful shown in firewall logs.

Tried using valid HTTPS certificates - Still no reponse

Has me completely stumped.

Have the same LTE device and service at another site with an XG box and it works perfectly fine. (LTE router settings are exactly the same at both sites) 

Anyone have a ideas?

Thank you



This thread was automatically locked due to age.
Parents
  • 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! 

Reply
  • 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! 

Children
  • 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.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.