#Locked my self out with VPN

1 messages · Page 1 of 1 (latest)

obsidian tendon
#

I have oracle cloud
Ubuntu 22.04
i have public ssh port 22 and tailscale opened too

applied vpn then it locked me out.

I managed to connect via Console connection within oracle cloud now im at:
root@(none):/#

i need you to give me steps how can i secure my connection back via vs code and tailscale

tulip jungleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

obsidian tendon
#

@formal heron help needed important urgent

formal heronBOT
formal heronBOT
# obsidian tendon <@1457407575476801641> help needed important urgent

Don’t reboot yet. Since you’re in the OCI console as root, you can recover SSH + Tailscale pretty quickly.

Fast recovery (most common lockout causes)

1) Make sure SSH is running + listening on all interfaces

systemctl restart ssh
ss -tulpn | grep ':22' || true

If that shows nothing listening on :22, paste:

systemctl status ssh --no-pager

2) Temporarily disable the firewall (to regain access), then we’ll tighten it

If you use UFW:

#
  • If ping 1.1.1.1 works but ping google.com fails → DNS got broken.

(Reply with that output if anything fails.)

1) Identify what “VPN” changed (and temporarily stop it)

Common lockout cause: a VPN client/server changed default routes or firewall policy.

Check what new interfaces exist:

ip link | egrep 'wg|tun|tap|tailscale' || true
systemctl --failed --no-pager
systemctl list-units --type=service --no-pager | egrep -i 'wireguard|wg|openvpn|strongswan|ipsec|tailscale' || true
# 
ufw status verbose || true
ufw disable

If you don’t have UFW, tell me what ufw status prints (or “command not found”).

3) Bring Tailscale back up (so you can connect securely)

systemctl enable --now tailscaled
tailscale status || true
tailscale up
tailscale ip -4

If tailscale up asks for login and you can’t do browser auth easily from console, use a Tailscale auth key:

#

Then stop the non‑tailscale VPN service (examples):

If WireGuard:

wg show || true
systemctl stop wg-quick@wg0 2>/dev/null || true
wg-quick down wg0 2>/dev/null || true

If OpenVPN:

systemctl stop 'openvpn*' 2>/dev/null || true

Re-check routes:

# 
tailscale up --authkey tskey-REDACTED

4) Test from your laptop

  • ssh ubuntu@<TAILSCALE_100.x_IP>
  • Then VS Code Remote-SSH to that same host/IP.

If it still fails, paste these 6 outputs (from the OCI console)

ip -br a
ip route
systemctl status ssh --no-pager
ss -tulpn | grep ':22' || true
# 
ip route

You want the default route to be via your main NIC (often ens3 on OCI), not wg0/tun0.

2) Make sure SSH is actually listening (common: ListenAddress got set to VPN only)

Check SSH service + listening sockets:

systemctl status ssh --no-pager
ss -tulpn | grep ':22' || true

Then inspect SSH config for anything that binds only to a VPN IP:

# 
ufw status verbose || true
tailscale status || true

Also tell me: what “VPN” did you apply (WireGuard / OpenVPN / something else)? That determines the exact service to stop/undo.

# 
grep -R --line-number -E '^(ListenAddress|Port|PasswordAuthentication|PermitRootLogin|AllowUsers|DenyUsers)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true

If you see something like ListenAddress 10.x.x.x (VPN IP), remove/comment it so SSH listens normally again.

Validate + restart:

sshd -t
systemctl restart ssh
ss -tulpn | grep ':22'

3) Fix the firewall enough to get back in (then we’ll tighten it)

#

On Ubuntu, it’s usually ufw:

ufw status verbose || true

If it’s enabled and blocking, allow SSH at least temporarily:

ufw allow 22/tcp
ufw reload

If you plan to use Tailscale SSH-over-tailnet (recommended), also allow SSH via the Tailscale interface:

# 
ufw allow in on tailscale0 to any port 22 proto tcp
ufw reload

(If you’re using nftables/iptables instead of ufw, tell me what ufw status says and I’ll adapt.)

4) Bring up Tailscale cleanly (this is the easiest “secure VS Code access”)

Ensure tailscaled is running:

systemctl enable --now tailscaled
tailscale status || true
#

If it’s not logged in, the safest way from console is an auth key (don’t paste it publicly):

  1. In Tailscale admin → Keys → create an auth key (prefer ephemeral if this is a single server).
  2. On the server:
