You can then update the section for wire_guard_state.concordia.peer in config.yml with peerip from the list above, and pubkey, and endpoint (remove the :51820).
You should then be able to run the console for condordia, and you can do the same for the other org as well.
Will update again once we get the issue fixed, but this should route you via lhr instead of fra.
It doesn’t work at all.
I work from Russia.
I tried connect to VPN in London, removed wire_guard_state record and ran flyctl ssh console -a concordia-production-web -r lhr
But for @ matt2 this doesn’t work either, he’s in UK
We don’t have a clear fix for the problem yet — I’ve replicated it and fixed it for myself by removing all my peers using fly wireguard remove, then trying to re-connect (it should create a new peer for you).
You could do fly wireguard list to see which peers are in fra and then remove those selectively.
@nickolay.loshkarev can you confirm that the problem is still happening even after removing all peers using fly wireguard remove? That should take out your old peers and give you new ones when you try to connect again.
In my case the Wireguard macOS app seems to have set up the internal VPN DNS server correctly, in case that doesn’t happen at your end you can change the dig command to explicitly include the DNS server:
dig aaaa <app>.internal @fdaa:<xxx>
You’ll find your DNS server in the .conf created when calling fly wireguard create