Hello!
I’m struggling getting hairpin to work with a Wireguard interface.
In the following attached routeros settings, everything is working as expected without the Wireguard interface: everyone gets access to the internet and everyone gets access to my web server (192.168.88.6) both for distant machines and for machines belonging to the same LAN as my web server (i.e. hairpin nat is working fine).
Then I add the Wireguard interface and I mangle one machine (192.168.88.5) and route it to the Wireguard interface. As expected, VPN internet access is granted to 192.168.88.5 but unfortunately, 192.168.88.5 doesn’t have access to my web server anymore.
Any clue what I should do to overcome this issue? MyFile.rsc (5.38 KB)
What is the purpose of Wireguard? Is it for your remote devices to access the router and LAN while away or are you connecting to some third party vpn to access internet somewhere else.??
Will assume the latter case!!
Fixes:
EDIT, nm this is okay
These rules make no sense
the first rule says → allow all LAN members to ALL router services
the second rule says → allow ALL internal and more dangerously ALL external users to use my routers DNS… DANGER DANGER
( you forgot to add at least in-interface-list=LAN on this rule )
the third rule allows only one admin IP to access the router for ALL SERVICES
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
add action=accept chain=input comment=“accept LAN DNS requests” dst-port=53
protocol=udp
add action=accept chain=input src-address-list=allowed_to_router
add action=drop chain=input
Change this too… add action=accept chain=input comment=“admin access” in-interface-list=LAN src-address-list=allowed_to_router
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=udp
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=tcp
add action=drop chain=input comment=“drop all else” { add this rule laste so you dont lock yourself out }
Only one hairpin nat rule is needed. add action=masquerade chain=srcnat comment=“Hairpin NAT” dst-address=192.168.88.0/24 src-address=192.168.88.0/24
REMOVE mangle, its too complex for a single address, instead use routing rules, the existing table is fine and the existing route is fine.
/routing rule
add action=lookup-only-in-table src-address=192.168.88.0/24 dst-address=192.168.88.0/24 table=maincomment=“allows LAN to LAN traffic”
add action=lookup-only-in-table src-address=192.168.88.5/32 table=vpn_mark
Missing one thing on wireguard peer settings /interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=... endpoint-port=XXX interface=“wg1” name=peer2 public-key=“-----” persistent-keep-alive=35s
For LAN users to reach the servers do they use LANIP address or a DYNDNS name ( like the ip cloud available mynetname.net ) ???
As per my recent post above, cat, was working on it this morning and got caught up doing other things…
I am avoiding using the prefix thing for several reasons.
a. there is a bug when you do modifications after the fact to the prefix rules that do not actually stick on the router ( what is shown is not what the router uses )
b. Its a simple one IP, and one subnet so the rule provided works very well.
c. the structure of the prefix rule and the explanation confounds a simple explanation of what it does or is supposed to do. I have not been able to explain it in several sentences to myself so not sure for new users its as useful. Its easy to understand that one can ensure all traffic from the single IP going out wireguard needs to be able to reach other LAN IPs and vice versa, out the main table, before all traffic from that IP ( originating traffic or reply traffic, to other LAN IPs) gets sucked out wireguard.
This can be accomplished in two ways /routing rule add action=lookup-only-in-table src-address=192.168.88.5/32 dst-address=192.168.88.0/24 table=main comment=“allows PC to LAN traffic”
add action=lookup-only-in-table dst-address=192.168.88.5/32 src-address=192.168.88.0/24 table=main comment=“allows LAN to PC traffic”
add action=lookup-only-in-table src-address=192.168.88.5/32 table=vpn_mark
OR ( the more simple ) add action=lookup-only-in-table src-address=192.168.88.0/24 dst-address=192.168.88.0/24 table=main comment="LAN to LAN traffic"add action=lookup-only-in-table src-address=192.168.88.5/32 table=vpn_mark
Thx to both of you. I tried cat suggestion which succeeded but the DNS who is now leaking for 192.168.88.5 connected to Wireguard (before these rules DNS was provided to 192.168.88.5 by Wireguard server and was not leaking).
Going to read anav post carefully and make some tries.
Can you confirm what the 3rd party provider gave you for information
Apparently besides endpoint address and endpoint port and private key to use ( so same public key is generated for their end etc…)
Specifically ip address of 100.96.1.09 was given, DID they provide anything else? I see you have network entered of same address so presumably they gave you that as well.
Did they provide a DNS address or anything else ???
Yes, besides 100.96.1.09, they give DNS address: 198.18.0.1,198.18.0.2
I have no clue where to put these DNS address on Mikrotik router (I’m using 8.8.8.8 for the regular traffic). But I observed that with my original config with mangle, the machine routed to wg1 was requesting the DNS to the router which itself was requesting DNS through wg1 also (DNS leak tests were giving wg endpoint address). Then even though I didn’t mention 198.18.0.1 anywhere, the DNS requesting was not leaking to google.
To prevent leaking is difficult as the rest of the router goes out the normal local WAN.
To accomplish no leaking try this… Option1: If 3rd party provided a DNS address to use… /ip nat
add chain=dstnat action=dstnat src-address=192.168.88.5 dst-port=53 protocol=udp to-address=198.18.0.1
add chain=dstnat action=dstnat src-address=192.168.88.5 dst-port=53 protocol=tcp to-address=198.18.0.1
By the way you should add the following mangle rule for potential MTU browsing issues… /ip firewall mangle
add action=change-mss chain=forward comment=“Clamp MSS to PMTU for Outgoing packets” new-mss=clamp-to-pmtu out-interface=“wg1” passthrough=yes protocol=tcp tcp-flags=syn****
Because its a function of ensuring the path through the 3rdparty provider from the single PC to the Www is working properly MTU wise. Nothing to do with bridge.
Also note an improvement on the schema already provided:\
I have actually multiple machines on my LAN and was thinking about the possibility to activate/deactivate some of them at will, easily. I will look at it further. Thx a lot for your help.
Note: Routing rules works well for a small group of IPs… or entire subnets,
however if the number grows to big, then mangling will be used to replace routing rules.