tailscale up --authkey tskey-REDACTED
tailscale ip -4

From your laptop:

  • Confirm you can reach it: tailscale ping <100.x.y.z>
  • SSH in via tailnet IP: ssh ubuntu@<100.x.y.z>

5) Lock it down properly (so you don’t get locked out again)

#

Once you can SSH in over Tailscale:

A) Restrict/close public SSH at the OCI layer (best)

In OCI Networking (VCN Security List / NSG):

  • Remove 0.0.0.0/0 → TCP 22
  • Either:
    • allow TCP 22 only from your home IP, or
    • close TCP 22 entirely and use Tailscale for access

B) Harden SSH on the VM (after you confirm Tailscale works)

In /etc/ssh/sshd_config or a file in /etc/ssh/sshd_config.d/:

  • PasswordAuthentication no
  • PermitRootLogin no
  • use SSH keys only

Then:

# 
sshd -t && systemctl restart ssh

6) VS Code setup (simple)

Use the Tailscale IP as the host:

~/.ssh/config on your laptop:

Host oci
  HostName 100.x.y.z
  User ubuntu

Then VS Code “Remote-SSH” → connect to oci.

#

If you paste me these outputs, I can tell exactly what broke

Run and paste (from the OCI console):

ip -br a
ip route
systemctl status ssh --no-pager
ss -tulpn | grep ':22' || true
ufw status verbose || true
tailscale status || true

Also: what “VPN” did you apply (WireGuard/OpenVPN/something else)? That determines the cleanest rollback.

obsidian tendon
#

root@(none):/# ufw status verbose || true
Status: inactive
root@(none):/# systemctl enable --now tailscaled
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@(none):/# tailscale status || true
failed to connect to local tailscaled; it doesn't appear to be running (sudo systemctl start tailscaled ?)
root@(none):/# tailscale up
failed to connect to local tailscaled; it doesn't appear to be running (sudo systemctl start tailscaled ?)
root@(none):/# tailscale ip -4
Failed to connect to local Tailscale daemon for /localapi/v0/status; not running? Error: dial unix /var/run/tailscale/tailscaled.sock: connect: no such file or directory
root@(none):/# ip -br a
lo DOWN
enp0s6 UP 10.0.0.28/24 fe80::17ff:fe06:a54e/64
root@(none):/# ip route
default via 10.0.0.1 dev enp0s6
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.28
169.254.0.0/16 dev enp0s6 scope link
root@(none):/# ss -tulpn | grep ':22' || true
root@(none):/# ip route
default via 10.0.0.1 dev enp0s6
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.28
169.254.0.0/16 dev enp0s6 scope link
root@(none):/# systemctl status ssh --no-pager
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@(none):/# ss -tulpn | grep ':22' || true
root@(none):/#

#

Try: apt install <deb name>
root@(none):/# systemctl restart ssh
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@(none):/# systemctl status ssh --no-pager
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@(none):/# ip link | egrep 'wg|tun|tap|tailscale' || true
root@(none):/# systemctl --failed --no-pager
System has not been booted with systemd as init system (PID 1). Can't operate. oot@(none):/#
Failed to connect to bus: Host is down oot@(none):/# systemctl list-units --type=service --no-pager | egrep -i 'wiregua
System has not been booted with systemd as init system (PID 1). Can't operate.list-units --type=service --no-pager | egrep -i 'wiregu oot@(none):/# 0~systemctl lFailed to connect to bus: Host is downegrep -i 'wireg oot@(none):/# 00~systemctl list-units --type=service --no-pager | egrep -i 'wire
root@(none):/# ~ oot@(none):/# 200~systemctl list-units --type=service --no-pager | egrep -i 'wir
root@(none):/# [200~systemctl list-units --type=service --no-pager | egrep -i 'wi
root@(none):/# penvpn|strongswan|ipsec|tailscale' || true --no-pager | egrep -i '
root@(none):/#
root@(none):/#

#

"[ OK ] Stopped Service for snap application nordvpn.nordvpnd.

[FAILED] Failed to start Service fo… application nordvpn.nordvpnd.

See 'systemctl status snap.nordvpn.nordvpnd.service' for details.

[ OK ] Started Tailscale node agent."

#

i have renamed the folder so it cant start the nordvpn yet i still cant login with vs code even after restart, so something is off

#

i found something interesting

#

"This machine’s key expired 1 day ago and needs to be reauthenticated."

#

on tailscale website

