AstroWarp IP leak when switching P2P on/off

Cloud Services
1

Hi everyone,

I've been using AstroWarp for a while now and generally it works pretty well, but I've noticed something concerning when switching P2P on and off.

My setup is:

  • GL-MT3000 (4.11.0) in my camper, connected to Starlink Mini

  • GL-MT2500 (4.8.2 beta) at home in Poland, connected to Orange

  • All traffic from the camper goes through my home connection using AstroWarp

The problem is that whenever I toggle P2P on or off in the AstroWarp web portal, my public IP briefly changes from my home IP to the Starlink IP.

I tested this by continuously checking my public IP from a MacBook connected to the MT3000. It happens in both directions (P2P on → off and off → on), and the Starlink IP is visible for around 6–7 seconds before traffic starts going through my home connection again.

What worries me is that the internet doesn't simply stop working during those few seconds. Traffic actually goes out through Starlink instead of being blocked.

I'm not sure whether manually toggling P2P causes the tunnel to restart completely, so I don't know if the same thing happens during automatic P2P/relay failover.

Has anyone tested this, or does anyone from GL.iNet know whether automatic failover can cause the same IP leak?

I also noticed that switching P2P resets my custom MTU on mptun0 back to the default. I normally use 1320–1340 because I'm running another VPN for work on top of AstroWarp, and the default MTU causes connectivity issues.

There's also a strange DNS issue. When I enable "Override DNS Settings of All Clients" on the MT3000, I can't access my.astrowarp.net, and GoodCloud sometimes shows the router as offline even though the tunnel itself is still working. Disabling that option fixes it. DNS leak tests with it disabled show my home ISP's DNS servers, so it seems fine during normal operation, but I'm not sure what happens during reconnection.

I've checked the router over SSH and the active tunnel is mptun0. I also have aw-s2s, gl-sdk4-ui-goodpas and AmneziaWG packages installed, but since I'm managing the connection through my.astrowarp.net, I assume I'm still using the older AstroWarp implementation.

I'm considering switching to the newer GoodPAS, but before doing that I'd really like to know:

  • Does GoodPAS have a proper kill switch that blocks internet access if the tunnel drops or switches between P2P and relay, rather than falling back to the local WAN?

  • Is automatic failover in the older AstroWarp affected by the same issue I see when manually toggling P2P?

  • Is the new integrated AstroWarp/GoodPAS available on the GL-MT2500 with firmware 4.9.0 beta?

  • Is there a way to keep a custom MTU after the tunnel reconnects?

My main concern is preventing any traffic from leaking through Starlink. I'd much rather lose internet access for a few seconds than have my real WAN IP exposed.

The MT2500 is also located remotely, so I'd prefer to avoid upgrading it unless I'm sure the newer firmware supports GoodPAS and the migration is reasonably safe.

Has anyone dealt with something similar?

Thanks!

4

Hi, thank you for your testing and detailed feedback.

  • AstroWarp and GoodPAS do not provide a dedicated Kill Switch feature. Changing the P2P setting in the AstroWarp web portal restarts the relevant interfaces and services, during which traffic may briefly use the local WAN connection.

  • Regarding MTU, the tunnel is recreated using the cloud-managed configuration, which overwrites local changes made to the running interface.

  • For the DNS issue, as a temporary workaround, please note your current DNS settings, select Automatic DNS on the MT3000, and then run the following commands over SSH.

if [ "$(readlink /tmp/dnsmasq.d/mptun_policy)" = "/tmp/dnsmasq.d.mptun/mptun_policy" ]; then
    rm /tmp/dnsmasq.d/mptun_policy
    /etc/init.d/dnsmasq restart
fi

The link may be recreated when the AstroWarp tunnel is rebuilt, so this workaround may need to be reapplied.

  • The GL-MT2500 with firmware 4.9.0 beta supports the integrated AstroWarp feature in the router’s web admin panel and can pair with an MT3000 using the corresponding integrated feature. This setup also does not support Kill Switch.
    image
    image1022×745 32.5 KB

We will share these findings and test results with the relevant team for further evaluation. Thank you for your patience and understanding.

5

Thanks for the reply!

Just wanted to clarify one thing about the IP leaks. I understand that manually switching P2P on/off restarts the tunnel and may cause traffic to briefly go through the local WAN.

But what about automatic failover between P2P and Relay? Does that work differently, or is there still a risk of leaking the local IP?

I actually tested this by temporarily blocking the P2P connection. AstroWarp switched to Relay automatically, and after removing the block, it eventually switched back to P2P.

During the whole test, I was monitoring my public IP from a MacBook connected to the MT3000. I saw some timeouts, but never my Starlink IP only my Polish exit IP.

So I'm curious whether automatic failover is safer than manually toggling P2P, or if I just got lucky with my tests :wink:

And one more thing, since AstroWarp doesn't have a built-in kill switch, is there a way to set one up manually on the MT3000 without interfering with AstroWarp?

Basically, I want to make sure that if the tunnel goes down or switches between P2P and Relay, my devices either use the VPN or have no internet at all. I'm perfectly fine with losing connectivity for a while.

I was thinking about firewall rules, but since AstroWarp manages its own interfaces and routing, I don't want to accidentally break something.

Is there a particular place or method you'd recommend for setting this up so it survives tunnel restarts and doesn't conflict with AstroWarp?

Thanks again for looking into this!