JM Net 1.2.5

• Fixes Connect failing on macOS with "jmnet0 already exists as utun12": macOS will not let WireGuard name an interface, so JM Net was not recognising its own live tunnel, decided it was disconnected, and tried to connect a second time
• JM Net now finds its tunnel by reading ifconfig and looking for a utun carrying one of your 100.64.x.y addresses. The previous attempt read /var/run/wireguard, which the app cannot actually read because it runs as you rather than as root — so it reported a working tunnel as disconnected
• Connecting now asks for your password exactly once. Installing the configuration and bringing the tunnel up were two separate elevated steps, so one Connect click meant two prompts — and three or four while the macOS bug above was sending it round the retry path
• A failed connect still tells you which part failed: installing the configuration and bringing the interface up have separate messages, because the first is usually a declined prompt and the second is not
• Your WireGuard private key still never appears in a command line or in any elevated script — it travels in a file only you can read, and the single elevated step moves it into place

JM Net 1.2.4

• Fixes Connect failing on macOS with "jmnet0 already exists as utun12": macOS will not let WireGuard name an interface, so JM Net was not recognising its own live tunnel, decided it was disconnected, and tried to connect a second time
• JM Net now finds its tunnel by reading ifconfig and looking for a utun carrying one of your 100.64.x.y addresses. The previous attempt read /var/run/wireguard, which the app cannot actually read because it runs as you rather than as root — so it reported a working tunnel as disconnected
• Connecting now asks for your password exactly once. Installing the configuration and bringing the tunnel up were two separate elevated steps, so one Connect click meant two prompts — and three or four while the macOS bug above was sending it round the retry path
• A failed connect still tells you which part failed: installing the configuration and bringing the interface up have separate messages, because the first is usually a declined prompt and the second is not
• Your WireGuard private key still never appears in a command line or in any elevated script — it travels in a file only you can read, and the single elevated step moves it into place

JM Net 1.2.3

• Fixes Connect failing on macOS with "jmnet0 already exists as utun12": macOS will not let WireGuard name an interface, so JM Net was not recognising its own live tunnel, decided it was disconnected, and tried to connect a second time
• JM Net now finds its tunnel by reading ifconfig and looking for a utun carrying one of your 100.64.x.y addresses. The previous attempt read /var/run/wireguard, which the app cannot actually read because it runs as you rather than as root — so it reported a working tunnel as disconnected
• Connecting now asks for your password exactly once. Installing the configuration and bringing the tunnel up were two separate elevated steps, so one Connect click meant two prompts — and three or four while the macOS bug above was sending it round the retry path
• A failed connect still tells you which part failed: installing the configuration and bringing the interface up have separate messages, because the first is usually a declined prompt and the second is not
• Your WireGuard private key still never appears in a command line or in any elevated script — it travels in a file only you can read, and the single elevated step moves it into place

JM Net 1.2.2

• Fixes Connect failing on macOS with "jmnet0 already exists as utun12": macOS will not let WireGuard name an interface, so JM Net was not recognising its own live tunnel, decided it was disconnected, and tried to connect a second time
• JM Net now finds its tunnel by reading ifconfig and looking for a utun carrying one of your 100.64.x.y addresses. The previous attempt read /var/run/wireguard, which the app cannot actually read because it runs as you rather than as root — so it reported a working tunnel as disconnected
• Connecting now asks for your password exactly once. Installing the configuration and bringing the tunnel up were two separate elevated steps, so one Connect click meant two prompts — and three or four while the macOS bug above was sending it round the retry path
• A failed connect still tells you which part failed: installing the configuration and bringing the interface up have separate messages, because the first is usually a declined prompt and the second is not
• Your WireGuard private key still never appears in a command line or in any elevated script — it travels in a file only you can read, and the single elevated step moves it into place

JM Net 1.2.1

• Fixes the tunnel that connects but carries no traffic on Linux: WireGuard does not manage your firewall, so with ufw active and the usual default-deny inbound policy the handshake succeeds and the decrypted packets are then dropped before any app sees them
• JM Net now allows the tunnel interface (ufw allow in on jmnet0) as part of the same elevated step as bringing the tunnel up — one authorization prompt, not two
• The rule is only added when ufw is active and the rule is genuinely missing; when ufw status cannot be read (it needs root) JM Net changes nothing rather than guessing about your firewall
• The rule allows traffic only on the JM Net interface, which WireGuard has already authenticated — it opens no port to the outside world — and if it cannot be added, your connection still goes through and you are told how to add it
• The installer, which runs without sudo and so never touches the firewall itself, now prints the exact command when it sees an active ufw with no rule for the tunnel

JM Net 1.2.0

• Fixes the tunnel that connects but carries no traffic on Linux: WireGuard does not manage your firewall, so with ufw active and the usual default-deny inbound policy the handshake succeeds and the decrypted packets are then dropped before any app sees them
• JM Net now allows the tunnel interface (ufw allow in on jmnet0) as part of the same elevated step as bringing the tunnel up — one authorization prompt, not two
• The rule is only added when ufw is active and the rule is genuinely missing; when ufw status cannot be read (it needs root) JM Net changes nothing rather than guessing about your firewall
• The rule allows traffic only on the JM Net interface, which WireGuard has already authenticated — it opens no port to the outside world — and if it cannot be added, your connection still goes through and you are told how to add it
• The installer, which runs without sudo and so never touches the firewall itself, now prints the exact command when it sees an active ufw with no rule for the tunnel

JM Net 1.1.0

• The status line now reflects a real WireGuard handshake, not just an interface that came up — a tunnel nothing is getting through says so, and names the likely cause (UDP 51821 blocked, or the hub endpoint unreachable)
• A stalled tunnel (no handshake for over three minutes) is reported as stalled instead of "Connected"
• When the server cannot be reached the tunnel is reported as unverified — never as connected, never as failed
• Uninstall now removes the WireGuard config and the app's state file, so it no longer leaves your private key and API token on disk — and reinstalling really does start fresh

JM Net 1.0.0

• Stable private addresses for every device you enroll
• Works behind NAT with no router configuration
• Private keys never leave your machine
• Routes only your private network, not your internet traffic