Hello everyone.
My router has dhcp wan connection, 1 ether port with client. All i want to do is to route all traffic to VPN.
I tried multiple guides from like a dozen similar questions but cant make all my traffic route throught the wireguard tunnel: it is either shows real ip or dont have internet access at all.
I’m connecting to private server. Got another router (Unifi) which uses same config without troubles - im mentioning this as a proof that server itself is working.
I tried mangle without routing rule first - no luck. Now i tried only routing rule - it shows my real ip.
The reason I state this is because your router FIRST has to establish the tunnel with the other end… then wireguard traffic can flow.
If there is no route, then the tunnel will never happen…
Since you are getting internet locally it must exist..
…
Very strange indeed.
So you confirm the following
a. ip dhcp client has default route=yes?
b. with RRules disabled and mangle disabled you go out the local internet (local WAN) no problem?
c. while testing b, please attempt to ping the remote address you have entered in 1 below !!!
Assuming yes to these then we have to assume there is a problem with wireguard settings next. LOCAL MT /ip wireguard peer settings
1 - is the endpoint address correct to reach the other side?
2 - is the endpoint port correctly assigned ( matches listening port on other end )
3 - is the public key generated by the other side correctly copied to the MT device
OTHER END
4 - Does the listening port match the entry in the peer settings found in 2 above.
5 - Does the device have an input chain 'Like" rule to allow incoming wireguard traffic
6 - is the public key generated by the MT device (when creating the tunnel initially) correctly copied to this device
Yes, i do confirm
a. ip dhcp client has default route=yes - YES
b. with RRules disabled and mangle disabled you go out the local internet (local WAN) no problem? - YES
c. while testing b, please attempt to ping the remote address you have entered in 1 below !!! Yes, can ping WG server IP from MT and cant ping from local machine.
1 - is the endpoint address correct to reach the other side? Yes
2 - is the endpoint port correctly assigned ( matches listening port on other end ) Yes
3 - is the public key generated by the other side correctly copied to the MT device Yes. In case i mess up with a key, i get error in UI saying that key is invalid.
4 - Does the listening port match the entry in the peer settings found in 2 above. Yes, same settings work on other device.
5 - Does the device have an input chain 'Like" rule to allow incoming wireguard traffic Yes
6 - is the public key generated by the MT device (when creating the tunnel initially) correctly copied to this device Yes
I checked and double checked everything, recreated WG profiles and rules. Here is my current config:
The concept is…to be clear, that the traffic from the router has to have one SOURCE IP to a third party server … that way the third party server does not have to anticipate and handle incoming traffic that is not the prescribed wireguard IP of the source. Critical in 3rdparty Wireguard VPN servers that provide a single IP. A private server under ones control does not require this move, unless it helps simplify matters. How is this accomplished.
EASY
By the OPs current rule. add action=masquerade chain=srcnat out-interface=wireguard1
The main reason you sometimes see the wg interface added to the WAN, is to ACHIEVE the same effect since the default sourcenat rule is add chain=srcnat action=masquerade out–interface-list=WAN
Hence if you make the wg interface part of the WAN interface list, the same effect of one wg IP arriving at destination is the result.
The reason this is done for third party servers, preferentially over the method used by the OP, is because there is no return traffic!!!
However he is connecting to a private Server and thus likely there may be traffic BACK to this router and probably the admin via the SERVER to configure this router or to access subnets or perhaps to even access the internet and thus LAN interface list is actually a more logical choice.
You can remove this rule in the input chain, wireguard traffic for handshake is outbound TO server, not inbound!!! add action=accept chain=input comment=“WG HANDSHAKE” dst-port=13231 protocol=udp
not a fan of your firewall rules but will just reorder them for easy reading and add one rule.
/ip firewall filter
add action=accept chain=input connection-state=established,related
add action=drop chain=input connection-state=invalid add action=accept chain=input protocol=icmp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment=“Drop all else” { ensure you put this rule in last }
++++++++++++++++++++++++++++++
add action=fasttrack-connection chain=forward connection-state=
established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=bridge1 src-address=
192.168.188.0/24
add action=accept chain=input in-interface=bridge1 src-address=
192.168.188.0/24
add action=drop chain=forward in-interface=!bridge1 add action=accept chain=forward comment=“local internet access” in-interface-list=LAN out-interface-list=WAN { disabled =yes if you DONT want users going out local WAN)
add action=accept chain=forward comment=“wireguard acess” src-address=192.168.88.0/24 out-interface=wireguard1
add action=drop chain=forward comment=“drop all else”
DISCUSSION:
The rule in orange is removed as its a duplicate and obvious when you have rules ordered properly
add action=drop chain=input in-interface=!bridge1
add action=accept chain=input in-interface=bridge1 src-address=
192.168.188.0/24
The second rule is not needed as you are already allowing it by the first rule. The first rule states block any traffic TO the router except bridge1 traffic.
Since the subnet address is the bridge address its rather silly.
The normal way to do this, is the following (clear, concise) add action=accept chain=input in-interface-list=LAN
and then after that is in place put add action=drop chain=input comment=“drop all else”
Now in the forward chain I see what you have done, wide open rules…again, no need.
There are not other subnets on the router and they only need to be allowed to wireguard if pushed out that way.
The rules in place are not that clear and are very non-standard (but not wrong). add action=accept chain=forward in-interface=bridge1 src-address=
192.168.188.0/24
add action=accept chain=input in-interface=bridge1 src-address=
192.168.188.0/24
add action=drop chain=forward in-interface=!bridge1
BETTER imho. add action=accept chain=forward comment=“local internet access” in-interface-list=LAN out-interface-list=WAN disabled =yes { assuming no local WAN allowed }
add action=accept chain=forward comment=“wireguard access” src-address=192.168.88.0/24 out-interface=wireguard1
add action=drop chain=forward comment=“drop all else”
What is the purpose of this rule???
Perhaps disable for testing purposes? Not sure if works thru wg ?? /ip nat-pmp
set enabled=yes
Same same with this rule, purpose, not sure will work thru wg>> disable for now /ip upnp
set enabled=yes
Anav, thanks so much for your help. I followed your guideline, changed everything as you suggested. Btw my firewall rules are mostly from other similar posts so i dont mind changing any and all of them
Current status: no connection to wan or wg from local machine, router still pings remote server easily.
Here’s update cfg
I suspect an issue with DNS and so lets try some things…before I get there some more work required on firewall rules.
You need access as admin to the router so we need to add that to the input chain rules.
To do this the easiest method is to identify the admins devices on the network wired and wifi.]
Go to DHCP leases and make those devices leases STATIC/fixed.
We should also add any of your devices using wireguard when remote and away from the router (laptop/iphone etc..)
and then add the rule to your input chain…not sure how you access it now as according to the rules there should be no access LOL /ip firewall filter add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=icmp
add action=accept chain=input comment=“admin access” src-address-list=AUTHORIZED add action=drop chain=input
FORWARD CHAIN, you have the first rule out of place needs to be properly placed in order and get rid of the useless rules NOISE, vice disable.
We might not even need the rule to allow the lan subnet out wireguard because we have the rule above that allowing LAN to WAN interfaces
and since WG is part of WAN interface list, its is already allowed to hit the wireguard interface…
Once we have it up and running we can add a log rule to the second rule and if not hits, confirm our logic and then can remove the presumably extra rule.
MODIFY IP DNS TO ( remove remote requests ) ALSO find out what dns servers are in use at the private server !!!1 /ip dns set servers=8.8.8.8,8.8.4.4,1.1.1.1
Okay, done. Doesnt work.
8.8.8.8 and 8.8.4.4 - are server dns.
and i access router via mac address, didnt have problem with it.
Also fixed one typo: add action=accept chain=forward comment=“wireguard access” out-interface=
wireguard1 src-address=192.168.188.0/24
I see a problem with thid part:
At some point, Mikrotik has added the min-prefix parameter to routing rules, but the explanation in Mikrotik manual just refers to the name of the feature as used in general Linux, and references I could find are also not very verbose regarding “side effects” (putting that in quotes as those effects may actually be intended).
What the first rule actually says is: if there is any route in table main that matches the destination address of the packet better than the default one, use that table for the packet. Otherwise, skip to the next rule. So the handshake packet the router itself sends to the address of the Wireguard server definitely will skip to the next rule. The next rule matches on src-address=192.168.188.0/24 so that handshake packet will skip it too as its address is the WAN one. And here comes the question - is routing table main still the default/falback choice even though the first rule has already acted and its action was not just lookup (which permits fallback) but lookup-only-in-table? Before I can test that here, I suggest you add a third routing rule that says just action=lookup-only-in-table table=main (without min-prefix) and see whether that helps.
Hi Sindy since order is specific, should it be… /routing rule add action=lookup-only-in-table table=main
add action=lookup-only-in-table min-prefix=0 table=main disabled=yes { disabled as to test your thinking }
add action=lookup-only-in-table src-address=192.168.188.0/24 table=rtab-wg
