Wireguard server on MT - my client have internet access but cannot access to LAN (shared folders) edit:SOLVED

Hello!

Like the Topic subject says, I’ve created Wireguard server on MT and it seems ok (peer - my iPhone is active and it has internet access but cannot access to LAN (Mac mini shared folders which is on local netvork)

May I ask for help, please! What I’m missing to configure? Here below is my config.

PS

When I disconnect from WG on iPhone and connect normaly via Wi-Fi, I am able to access those folders without any issues.

very basic config (just accepted after reset) + wireguard setup, WAN is on ether1 port

# 2025-10-02 23:30:59 by RouterOS 7.20
# software id = ------------
#
# model = RB760iGS
# serial number = --------------
/interface bridge
add admin-mac=74:4D:28:BE:5A:36 auto-mac=no comment=defconf name=bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=wg1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp interface=bridge name=defconf
/disk settings
set auto-media-interface=bridge auto-media-sharing=yes auto-smb-sharing=yes
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface wireguard peers
add allowed-address=192.168.90.10/32 client-address=192.168.90.10/32 \
    client-dns=8.8.8.8 client-endpoint=185.166.252.101 endpoint-port=13231 \
    interface=wg1 name=wg1-user1 persistent-keepalive=25s private-key=\
    "--------------------------" public-key=\
    "--------------------------------"
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
add address=192.168.90.1/24 interface=wg1 network=192.168.90.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input comment=Wireguard dst-port=13231 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
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=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=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
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 all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" \
    dst-port=33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack6" \
    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 packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/-----------
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

When the tunnel is active, the iPhone won't be able to automatically discover the Mac Mini and its shared folders (it's in a different subnet and multicast and broadcast do not work over WG). You'll need to manually enter the IP address.


Unrelated but if the iPhone is a road warrior device, then on the router don't set persistent-keepalive on the peer associated with it.

You can also add wg1 to the interface list LAN if you want the peers to be able to access the router resources like DNS or WinBox.

Thank you very much! It actualy works!

The thing is that I tried to acces to Mac mini with its local name (macmini.local).

I entered its local IP now (i/e of macmini.local) and iPhone connects to it! SOLUTION

persistant-keepalive removed

wg1 added to LAN interfacelist and I’m also able now to use winbox on my iPhone to connect to Mikrotik

Aditional newbie question - If I move IP filter rule for wg1 more to the bottom (below fasttrack rules) will it have any influene on the speed? Or must this rule be above “drop invalid” rule? Thanks!

Do you mean this rule?

/ip firewall filter
add action=accept chain=input comment=Wireguard dst-port=13231 protocol=udp

The rule is in the input chain, which is a separate from the forward chain where the fasttrack-connection rule is located. The relative position of the WG rule is not relevant to the position of the Fasttrack rule.

However, among the rules of the input chain, the order is important. The rule that will be hit with the most traffic on the input chain is this rule:

/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked

Which means you should try to keep it at the top of the chain. You can move the WG rule down, right below the

/ip firewall filter
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid

rule of the input chain (not the one of the forward chain) and it will be fine.

Yes, this requires working mDNS, which needs multicast. While recent versions of RouterOS has a mDNS-proxy feature, it's not usable with the WG tunnel.

I moved Wireguard rule like you said. It works.

That’ good enough for me. Thank you!

However, if you have time, I’m just trying to figure out logic; I check the statistic of this wireguard filter rule, and NO traffic counting. The rule that you wrote that will hit the most of traffic indeed counting traffic. Why is that?

Off-topic; I would like to move now to step 2 - create / isolate my IoT devices to separate VLAN. Should I open another forum topis or is it okay if I ask here? (The question is actually how to isolate / move IoT devices to VLAN when the scenario is that I have multiple “dumb” wireless AP’s and switches and it is not possible to assign any specific port to this VLAN. (I would like somehow manually move devices in VLAN I will create)

The rule that accept packets coming to the router with destination port 13231 will only be hit for the very first packet of the "connection". UDP has no real connection like TCP, but in case of the Linux firewall and RouterOS, UDP packets

  • Coming from source IP address A, source UDP port B to destination IP address C, destination UDP port D
  • And those coming from source IP address C, source UDP port D to destination IP address A, destination UDP port B

will all be tracked as part of the same UDP "connection" if the time gap to the previous packet is not long (the UDP timeout).

So, when you use your iPhone and turn on the WG tunnel, the phone will send a handshake UDP packet to the port of the router. Assuming that the phone has previously not contacted this port on the router, or the last contact was long ago (longer than the UDP timeout setting), this packet will be treated as the first packet of a new "connection" and a conntrack (connection tracking) entry will be created (that you can see in the IP -> Firewall -> Connections, or IPv6 -> Firewall -> Connections, table).

The connection at this time has the state "new", so the packet has the connection-state=new property. The packet will be checked by the rules on the input chain of the filter table, from top to bottom. Because it has connection-state=new, it will not match the "defconf: accept established,related,untracked" rule or the "defconf: drop invalid" rule, and will arrive to the rule that accepts UDP packet sent to port 13231. This is when the counter of this rule is incremented.

When WG on the router sends the response packet, the source address / source port and destination address / destination port pairs of the packet will be swapped compare to the initial packet. And because the router send this response packet almost immediately, the UDP timeout has not been reached, the packet will be tracked as part of the same conntrack entry as the previous packet. But this time it has connection-state=established, and is on the output chain, not the input chain, so no counters are incremented.

Next your phone will send more packets to that WG port on the router, because not much time has elapsed, all these packets will still be associated with the previous conntrack entry. And because of that they all have connection-state=established. They still arrive on the input chain, but this time, the "defconf: accept established,related,untracked" rule with match with them, and accept them, skipping the rest of the firewall rules.

That continues until you close the WG on your phone. Your phone will stop sending UDP packets to that WG port on the router. And after a while, the timeout elapses, and the conntrack entry will be removed. The next time the WG app on your phone send something to the router, it will cause a new conntrack entry to be created.

So we can see that the accept WG rule will only be hit once per tracked connection, and the counter incremented once, until the connection is removed. All the rest of the traffic are packets with connection-state=established. You have no rules on the output chain so you'll se no counters for packets that the router sends to the WG app on the phone, but the "defconf: accept established,related,untracked" of the input chain will count all but one packets that the phone sends to the router for the duration of that "connection" session.

And it's also the reason why the "defconf: accept established,related,untracked" rule (also on chain forward) should be placed as high as possible (but on the forward chain below the fasttrack rule). This has the effect that for the vast majority of the traffic packets, only one rule needs to be checked, and all the other filtering rules down below only have to work on the very first packet of each connections, instead of repeatedly working on every single packet.

It's probably better that you create a separate topic, so that others on the forum can also chime in.

1 Like

read this for starters, then post in a new topic.....

1 Like