formal heronBOT
# obsidian tendon "[ OK ] Stopped Service for snap application nordvpn.nordvpnd. [FAILED] Faile...

Good sign: NordVPN is stopped/failed and Tailscale started. Now the goal is: (1) make sure NordVPN isn’t still messing with routes/DNS, (2) confirm Tailscale is actually online, (3) SSH in via the Tailscale 100.x IP (then VS Code Remote-SSH).

1) Keep NordVPN from re-applying networking changes

Run:

systemctl disable --now snap.nordvpn.nordvpnd.service || true
snap disable nordvpn || true

(We’re just preventing it from starting again while you recover.)

2) Check if your default route is broken (most common lockout)

Paste this output:

# 
ip route show default
ip -br a

If you see default ... dev tun0 / wg0 / something that isn’t your main NIC (often ens3 on OCI), that’s the problem.

3) Confirm Tailscale is really up and get the IP you should SSH to

Run:

tailscale status
tailscale ip -4

You want a 100.x.y.z IP.

#

If it says you’re not logged in, do:

tailscale up

(or use an auth key: tailscale up --authkey tskey-REDACTED)

4) Ensure SSH is listening (for Tailscale SSH/Remote-SSH)

systemctl restart ssh
ss -tulpn | grep ':22' || true

5) If UFW is enabled, allow SSH from Tailscale interface

ufw status verbose || true
ufw allow in on tailscale0 to any port 22 proto tcp
# 
ufw reload

Then from your laptop

  • ssh ubuntu@100.x.y.z
  • VS Code Remote-SSH → connect to ubuntu@100.x.y.z

Paste these 4 command outputs and I’ll tell you the exact next fix (no guessing):

ip route show default
tailscale status
tailscale ip -4
ss -tulpn | grep ':22' || true
#

Renaming the NordVPN folder won’t undo what it already changed. With NordVPN, the usual culprit is the kill switch / firewall rules (iptables/nft) that stay in place even after the service dies — so SSH/VS Code still can’t reach the box.

Also: VS Code Remote-SSH is “just SSH”. First we need plain ssh working (ideally over Tailscale 100.x).

1) From your laptop: get the exact SSH error (this tells us what’s broken)

Try in a terminal (not VS Code):

ssh -vvv ubuntu@YOUR_TAILSCALE_100_IP
# or if you’re still trying public IP:
ssh -vvv ubuntu@YOUR_PUBLIC_IP

Paste the last ~30 lines. The key phrases are usually:

  • Connection timed out (network/firewall/routing)
  • Connection refused (sshd not listening / wrong interface)
  • Permission denied (publickey) (auth/user/key issue)
#

2) From the OCI console on the server: paste these outputs

Run:

tailscale status
tailscale ip -4
ss -tulpn | egrep ':22|sshd' || true
ufw status verbose || true
iptables -S | head -n 80
nft list ruleset 2>/dev/null | head -n 120 || true
ip route show default

This will show immediately if:

  • Tailscale is actually logged in and has a 100.x IP
  • sshd is listening on 0.0.0.0:22 / :::22 (good) vs only 127.0.0.1:22 (bad)
  • firewall default policies are DROP (classic Nord kill switch symptom)
#

3) Most likely fix (if you see firewall DROP / kill-switch rules)

If iptables -S shows default policy DROP on INPUT/OUTPUT/FORWARD, do a temporary reset to regain access (you can re-harden after):

ufw disable 2>/dev/null || true

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -t nat -F
iptables -X

Then restart SSH:

# 
systemctl restart ssh
ss -tulpn | grep ':22' || true

After that, try ssh ubuntu@100.x.y.z again from your laptop.

4) Important: connect VS Code to the Tailscale IP

In VS Code Remote-SSH, use the host ubuntu@100.x.y.z (not the public IP). If you want, add this to ~/.ssh/config on your laptop:

Host oci
  HostName 100.x.y.z
  User ubuntu

Then connect to oci.

#

Paste the outputs from step (2) and the ssh -vvv tail from step (1) and I’ll tell you exactly which branch it is (firewall vs sshd bind vs auth).

#

If you’re on the Tailscale admin website right now: check whether your Oracle VM shows “Connected/Online” or “Offline/Last seen …”.

A) If the machine is Offline in Tailscale admin

That means the server can’t reach Tailscale control plane (almost always NordVPN kill-switch / firewall / broken default route).

From the OCI console, run and paste just these:

ip route show default
tailscale status
tailscale netcheck 2>/dev/null || true

