Raft (Integrated Storage) follower joined as non voters after restore

My setup: K8s cluster installed by helm chart
in the values:

vault.server.ha.enabled: true

vault.server.ha.raft.enabled: true

What happened: after struggling to make the vault work when IPV V6 was disabled on the cluster, we decided to remove the installation and restore it with the last snapshot we did.
I’ve installed from scratch the vault (no PVC or any previous installation), on pod 0 - used vault operator init and unseal to open it, and used the snapshot to restore.
Then in pods 1-2, I’ve used the command:

vault operator raft join http://vault-server-0.vault-server-internal:8200

(the NS is vault-server that explains the string)
and once the pod was joined, I used vault operator unseal, but after completing the unseal progress, the vault kept being sealed.
In the list of peers I can see the new followers was added but they are non voters:

/ $ vault operator raft list-peers
Node                                    Address                                      State       Voter
----                                    -------                                      -----       -----
42242bd0-a48c-59f9-6e6b-***    vault-server-0.vault-server-internal:8201    leader      true
e243c8f2-2c8d-5d6c-36e2-***    vault-server-1.vault-server-internal:8201    follower    false
6a79dcd5-2aac-fe19-bd5d-***    vault-server-2.vault-server-internal:8201    follower    false

What I did do wrong to bring the vault alive in this step?
What can be done to make sure the nodes will be joining as voters?

Anyone solve this issue? or face it in any other situation

Troubleshooting raft consensus can be complex. Have you checked the logs for any errors during the unseal process? Also, ensure that your network settings allow proper betflix club communication between nodes. Best of luck resolving the vault sealing issue!

The communication between nodes is OK.
From pod 0# I did this:

/ $ ping vault-server-0.vault-server-internal 
PING vault-server-0.vault-server-internal (10.42.196.176): 56 data bytes
64 bytes from 10.42.196.176: seq=0 ttl=42 time=0.415 ms
64 bytes from 10.42.196.176: seq=1 ttl=42 time=0.325 ms

so we can see that DNS is resolved as expected and the request returned