iOS Ziti Client cannot connect to controller

Tunneler Apps
1

So today I went to use my Ziti on my iOS phone. The account went to a red dot when I enabled the client ( I leave it disabled as it is/was a battery hog).

The controller is online, as my Windows client, running on the same WiFi can access it correctly.

Looking at the controller log I am getting this:
[2829703.426] ERROR transport/v2/tls.(*sharedListener).processConn [tls:0.0.0.0:1280]: {remote=[192.168.9.27:49186] error=[local error: tls: bad record MAC]} handshake failed

Looking on the client logs, it is saying that the CONTROLLER UNAVAILABLE.

This client entity has been around a long time. So, as I had updated my controller about a month or two ago, I thought that I would just reissue my token. So, I did that, removed the entity on the phone, scanned the QR code and still the same issue.

I then checked the version of Ziti client on iOS: 2.4.5. I see there is an update to 2.4.7. Installed and still no dice. Restarted the phone as I generally need to do this with a ziti client update. Still no dice.

Basically the phone can connect to the controller (to start an initial communication), but then the controller says the MAK is incorrect.

To check, I created a new identity, and imported into ZDEW, and it worked fine, so something up with the iOS client. ZDEW is working fine.

I have sent the phone logs through to help at openziti dot org.

I am running docker-compose version 1.1.10

Let me know if you need anything else

2

Hi @gooseleggs, sorry to hear you're having this issue. I helped another forum member through this just recently as well and I'm not sure if there will be a really good answer here. It's gonna take me a bit to try to replicate the issue.

The root of the problem - I believe - stems from the change to mbed tls to openssl. Openssl is somehow being more strict when it comes to the PKI that it consumes. Older networks based on the older, original versions of the quickstart (> 1 year ago, which I'm sure your network is) have a PKI configuration that is not compatible with openssl. :confused:

The quick fix is to roll the client back for the time being while I try to figure out if there's a graceful way to upgrade one of these older PKIs to be compatible with the new openssl-based tunnelers.

The other "quick fix" (depending on how many services/clients you have) is to rebuild the network. The new quickstart will emit the CA bundle in a way that's compatible with both (as will the "linux deployment" which is newer, if you'd rather go that route).

Again, sorry you're hitting this issue. It might take a while for me to figure out a graceful way to do this. The quickstart was changed pre the 1.0 release and with the jump to 1.0 it seems we successfully broke some backward compatibility with 0.x based quickstarts of a certain age...

3

Yeah I am from an old school 0.28. It did work after I upgraded so yes I think the new clients are being different. Don’t think I can downgrade iOS client.

I did see this and wondered if I should do this. Probably would not hurt. Is this what you are thinking?

4

@TheLumberjack

Got up and going on the phone. Thanks to the post linked to above, that got me most of the way there. It worked for the controller certificates. However, in my setup, I had a multiple chain of intermediate certificates on my edge router.

This was found by using openssl x509 -in _filename_ -text | grep Issuer to follow who signed what and going backwards to the root CA.

Basically:
Ziti Controller:

ziticontroller.thesmithcave.nz-client.cert
  ziticontroller.thesmithcave.nz-intermediate

Ziti Edge Router:

client/server.cert
  ziti-signing-intermediate
    ziti-signing-intermediate_spurious_intermediate

When I try the verify command from the post above on the controller I end up with a 0, so that is good.

When I try and do that with the edge-router, I get errrors

[kelvins@Server2 pki]$ ZITI_EDGE_CTRL_ADVERTISED_HOST_PORT=zitiedgerouter.thesmithcave.nz:3022
[kelvins@Server2 pki]$ openssl s_client -connect "${ZITI_EDGE_CTRL_ADVERTISED_HOST_PORT}" -CAfile /tmp/cacerts.pem < /dev/null | grep Verify
depth=1 C = US, L = Charlotte, O = NetFoundry, OU = ADV-DEV, CN = ziti-signing-intermediate
verify error:num=2:unable to get issuer certificate
issuer= C = US, L = Charlotte, O = NetFoundry, OU = ADV-DEV, CN = ziti-signing-intermediate_spurious_intermediate
verify return:1
depth=0 C = US, ST = NC, L = Charlotte, O = NetFoundry, OU = Ziti, CN = KpnBJA6HTS
issuer= C = US, L = Charlotte, O = NetFoundry, OU = ADV-DEV, CN = ziti-signing-intermediate
verify return:1
DONE

but it is connected and I can route traffic though it. Something to look at another day. It is up and going. I will update back here if I sort out the edge-router certificate chain.

5

I'm very glad you were able to get through this! Thanks for following up and letting us know. Your issue was high on my list but I hadn't gotten to it yet... The routers have a re-enroll capability that might be easier to deal with than trying to fix the existing pki since there are generally few routers on an overlay.

You can stop your router then re-enroll it:

# stop edge router
ziti edge re-enroll edge-router "${EDGE_ROUTER_NAME}" -o "/tmp/${EDGE_ROUTER_NAME}.jwt"

You can then enroll it:

ziti router enroll "/path/to/${EDGE_ROUTER_NAME}.yaml --jwt "/tmp/${EDGE_ROUTER_NAME}.jwt"

The problem is likely with the bundle that was pulled down during the original enrollment process. In the edge router identity section - the ca file is likely incomplete as it was enrolled with a different ca bundle.

Maybe that'll help? Let me know if I can help in any way.