Very likely fix (Nord kill switch rules stuck): temporarily reset firewall so outbound works again:

# 
ufw disable 2>/dev/null || true

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -t nat -F
iptables -X

Then:

systemctl restart tailscaled
tailscale up
# 
tailscale status
tailscale ip -4

Once it shows online and you have a 100.x.y.z, you can SSH/VS Code via that.

B) If the machine is Online in Tailscale admin

Grab the server’s 100.x.y.z address (or run on server):

tailscale ip -4

Then from your laptop (terminal first):

# 
ssh -vvv ubuntu@100.x.y.z
  • If that works, VS Code Remote-SSH should work to the same ubuntu@100.x.y.z.
  • If it fails, paste the last ~30 lines of that ssh -vvv output (it’ll say timeout/refused/permission denied, which tells us exactly what to fix).

One quick question: in Tailscale admin, does your server show Online or Offline right now?

obsidian tendon
#

This machine has key expiry disabled and never needs to reauthenticate.

i extended yet i still cant login

formal heronBOT
# obsidian tendon This machine has key expiry disabled and never needs to reauthenticate. i exten...

That “key expiry disabled / never needs to reauthenticate” line is only about the Tailscale node key. It doesn’t mean the box is reachable. If you still can’t login, it’s almost certainly one of these:

  1. the VM is offline in Tailscale (Nord kill-switch / firewall / routing / DNS), or
  2. Tailscale is online, but SSH isn’t reachable (sshd not listening / firewall blocking / wrong user/key)

Step 1 — On Tailscale admin page

Open the machine entry and tell me what it says for:

  • Status: Online or Offline
  • Last seen: (a time, or “now”)

Step 2 — From the OCI console (on the VM) run these and paste output

tailscale status
tailscale ip -4
ip route show default
ss -tulpn | egrep ':22|sshd' || true
# 
ufw status verbose || true

Step 3 — From your laptop (terminal, not VS Code), try SSH and paste the last lines

Use the Tailscale 100.x IP (not public IP):

ssh -vvv ubuntu@100.x.y.z

The exact failure text matters:

  • timeout = firewall/routing
  • refused = sshd not listening / blocked locally
  • permission denied = wrong user/key

Once you paste those outputs, I’ll tell you the exact fix (and then how to lock it down so only Tailscale can access it).

obsidian tendon
#

in oracle dashboard this is the notificaiton: "Something went wrong
This instance is unresponsive. Confirm that the OS and network are configured correctly, and check the infrastructure health metrics to see determine whether there is an ongoing infrastructure issue.
"

#

in tailscale dashboard the oracle server is unseen

formal heronBOT
# obsidian tendon in oracle dashboard this is the notificaiton: "Something went wrong This instanc...

That OCI banner (“instance is unresponsive”) usually means the Oracle agent/health checks can’t reach the VM, most often because the VM’s network/routing/firewall got broken (NordVPN kill-switch is a classic cause). It doesn’t necessarily mean the VM is dead.

