WireGuard on v7.25: Handshake active and internet routing works, but cannot access local RouterOS services (WebFig/WinBox) from Android client

RouterOS General
1

Hi everyone,

I am facing a very specific and stubborn issue with a newly configured WireGuard tunnel on my RB750Gr3 running RouterOS v7.25.

The setup:

  • The ISP modem is in Bridge mode (Static Public IP is directly on the MikroTik WAN interface).
  • The WireGuard client is a Samsung Galaxy S24 (Android) connected via mobile data (LTE/5G).
  • The WireGuard subnet has been isolated to 10.0.99.0/24 to avoid any overlapping with internal ISP or LAN subnets.

What works:

  1. Handshake is fully functional. The Last Handshake timestamp updates regularly in WinBox, and data counters are increasing on both sides.
  2. Internet routing through the tunnel works perfectly. When WireGuard is enabled on the phone with AllowedIPs = 0.0.0.0/0, I can browse external websites seamlessly (traffic is successfully hitting the forward chain and being masqueraded out to the WAN).

The Problem:
I absolutely cannot access the router itself

(neither via WebFig on http://10.0.99.1 nor via the MikroTik Mobile app) from the connected phone.

Diagnostic steps already taken:

  • Firewall Verification: The explicit input rule allowing WireGuard traffic on port 13231 is placed at the very top of the input chain (Index 0). The input chain also has a rule explicitly accepting all traffic where in-interface=wireguard1.
  • FastTrack & MTU: FastTrack bypass rules for the 10.0.99.0/24 subnet are placed directly above the main FastTrack rule. MTU has been manually lowered to 1280 on both the MikroTik interface and the Android app. MSS clamping rules are also active in the mangle table.
  • IP Services: Router services (www and winbox) have their allowed-addresses set to 0.0.0.0/0.
  • Packet Sniffer Analysis: When running Packet Sniffer on wireguard1 while trying to connect to http://10.0.99.1 from the phone, I can see both RX and TX packets. The router is receiving the request and transmitting the response back into the tunnel, but the client never establishes the connection (resulting in a timeout/blank page even in Incognito mode).

It feels like a routing loop or an encapsulation issue within RouterOS v7.25 when handing traffic over to local input services, or a silent drop related to how Android handles cellular IPv6/IPv4 transitions inside the tunnel.

Below are my current firewall and NAT exports. Any advice on what might be causing this local service lockout would be highly appreciated!

routeros

# Firewall Filter Export
/ip firewall filter
add action=accept chain=input comment="WireGuard: Eksplicitno dovoli vhod v usmerjevalnik" in-interface=wireguard1
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="allow WireGuard VPN" dst-port=13231 protocol=udp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
add action=accept chain=input comment="allow l2tp" dst-port=1701 protocol=udp
add action=accept chain=input comment="allow IKE" dst-port=500 protocol=udp
add action=accept chain=input comment="allow SSH s preverjanjem blacklista" dst-port=22 protocol=tcp src-address-list=!bruteforce_blacklist
add action=add-src-to-address-list address-list=bruteforce_blacklist address-list-timeout=1d chain=input comment="SSH Blacklist" connection-state=new dst-port=22 protocol=tcp src-address-list=connection3
add action=add-src-to-address-list address-list=connection3 address-list-timeout=1h chain=input comment="SSH Third attempt" connection-state=new dst-port=22 protocol=tcp src-address-list=connection2
add action=add-src-to-address-list address-list=connection2 address-list-timeout=15m chain=input comment="SSH Second attempt" connection-state=new dst-port=22 protocol=tcp src-address-list=connection1
add action=add-src-to-address-list address-list=connection1 address-list-timeout=5m chain=input comment="SSH First attempt" connection-state=new dst-port=22 protocol=tcp
add action=accept chain=input comment="WireGuard: Dovoli DNS usmerjevalnika (UDP)" dst-port=53 protocol=udp src-address=10.0.99.0/24
add action=accept chain=input comment="WireGuard: Dovoli DNS usmerjevalnika (TCP)" dst-port=53 protocol=tcp src-address=10.0.99.0/24
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=accept chain=forward comment="WireGuard: bypass FastTrack naprej" src-address=10.0.99.0/24
add action=accept chain=forward comment="WireGuard: bypass FastTrack nazaj" dst-address=10.0.99.0/24
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop bad forward IPs" src-address-list=no_forward_ipv4
add action=drop chain=forward comment="defconf: drop bad forward IPs" dst-address-list=no_forward_ipv4
add action=accept chain=forward comment="allow traffic from WireGuard VPN" in-interface=wireguard1
add action=jump chain=forward comment="Skok na DDoS detekcijo" connection-state=new jump-target=detect-ddos
add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddos-targets address-list-timeout=10m chain=detect-ddos
add action=add-src-to-address-list address-list=ddos-attackers address-list-timeout=10m chain=detect-ddos
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

# NAT Export
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade + ipsec awareness" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="Masquerade za WireGuard" src-address=10.0.99.0/24

# Mangle Export
/ip firewall mangle
add action=change-mss chain=forward comment="WireGuard: MSS Clamp v1" new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn src-address=10.0.99.0/24
add action=change-mss chain=forward comment="WireGuard: MSS Clamp v2" new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn dst-address=10.0.99.0/24

Thank you!

2

You are only showing part of your config but if I may make an educated guess:
Double check where that wireguard interface is being accepted as input in firewall rules.
Is that in-interface=wireguard1 the correct name ?

Or add it to LAN interface list which is what most do for a VPN which should be able to access the router itself.
I use an interface list VPN and add that as allowed in FW Input.

3

Internet through the tunnel only proves the forward path and NAT are working; WebFig and Winbox are served on the input chain, so successful browsing does not mean those local services are allowed. On the Android client, AllowedIPs must include the exact address you open: the router's WireGuard address, and also the router's LAN subnet if you target a LAN IP instead. On the router, that peer's allowed address must include the client's WireGuard address, or the decrypted request has no return path back into the tunnel. The input accept for the real WireGuard interface name has to sit above the drop for traffic that is not from the LAN list, and it must cover the www and Winbox ports you test, not only the UDP port used for the handshake. Compare a connection to the router's WireGuard IP with one to its LAN IP, because those are different destinations and only an address present on both the client AllowedIPs and the return route will answer. If a sniffer shows a reply leaving the WireGuard interface while the phone still times out, the phone is likely excluding that destination from the tunnel or the reply source is not an address the client will accept.

4

Hello, thank you for your efforts.
The reason was:"defconf: drop all not coming from LAN"

Grok found it, Gemini missed it.
Have a great day, everyone.