Relay - Could Not Connect

Support / Troubleshooting
1

image
image701×383 21.2 KB

Running on Proxmox 8.0.3 as LXC Container.
Everything was working fine for 3 weeks. Suddenly the Relay stopped connecting.
Checked ports 30000- 31000 and they are okay.

Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-24 13:05 IDT
Nmap scan report for twingate.com (104.198.14.52)
Host is up (0.21s latency).
rDNS record for 104.198.14.52: 52.14.198.104.bc.googleusercontent.com

PORT STATE SERVICE
30001/tcp filtered pago-services1

Nmap done: 1 IP address (1 host up) scanned in 2.62 seconds

real 0m2.625s
user 0m0.039s
sys 0m0.005s

2

Hi there,

Is there anything in your Twingate Connector Logs that might suggest what’s going on?

3

2023-07-24T17:11:07.498624000Z [DEBUG] [libsdwan] [relay] get_needed_conns_count: relay 34.147.189.15:30000, needed_conns_count 0
2023-07-24T17:11:07.498661000Z [DEBUG] [libsdwan] [relay] get_needed_conns_count: relay 34.147.235.124:30014, needed_conns_count 0
2023-07-24T17:11:07.498707000Z [DEBUG] [libsdwan] relaybalancer::get_instance: “relaybalancer+https://relays.twingate.com”
2023-07-24T17:11:07.498747000Z [DEBUG] [libsdwan] http::request::send_request: GET “https://relays.twingate.com/api/v2/metadata” text/plain
2023-07-24T17:11:07.498789000Z [DEBUG] [libsdwan] [relay] get_all_listen_addrs: listeners_ size 1
2023-07-24T17:11:07.851201000Z [DEBUG] [libsdwan] http::response::from: certificate <certificate_thumbprint>, issuer: C=US, O=Let’s Encrypt, CN=R3, subject: CN=relays.twingate.com
2023-07-24T17:11:07.851354000Z [DEBUG] [libsdwan] http::request::handle_response: GET “https://relays.twingate.com/api/v2/metadata” 200 OK (duration 0 sec)
2023-07-24T17:11:07.851429000Z [DEBUG] [libsdwan] relaybalancer::operator(): relay info: {“ip”:“35.234.129.66”,“port”:“30005”,“stun”:“stun.europe-west2-a.twingate.com:3478”,“stuns”:[“stun.europe-west2-a.twingate.com:3478”,“stun-alt.europe-west2-a.twingate.com:3478”],“zone”:“europe-west2-a”}
2023-07-24T17:11:07.851497000Z [DEBUG] [libsdwan] [relay] operator(): new relay instance: zone europe-west2-a, addr 35.234.129.66:30005
2023-07-24T17:11:07.851565000Z [DEBUG] [libsdwan] [relay] get_needed_conns_count: relay 35.234.129.66:30005, needed_conns_count 16
2023-07-24T17:11:07.851641000Z [DEBUG] [libsdwan] [token_fetcher] get_ct: requesting ct_key_t(network: any)
2023-07-24T17:11:07.851708000Z [DEBUG] [libsdwan] [token_fetcher] get_token: got a cached token for ct_key_t(network: any)
2023-07-24T17:11:07.851779000Z [DEBUG] [libsdwan] [relay] get_needed_conns_count: relay 35.234.129.66:30005, needed_conns_count 16
2023-07-24T17:11:07.851845000Z [DEBUG] [libsdwan] [relay] connect: opening 16 connections to relay relays.twingate.com at 35.234.129.66:30005
2023-07-24T17:11:07.851932000Z [DEBUG] [libsdwan] relay_connect(0x5620870872d0)
2023-07-24T17:11:07.852002000Z [DEBUG] [libsdwan] dns_getaddrinfo(35.234.129.66:30005)
2023-07-24T17:11:07.852071000Z [DEBUG] [libsdwan] resolve_cb: connecting to 35.234.129.66:30005
2023-07-24T17:11:07.852131000Z [DEBUG] [libsdwan] relay_conntrack(0x5620870872d0)
2023-07-24T17:11:07.852188000Z [DEBUG] [libsdwan] relay_set_state(0x562086fe1420): switching state from 5 to 1
2023-07-24T17:11:07.852256000Z [DEBUG] [libsdwan] relay_connect(0x562086fe1420) hostname: 35.234.129.66:30005, proto: 1, err: 0
2023-07-24T17:11:07.852336000Z [DEBUG] [libsdwan] relay_connect(0x5620870d8150)
2023-07-24T17:11:07.852409000Z [DEBUG] [libsdwan] dns_getaddrinfo(35.234.129.66:30005)
2023-07-24T17:11:07.852481000Z [DEBUG] [libsdwan] resolve_cb: connecting to 35.234.129.66:30005
2023-07-24T17:11:07.852544000Z [DEBUG] [libsdwan] relay_conntrack(0x5620870d8150)
2023-07-24T17:11:07.852615000Z [DEBUG] [libsdwan] relay_set_state(0x562086fde560): switching state from 5 to 1
2023-07-24T17:11:07.852680000Z [DEBUG] [libsdwan] relay_connect(0x562086fde560) hostname: 35.234.129.66:30005, proto: 1, err: 0
2023-07-24T17:11:07.852743000Z [DEBUG] [libsdwan] relay_connect(0x562087070680)

4

It’s Okay now.

It was a routing problem in my split VPN configuration.