0) Can you still get in via OCI Console/Serial?

  • If yes → do the steps below.
  • If no → you’ll likely need OCI “boot volume attach to another instance” to repair /etc/netplan/* and firewall rules (tell me and I’ll outline that recovery path).

1) From the OCI console: check if the OS is actually alive

Run:

uptime
df -h
free -h
#

If disk is 100% full or RAM is exhausted, fix that first.

2) Check whether networking is broken (IP + default route)

ip -br a
ip route
ping -c2 1.1.1.1
ping -c2 google.com

Interpretation:

  • ping 1.1.1.1 fails → routing/interface/firewall is broken
  • ping 1.1.1.1 works but ping google.com fails → DNS broken
formal heronBOT
# obsidian tendon in tailscale dashboard the oracle server is unseen

If the server is “unseen” in Tailscale, it’s basically not reaching Tailscale at all (usually: no outbound internet because NordVPN kill-switch / firewall / routing got stuck). Fix that from the OCI console first.

1) From OCI console: confirm the VM has outbound internet

Run:

ip -br a
ip route show default
ping -c2 1.1.1.1
  • If ping 1.1.1.1 fails → it’s routing/firewall. Do step 2.

2) Remove kill-switch firewall rules (safe to do while you have console access)

Run:

#

3) Undo NordVPN kill-switch/firewall (quick “get connectivity back” reset)

From the OCI console:

ufw disable 2>/dev/null || true

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -t nat -F
iptables -X

nft flush ruleset 2>/dev/null || true

Then retry:

# 
ufw disable 2>/dev/null || true

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -t nat -F
iptables -X

nft flush ruleset 2>/dev/null || true

Then test again:

# 
ping -c2 1.1.1.1

(If that suddenly works, you found the culprit.)

4) If you have no default route / no IP on the main NIC: fix netplan

On OCI Ubuntu it’s usually DHCP on ens3.

Show netplan:

ls -l /etc/netplan
sed -n '1,200p' /etc/netplan/*.yaml
# 
ping -c2 1.1.1.1
ping -c2 google.com

3) If there is NO default route (or it’s wrong), renew DHCP on the main NIC

On OCI Ubuntu it’s usually ens3:

ip link
dhclient -v ens3
ip route show default

If you don’t have dhclient, tell me what ip link shows as your main interface name.

4) Once ping works: restart Tailscale and bring it up

#

If it looks wrong, the “safe default” netplan for OCI is typically:

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      dhcp6: false

Apply:

netplan generate
netplan apply
ip route show default
# 
systemctl restart tailscaled
tailscale status
tailscale up
tailscale ip -4

After this, the machine should show Online in the Tailscale dashboard.

Paste me these outputs (from OCI console) and I’ll tell you the exact next move

ip -br a
ip route show default
ping -c2 1.1.1.1
#

5) Bring back Tailscale + SSH (for VS Code Remote-SSH)

systemctl restart tailscaled
tailscale status
tailscale ip -4

systemctl restart ssh
ss -tulpn | grep ':22' || true

Then from your laptop, test Tailscale IP (100.x):

ssh -vvv ubuntu@100.x.y.z
# 
tailscale status
journalctl -u tailscaled -n 50 --no-pager

Also confirm: do you still have OCI console access right now, or did that also stop working?

#

Paste these outputs and I’ll tell you exactly which branch you’re in

From OCI console:

ip -br a
ip route
ping -c2 1.1.1.1
tailscale status
ss -tulpn | grep ':22' || true

Also: can you confirm you’re still able to use the OCI console right now?

obsidian tendon
#

root@(none):/# ip -br a
lo DOWN
enp0s6 UP 10.0.0.28/24 fe80::17ff:fe06:a54e/64
root@(none):/# ip route show default
default via 10.0.0.1 dev enp0s6
root@(none):/# ^[[200~ip -br a
ip: command not found
root@(none):/# ip route show default
default via 10.0.0.1 dev enp0s6
root@(none):/# ping -c2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=0.912 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=0.905 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.905/0.908/0.912/0.003 ms
root@(none):/# ~

formal heronBOT
# obsidian tendon root@(none):/# ip -br a lo DOWN enp0s6 UP ...

Nice — your VM’s IP + default route look correct and ping 1.1.1.1 works. That means the box has outbound connectivity at least for ICMP.

If Tailscale still shows “unseen”, the usual remaining blockers are:

  1. DNS is broken (so tailscaled can’t reach login.tailscale.com / controlplane.tailscale.com)
  2. Time is wrong (TLS cert checks fail)
  3. tailscaled is running but failing/auth stuck (logs will say why)

Run these on the OCI console and paste the output

# DNS + time checks
ping -c2 google.com || true
getent hosts login.tailscale.com controlplane.tailscale.com || true
cat /etc/resolv.conf
date -u
# 
# Tailscale health
systemctl status tailscaled --no-pager || true
tailscale status || true
journalctl -u tailscaled -n 120 --no-pager || true

If ping google.com fails OR getent hosts ... fails (DNS broken)

Quick fix (safe, reversible) — set DNS on your NIC (yours is enp0s6):

resolvectl dns enp0s6 1.1.1.1 8.8.8.8
resolvectl domain enp0s6 "~."
systemctl restart systemd-resolved
#

Then retry:

getent hosts login.tailscale.com
systemctl restart tailscaled
tailscale up
tailscale ip -4

If date -u is way off (wrong year/time)

Fix time (TLS will fail otherwise):

timedatectl set-ntp true || true
systemctl restart systemd-timesyncd || true
date -u
#

Then restart Tailscale:

systemctl restart tailscaled
tailscale up

Once Tailscale comes online and tailscale ip -4 shows a 100.x.y.z, connect VS Code Remote-SSH to that 100.x IP (not the public IP).

Paste those outputs and I’ll tell you exactly which one (DNS vs time vs tailscaled error) is blocking you.