I encountered a condition on Linux with the latest ZET release 0.22.20 where ZET doesn't recover after escaping a captive portal.
The workaround is to restart ZET after escaping the captive portal (no MitM).
If a captive portal/MitM prevents T-SDK (not reproducible with C-SDK via ziti-prox-c) from verifying the client API's server certificate, and the captive portal login is performed to eliminate the MitM, then ZET doesn't recover and continues to report controller unavailable, no API session is obtained, no routers are connected, and no services work, despite the client API being available with no MitM.
The condition does not recur after a reboot if the captive portal authorization for the Ethernet address is remembered, and the condition can be reproduced by changing the Ethernet address, thereby restarting the captive portal login flow and reintroducing the MitM.
@ekoby pointed out this appears to be related to ZET's implementation of "exlusion routes," which are static routes installed by ZET that have a higher specificity than intercept routes and thereby prevent interception of packets destined for the Ziti controllers' client API listeners or routers' edge listeners.
(1118467)[ 1167.230] TRACE tlsuv:tls_link.c:86 TLS(0x5f912dffa680) starting handshake(st = 0)
(1118467)[ 1167.230] TRACE tlsuv:tls_link.c:100 TLS(0x5f912dffa680) starting handshake(sending 324 bytes, st = 3)
(1118467)[ 1167.274] TRACE tlsuv:tls_link.c:111 TLS(0x5f912dffa680)[1]: 5456
(1118467)[ 1167.274] TRACE tlsuv:tls_link.c:131 TLS(0x5f912dffa680) continuing handshake(5456 bytes received)
(1118467)[ 1167.274] TRACE tlsuv:tls_link.c:137 TLS(0x5f912dffa680) continuing handshake(sending 0 bytes, st = 3)
(1118467)[ 1167.274] ERROR tlsuv:tls_link.c:160 TLS(0x5f912dffa680) handshake error SSL - An invalid SSL record was received
(1118467)[ 1167.274] ERROR tlsuv:http.c:188 handshake failed status[3]: SSL - An invalid SSL record was received
(1118467)[ 1167.274] VERBOSE tlsuv:http.c:356 closing connection
(1118467)[ 1167.274] TRACE tlsuv:tls_link.c:266 closing TLS link
(1118467)[ 1172.274] VERBOSE tlsuv:http.c:389 client not connected, starting connect sequence
(1118467)[ 1172.274] DEBUG tlsuv:tcp_src.c:158 resolving 'ziti.bingnet.cloud:443'
(1118467)[ 1172.288] TRACE tlsuv:tcp_src.c:99 resolved status = 0
(1118467)[ 1172.312] VERBOSE tlsuv:http.c:249 src connected status = 0
(1118467)[ 1172.312] TRACE tlsuv:tls_link.c:86 TLS(0x5f912dffa680) starting handshake(st = 0)
(1118467)[ 1172.312] TRACE tlsuv:tls_link.c:100 TLS(0x5f912dffa680) starting handshake(sending 324 bytes, st = 3)
(1118467)[ 1172.359] TRACE tlsuv:tls_link.c:111 TLS(0x5f912dffa680)[1]: 5456
(1118467)[ 1172.359] TRACE tlsuv:tls_link.c:131 TLS(0x5f912dffa680) continuing handshake(5456 bytes received)
(1118467)[ 1172.359] TRACE tlsuv:tls_link.c:137 TLS(0x5f912dffa680) continuing handshake(sending 0 bytes, st = 3)
(1118467)[ 1172.359] ERROR tlsuv:tls_link.c:160 TLS(0x5f912dffa680) handshake error SSL - An invalid SSL record was received
(1118467)[ 1172.359] ERROR tlsuv:http.c:188 handshake failed status[3]: SSL - An invalid SSL record was received
(1118467)[ 1172.359] VERBOSE tlsuv:http.c:356 closing connection
I encountered a condition on Linux with the latest ZET release 0.22.20 where ZET doesn't recover after escaping a captive portal.
The workaround is to restart ZET after escaping the captive portal (no MitM).
If a captive portal/MitM prevents T-SDK (not reproducible with C-SDK via
ziti-prox-c) from verifying the client API's server certificate, and the captive portal login is performed to eliminate the MitM, then ZET doesn't recover and continues to report controller unavailable, no API session is obtained, no routers are connected, and no services work, despite the client API being available with no MitM.The condition does not recur after a reboot if the captive portal authorization for the Ethernet address is remembered, and the condition can be reproduced by changing the Ethernet address, thereby restarting the captive portal login flow and reintroducing the MitM.
@ekoby pointed out this appears to be related to ZET's implementation of "exlusion routes," which are static routes installed by ZET that have a higher specificity than intercept routes and thereby prevent interception of packets destined for the Ziti controllers' client API listeners or routers' edge listeners.