Wireguard configuration

Kamaz · Sat Jul 16, 2022 6:57 pm

Hi there.
I have a VPS running WireGuard server. And it's possible to connect there from my Windows PC using WireGuard client. All traffic is going through my Wireguard server. That's ok. And my first goal.
But the problem is in fact, that I can't redirect all traffic from my network via Mikrotik via VPS. Mikrotik acts as WireGuard client.

Server config:

[Interface]
Address = 10.8.0.1/24
SaveConfig = true
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = iptables -D FORWARD -i wg0 -j ACCEPT
ListenPort = 443
PrivateKey = server's_private_key

Windows client 1 config:

[Interface]
PrivateKey = windows_private_key
Address = 10.8.0.10/24

[Peer]
PublicKey = server_publick_key
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = server_external_ip:443
PersistentKeepalive = 10

Windows client 2 config:

[Interface]
PrivateKey = windows_private_key
Address = 10.8.0.11/24

[Peer]
PublicKey = server_public_key
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = server_external_ip:443
PersistentKeepalive = 10

Mikrotik configuration:

/interface/wireguard add listen-port=443 name=WG_to_VPS
/interface/wireguard print
/ip/address add address=10.8.0.2/32 interface=WG_to_VPS
/interface/wireguard/peers
add allowed-address=0.0.0.0/0 endpoint-address=server_ip:443 endpoint-port=443 interface=WG_to_VPS \
public-key="server_public_key"

What I want:
1) Redirect traffic for all WireGuard clients via my VPS server. For now it works for Windows and Android clients. Done.
2) To be able to connect from one Wireguard client to another. Ping is going between Windows 1 and 2 client fine. For Android <> Windows it also works. But between Windows <> Mikrotik no connection.
3) Redirect all traffic from my Mikrotik's LAN network via VPS. Not working.
4) To be able to reach from Windows/Android wireguard clients, inner resources behind Mikrotik. For example from 192.168.33.10 or 10.8.0.30 I want to connect to 192.168.33.10. Not working.

I hope that my explanations were correct and you understand my needs. Also attached schema on the network.

own3r1138 · Sat Jul 16, 2022 8:27 pm

1, 2, 3, and 4 viewtopic.php?t=182340
3
viewtopic.php?t=182072

Kamaz · Sun Jul 17, 2022 2:37 am

1, 2, 3, and 4 viewtopic.php?t=182340
3
viewtopic.php?t=182072

Hi. Thank you for useful links, I'll read them tomorrow.

Here is a small update:
1) Was done.
2) One missed route for Mikrotik. Fixed, done.
3) Working on that.
4) srcnat + port forwarding on Mikrotik. That's enough for my needs. Done.

anav · Sun Jul 17, 2022 3:26 pm

(1) The IP address for the mikrotik client should be as follows:
/ip/address add address=10.8.0.2/24 interface=WG_to_VPS

the windows clients being single entities should be /32

(2) Assuming you want the MT Client router to provide/force VPS internet for MT client users - hence the 0.0.0.0/0 allowed IPs?

(3) Missing "persistant" keep alive on MT client?

(4) Without showing the current firewall rules and IP routes, no further observations can be made.

(a.) In general (since I use drop all rules at end of chain) you can add something like this to give your wg pc users access to MT router subnets.......
add chain=forward action=accept in-interface=WG_interface_name out-interface-list=LAN

YOu can be more specific as the need entails
add chain=forward action=accept in-interface=WG src-address=10.8.0.10/32 dst-address=SubnetA_device_IP { to a single device }
add chain-forward action=accept in-inteface=WG src-address=10.8.0.11/32 dst-address=SubnetB { to a whole subnet }
etc........

(b.) In terms of IP routes for the incoming remote traffic, this should be handled by the fact that they are included within the IP address configuration of the Router (make sure you change that /32 to the proper /24 on the MT Router). In other words the router will create a route automatically for this traffic <DAC> dst-address=10.8.0.0/24 gateway=WG_interface-name table=main.

In terms of the above, the allowed IPs lets the pc user traffic exit the wg tunnel at the MT device, the firewall rules permit that traffic to go where it needs to go (as controlled by the admin), and the return traffic has a path back to the wireguard interface and will re-enter the tunnel.

(5) The originating outbound traffic (for local users to use VPS internet) is a tad more complicated. The allowed IPs of 0.0.0.0/0 ensures all internet queries will be permitted if they reach the tunnel.
The issue is how to ensure all traffic reaches the tunnel.

Typically this can be done with IP routes and rules etc......
Since its all traffic, then identify the entire subnet.........
/routing table fib add name=use-WG
/routing rule src-address=192.168.33.0/24 action=lookup-only-in-table table=use-WG
/ip route
dst-address=0.0.0.0/0 gwy=wg-interface-name table=use-WG

If you want the users to be able to access local internet if the VPS internet is not available simply change the action to action=lookup

Kamaz · Mon Jul 18, 2022 10:46 pm

(1) The IP address for the mikrotik client should be as follows:
/ip/address add address=10.8.0.2/24 interface=WG_to_VPS

the windows clients being single entities should be /32

(2) Assuming you want the MT Client router to provide/force VPS internet for MT client users - hence the 0.0.0.0/0 allowed IPs?

(3) Missing "persistant" keep alive on MT client?

(4) Without showing the current firewall rules and IP routes, no further observations can be made.

(a.) In general (since I use drop all rules at end of chain) you can add something like this to give your wg pc users access to MT router subnets.......
add chain=forward action=accept in-interface=WG_interface_name out-interface-list=LAN

YOu can be more specific as the need entails
add chain=forward action=accept in-interface=WG src-address=10.8.0.10/32 dst-address=SubnetA_device_IP { to a single device }
add chain-forward action=accept in-inteface=WG src-address=10.8.0.11/32 dst-address=SubnetB { to a whole subnet }
etc........

(b.) In terms of IP routes for the incoming remote traffic, this should be handled by the fact that they are included within the IP address configuration of the Router (make sure you change that /32 to the proper /24 on the MT Router). In other words the router will create a route automatically for this traffic <DAC> dst-address=10.8.0.0/24 gateway=WG_interface-name table=main.

In terms of the above, the allowed IPs lets the pc user traffic exit the wg tunnel at the MT device, the firewall rules permit that traffic to go where it needs to go (as controlled by the admin), and the return traffic has a path back to the wireguard interface and will re-enter the tunnel.

(5) The originating outbound traffic (for local users to use VPS internet) is a tad more complicated. The allowed IPs of 0.0.0.0/0 ensures all internet queries will be permitted if they reach the tunnel.
The issue is how to ensure all traffic reaches the tunnel.

Typically this can be done with IP routes and rules etc......
Since its all traffic, then identify the entire subnet.........
/routing table fib add name=use-WG
/routing rule src-address=192.168.33.0/24 action=lookup-only-in-table table=use-WG
/ip route
dst-address=0.0.0.0/0 gwy=wg-interface-name table=use-WG

If you want the users to be able to access local internet if the VPS internet is not available simply change the action to action=lookup

1) FIxed
2) Yes, you are totally right. I want to force all traffic from MT clients (2 PC or whole subnet) to Internet via wireguard VPN tunnel and via VPS server.
3) My bad, there is keepalive in my configuration = 10
4) Thank you for the brief explanation!!!
5) The error appeared while routing table creation

/routing table fib add name=use-WG-table
bad command name fib (line 1 column 16)

 /routing/table/print 
Flags: D - dynamic; X - disabled, I - invalid; U - used 
 0 D   name="main" fib

anav · Mon Jul 18, 2022 11:23 pm

Yeah that is my mistake, the fib needs to come after the add. SO

/routing table add fib name=xxxxxxx OR
/routing table add name=xxxxxx fib

Kamaz · Tue Jul 19, 2022 5:34 pm

Yeah that is my mistake, the fib needs to come after the add. SO

/routing table add fib name=xxxxxxx OR
/routing table add name=xxxxxx fib

Hi.
Here is the commands I used

/routing table add name=use-WG-table fib
/routing rule add src-address=192.168.33.0/24 action=lookup table=use-WG-table
/ip route add dst-address=0.0.0.0/0 gateway=WG_to_VPS routing-table=use-WG-table

but now I can't ping or connect from one PC to another or from PC to router (have to use MAC connection) after adding last route.
Here is my config. Could you please take a look?

Thanks in advance.

anav · Tue Jul 19, 2022 7:38 pm

(1) The first thing I would do is get rid of this rule.
Its an advanced rule that is rarely used.......... The standard IP firewall rules suffice for 98% of configs.

/interface bridge settings
set use-ip-firewall=yes

(2) The second thing I would get rid of is IP filter strict...................... its use is definitely not compatible with dual wans and again, rarely used.
/ip settings
set rp-filter=strict

If you are concerned about optimizing the default rule set especially this rule.........
add action=drop chain=input comment="Drop invalid input packets" \
connection-state=invalid

Then ensure that you go to IP Firewall menu selection, choose the Connections Tab, and find the Tracking sub tab/button (second line).
Then ensure connection tracking is set to auto and the checkbox for LOOSE TRACKING is NOT SELECTED, which means it will be set for strict tracking.

(3) Your firewall rules are out of control IMHO. Also disorganized as you mix forward chain and input chains together. My recommendation is to simplify.
ex. look at last two rules you have...... a symptom of a shit show......
add action=drop chain=input comment="defconf: drop all from WAN" \
in-interface=ether1-WAN
add action=drop chain=forward comment="defconf: drop all from WAN" \
in-interface=ether1-WAN

90% of your rules I would throw in the toilet, not even sure what L2TP brute force protection is about? If you are using an insecure VPN such as PPP, dont use that type of VPN. I would focus on
a. actual required rules first in an organized fashion.
b. add rules for better security as required
---> what is SSH used for and by whom?
---> are you running any servers that require extra security?
---> what issues have you had in the past that drove you to this extreme?

(4) Now lets focus on wireguard

a. why are you using port 443 for wireguard ?? 443 is a port used for protocol HTTPS traffic?
Suggest you change it.

b. I dont understand your masquerade rules.....................
Lets take a look at the first two:
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
out-interface=ether1-WAN
add action=masquerade chain=srcnat comment="LAN > WG" out-interface=WG_to_VPS

When viewed in conjunction with an interface list member you have.
add interface=WG_to_VPS list=WAN

This means that any traffic heading out the tunnel will be given the IP address of the interface 10.8.0.2
So what is the point of the second rule???
Finally, do you really need to masquerade your traffic heading out of the tunnel??
You control the VPS correct? If so, then you dont have to masquerade your LAN traffic from the MT to the VPS?
All you need to do is ensure the subnets are identified as allowed IPs on the VPS for the MT client peer settings on the VPS
addresses=10.8.0.2/32, subnetA, subnetB etc.........

I mean its personal choice, as long as you understand what you are doing to the traffic, either way works but at least get rid of the second rule.

++++++++++++++++++++

I have no clue as to what is intended by the next two rules.......
Can you please explain what is being accomplished here in some detail??

add action=netmap chain=dstnat comment="WG > PC1 RDP" dst-port=40001 \
in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.2 to-ports=\
3389
add action=netmap chain=dstnat comment="WG > PC2 RDP" dst-port=40002 \
in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.3 to-ports=\
3389

c. Since you dont have drop all rules that I can see and the firewall is too messy I will assume there is nothing blocking LAN to WG interface traffic.

d. Whats left is routes. All I see is disabled routes............ ???

Thus what you should have currently in your IP Tables, which is not shown in the config.........
<AS> dst-address=0.0.0.0/0 gateway=ISPgateway_IP table=main
<DAC> dst-address=192.168.33.0/24 gateway=bridge1 table=main

You have currently created the required components for WG.
/routing rule
add action=lookup src-address=192.168.33.0/24 table=use-WG-table
/routing table
add fib name=use-WG-table

Now you have to add the IP route ( i see its there but disabled, so just enable it! )
/ip route
add dst-address=0.0.0.0/0 gateway=WG_to_VPS table=use-WG-table

Now lets look at the logic,
All traffic coming from the LAN is captured and sent out WG, so to ensure we dont inadvertently do that for LAN to LAN traffic, add a another route rule ORDER IS KEY SUCH THAT..

/routing rule
add action=lookup-only-in-table dst-address=192.168.33.0/24 table=main
add action=lookup src-address=192.168.33.0/24 table=use-WG-table

Another option is that we could also simply add another route manually similar to the DAC route and create the same route on the other table (VS_to_WG)
/ip route
add dst-address=192.68.33.0/24 gateway=bridge1 table=WG_to VS

anav · Tue Jul 19, 2022 8:21 pm

So lets talk about what you are using
L2TP VPN with PPP for ????
SSH for ???

You are using wireguard and it appears RDP over wireguard which is much better than RDP by itself!!!

Kamaz · Wed Jul 20, 2022 1:13 am

/interface bridge settings
set use-ip-firewall=yes

(2) The second thing I would get rid of is IP filter strict...................... its use is definitely not compatible with dual wans and again, rarely used.
/ip settings
set rp-filter=strict

Done, both disabled.

LOOSE TRACKING is NOT SELECTED

Done.

ex. look at last two rules you have...... a symptom of a shit show......
add action=drop chain=input comment="defconf: drop all from WAN" \
in-interface=ether1-WAN
add action=drop chain=forward comment="defconf: drop all from WAN" \
in-interface=ether1-WAN

But why? This is the default configuration like "allow everything you need and block other thing at the end of chain".

Your firewall rules are out of control IMHO. Also disorganized as you mix forward chain and input chains together.

I agree that there are a loooot of rules but they organized by the action they do. I tried to use comments for that.
And from my perspective it looks not so terrible in Winbox (see attached screenshots)

not even sure what L2TP brute force protection is about?

- Couple month ago there was an L2TP/IPsec server on that MT. And that list of rules/scripts was created for L2TP protection because of the amount of brutforce attempts.

---> what is SSH used for and by whom?
---> are you running any servers that require extra security?
---> what issues have you had in the past that drove you to this extreme?

---> SSH is only a spare channel to configure that MT.
---> Nope.
---> I was looking for ways to secure my MT and that's it.

a. why are you using port 443 for wireguard ?? 443 is a port used for protocol HTTPS traffic?
Suggest you change it.

In the region where this router situated a censorship started. A lot of thing and sites are blocked already, I'd say that the half of the Internet... so 443 port it was an attempt to bypass possible blocks/censorship in the future. I know about DPI and traffic obfuscation but this (WG) schema almost works for now.

So what is the point of the second rule???

I thought that it was turned off. Looks like I missed it because of the luck of experience with MT and amount of the rules.

I have no clue as to what is intended by the next two rules.......
Can you please explain what is being accomplished here in some detail??

add action=netmap chain=dstnat comment="WG > PC1 RDP" dst-port=40001 \
in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.2 to-ports=\
3389
add action=netmap chain=dstnat comment="WG > PC2 RDP" dst-port=40002 \
in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.3 to-ports=\
3389

As far as there was a srcnat rule, I forwarded 2 ports to be able to get to these 2 Windows machines via RDP from WG network. Besides that I planned to give an access to the WireGuard to various relatives/friends/etc so I want to be sure that they can't get to MT LAN network directly. I didn't make a final decision should I do that so I mixed up all rules =(

/routing rule
add action=lookup-only-in-table dst-address=192.168.33.0/24 table=main
add action=lookup src-address=192.168.33.0/24 table=use-WG-table

WOW!!!! It works! Thanks you so much!!!

Kamaz · Wed Jul 20, 2022 1:18 am

So lets talk about what you are using
L2TP VPN with PPP for ????
SSH for ???

You are using wireguard and it appears RDP over wireguard which is much better than RDP by itself!!!

I don't have such possibility to use L2tp/ipsec because of the restrictions of my ISP. It was MT<>MT VPN. So now I changed it to WireGuard and trying to configure everything I need (RDP, DOH, etc).
SSH for MT router configuration (Just in case). Main tool is Winbox.

Actually, I configured everything I wanted. Thanks to you, my friend!
- All clients can see each other - done.
- Devices from the MT LAN network could reach WG devices - done.
- All traffic from MT LAN forced to go via WG server - done.
- I can access from WG network to router's LAN - done.

anav · Wed Jul 20, 2022 1:30 am

Understood,
For your edification I use winbox ONLY from the local router NEVER direct externally.
a. from my PC within the subnet
b. from my iphone through wireguard and IOS MT App
c. from Remote winbox ( I joined when a free account was a free account now it seems they charge $2 per month but I dont get any of the services included just access to my router as a backup which is all I need )
d. I dont use SSH at all, but would consider it also as a backup to winbox but only from the local router so basically wireguard in first.

As a probably better option than C. Check out using zerotier client on your PC or laptop to access your router. Its pretty cool too and reasonably secure.

anav · Wed Jul 20, 2022 1:33 am

On those dst-nat rules for RDP............
A friend noted that when the destination address is a /32 address there is no difference between using action=netmap and action=dst-nat.

anav · Wed Jul 20, 2022 1:36 am

But why? This is the default configuration like "allow everything you need and block other thing at the end of chain".

Couple of points, order counts within a chain so its much easier to see how a chain fits together when the rules are grouped.
Second, it was a duplication of rules I was pointing out, not saying to get rid of both as the rule serves some purpose.

I am seeing now, silly me that one was for the input chain and one was for the forward chain, MY BAD!!
In other words you should put them back in, my error!

If you look at how I handle firewall rules, I basically work from the defaults, simplify and then
DROP ALL period.
viewtopic.php?t=180838

anav · Wed Jul 20, 2022 2:34 am

just for giggles here is you config, cleaned up

...............................

# model = RouterBOARD 750G r3
# serial number = 6F38071D6DF3
/interface bridge
add fast-forward=no name=bridge1
/interface ethernet
set [ find default-name=ether1 ] loop-protect=on name=ether1-WAN speed=\
    100Mbps
set [ find default-name=ether2 ] loop-protect=on name=ether2-LAN speed=\
    100Mbps
set [ find default-name=ether3 ] loop-protect=on name=ether3-LAN speed=\
    100Mbps
set [ find default-name=ether4 ] loop-protect=on name=\
    ether4-LAN speed=100Mbps
set [ find default-name=ether5 ] loop-protect=on name=ether5-LAN speed=\
    100Mbps
/interface wireguard
add listen-port=54370 mtu=1420 name=WG_to_VPS
/interface list
add name=LAN
add name=WAN
add name=MANAGE
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.33.50-192.168.33.150
/ip dhcp-server
add add-arp=yes address-pool=default-dhcp authoritative=after-2sec-delay \
    interface=bridge1 lease-time=3d18h10m name=defconf
/routing table
add fib name=use-WG-table
/interface bridge port
add bridge=bridge1 ingress-filtering=no interface=ether5-LAN
add bridge=bridge1 ingress-filtering=no interface=ether3-LAN
add bridge=bridge1 ingress-filtering=no interface=ether2-LAN
add bridge=bridge1 ingress-filtering=no interface=ether4-LAN
/ip neighbor discovery-settings
set discover-interface-list=MANAGE
/interface list member
add interface=bridge1 list=LAN
add interface=ether2-LAN list=MANAGE
add interface=ether1-WAN list=WAN
add interface=WG_to_VPS list=MANAGE
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=94.123.141.46 endpoint-port=\
    443 interface=WG_to_VPS persistent-keepalive=10m public-key=\
    "ggggggggggggggggggggggggggg+JWMf1u6PyRI="
/ip address
add address=192.168.33.1/24 interface=bridge1 network=192.168.33.0
add address=10.8.0.2/24 interface=WG_to_VPS network=10.8.0.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=10m
/ip dhcp-client
add interface=ether1-WAN use-peer-ntp=no
/ip dhcp-server lease
add address=192.168.33.20 client-id=camera_koridor comment=Camera_Koridor \
    mac-address=00:12:15:2B:E2:7F server=defconf
add address=192.168.33.21 client-id=1:0:12:17:7:79:69 comment=Camera_Zala \
    mac-address=00:12:17:07:79:69 server=defconf
add address=192.168.33.22 client-id=1:0:12:17:20:B7:91 comment=Camera_dver \
    mac-address=00:12:17:20:B7:91 server=defconf
/ip dhcp-server network
add address=192.168.33.0/24 comment=defconf dns-server=192.168.33.1 gateway=\
    192.168.33.1 ntp-server=192.168.33.1
/ip dns
set allow-remote-requests=yes cache-size=4048KiB max-concurrent-queries=5000 \
    max-concurrent-tcp-sessions=160 query-server-timeout=8s \
    query-total-timeout=15s servers=1.1.1.1,1.0.0.1 use-doh-server=\
    https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/ip firewall address-list
add address=admin_Desktop_IP  list=Authorized
add address=admin_Laptop_IP  list=Authorized
add address=admin_Iphone(at home)_IP  list=Authorized
add address=admin_Iphone(via wireguard IP)  list=Authorized
add address=admin_Laptop (via wireguard IP) list=Authorized
/ip firewall filter
{input chain}
add action=accept chain=input comment="defconf: accept establieshed,related,untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="Drop invalid input packets" \
    connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input in-interface-list=MANAGE src-address-list=Authorized dst-port=xxxxxx,yyyyyy protocol=tcp {winbox & SSH ports}
add action=accept chain=input in-interface-list=LAN dst-port=53 protocol=tcp
add action=accept chain=input in-interface-list=LAN dst-port=53,123 protocol=udp
add action=drop chain=input comment="drop all else"
{forward chain}
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="Drop invalid forward packets" \
    connection-state=invalid	
add action=accept chain=forward comment="WG > LAN" dst-address=\
    192.168.33.0/24 src-address=10.8.0.0/24
add action=accept chain=forward comment="LAN > WG" dst-address=10.8.0.0/24 \
    src-address=192.168.33.0/24
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward	connection-nat-state=dstnat 
add action=drop  chain=forward comment="drop all else"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    out-interface=ether1-WAN
add action=masquerade chain=srcnat out-interface=WG_to_VPS
add action=dst-nat chain=dstnat comment="WG > PC1 RDP" dst-port=40001 \
    in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.2 to-ports=\
    3389
add action=dst-nat chain=dstnat comment="WG > PC2 RDP" dst-port=40002 \
    in-interface=WG_to_VPS protocol=tcp to-addresses=192.168.33.3 to-ports=\
    3389
/ip route
add dst-address=0.0.0.0/0 gateway=ISPgateway table=main
add dst-address=0.0.0.0/0 gateway=WG_to_VPS  table=use-WG-table
add  blackhole disabled=no dst-address=10.0.0.0/8 
add  blackhole disabled=no dst-address=172.16.0.0/12 
etc.........
/ip service
set telnet disabled=yes
set ftp disabled=yes 
set www  disabled=yes 
set ssh address=192.168.33.0/24,10.8.0.x, 10.8.0.y, etc.... port=xxxxx
set www-ssl address=192.168.33.0/24,10.8.0.x, 10.8.0.y, etc.. \
    certificate=mikrotik.ca.cert.pem_0 disabled=no port=38965 tls-version=\
    only-1.2
set api disabled=yes
set winbox address=192.168.33.0/24, 10.8.0.X, 10,8.0.Y, etc.......
    port=xxxxx
set api-ssl disabled=yes
/ip ssh
set forwarding-enabled=remote host-key-size=8192
/routing rule
add action=lookup-only-in-table dst-address=192.168.33.0/24  table=main
add action=lookup src-address=192.168.33.0/24 table=use-WG-table
/system clock
set time-zone-name=Europe/Moscow
/system identity
set name=valerchik
/system ntp client
set enabled=yes
/system ntp client servers
add address=217.91.44.17
add address=91.198.10.1
/tool mac-server
set allowed-interface-list=NONE
/tool mac-server mac-winbox
set allowed-interface-list=MANAGE
/tool mac-server ping
set enabled=no

.........................

As to your question about others using wireguard to access your connection, not a problem.
As you can see the setup is controlled for access to the router itself, via firewall address list and interface list of MANAGE, ensuring entries match for winbox and ssh for example.
The idea is to use the following.
a. wireguard - this allows local user(s) to enter the tunnel (allowed IPs) and this allows the same user(s) to exit the tunnel as the remote site has allowed (source IPs).
b. firewall rules - on the mT device use the firewall rules to ONLY allow traffic designated. Since we have drop rules now, anything not allowed will be dropped.

For example lets look at these rules to modify ON the MT device, in the forward chain (imagine trying to find them in your previous mess)

add action=accept chain=forward comment="WG > LAN" dst-address=\
192.168.33.0/24 src-address=10.8.0.0/24

(i) In this first rule we probably dont want to to give full access of the router subnet to all the potential wireguard clients............
If there was a common device, lets say an NAS that you wanted all to access then that would be fair game.

So for ADMIN WIREGUARD REMOTE ACCESS
add action=accept chain=forward in-interface=WG_to_VPS src-address=10.8.0.X./32 \
dst-address=192.168.33.0/24 comment="admin full lan access from remote laptop"

FOR COMMON ACCESS TO single DEVICE NAS
add action=accept chain=forward in-interface=WG_to_VPS \
dst-address=192.168.33.Z/32 comment="all wireguard users to NAS"

In summary use the interface alone for all wireguard users, add source address to narrow down which incoming user, and the same for the destination, either the entire subnet or nail it down by specific IP.

(ii) For the reverse case traffic originating on the LAN heading outbound, I dont think one should assume that a LAN user is going to be configuring an iphone so really nothing specific is needed.
But correct if some of the traffic is going to go out a VPS device......for internet, its probably the right thing to allow as follows,
add action=accept chain=forward src-address=192.168.33.0/24 out-interface=WG_to_VPS

Kamaz · Sun Sep 04, 2022 11:06 am

just for giggles here is you config, cleaned up
...............................

Hi, sorry for the late response. Thank you so much for the help, now it work like a charm!

Kamaz · Fri Jul 28, 2023 12:07 pm

Hello again. The previous configuration was working fine during last year, thank you again.
But users behind Mikrotiks are facing a very strange issue with some well-known web sites like Github, Duckduckgo, Iherb, Aliexpress. It was not important during this time but it's not good for now.
Chrome gives ERR_TIMED_OUT error. And at the same time Firefox gives ns_error_net_timeout and ns_binding_aborted.

The same schema as it was previously user(PC/phone) > MT router (force traffic routing) > WG tunel > WG server (VPS) > Internet

I checked Windows configuration, host file, antivirus/FW, DNS configuration, browsers - no luck.
After that I asked people to try Ubuntu and Android - no luck.
Next to it I disabled everything on Mikrotik side (FW rules, NAT, DNS/DOH, all acripts) - no luck.
Tried different browsers, different DNS configuration for them DOH/non-DOH, differend DNS provider - no luck.

And the last - when I disabled route to WG server - all works fine (direct connection user > ISP > web-site). But this is the main idea, I need to encrypt all traffic from networks behind MT routers. Besides that, if user connect to WG server directly from his PC/phone using Wireguard client, everything works fine also.

Yesterday I spent hours googling something like "Wireguard+ns_error_net_timeout" and trying to figure out what's wrong. And the only noticable thing I found, it's IPv6 issue in WG+OpenWRT. But my VPS and MT routers do not use IPv6, it was disabled on MT and Linux VPS long time ago.

Ping to specified hosts (Github, Duckduckgo, Iherb, Aliexpress) is OK
Tracert shows correct path.

curl -vv https://aliexpress.com
* Trying 47.246.173.237:443...
* Connected to aliexpress.com (47.246.173.237) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: failed to receive handshake, SSL/TLS connection failed
* Closing connection 0
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

I hope that somebody can help, because I don't know what to do next.

Kamaz · Fri Jul 28, 2023 1:30 pm

OMG!!! I found the issue!

viewtopic.php?t=184115
https://help.mikrotik.com/docs/display/ ... -ChangeMSS

Change MSS

It is a known fact that VPN links have a smaller packet size due to encapsulation overhead. A large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to sending it via that kind of connection. However, if the packet has a Don't Fragment flag set, it cannot be fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD), it may lead to a number of problems, including problems with FTP and HTTP data transfer and e-mail services.

In the case of a link with broken PMTUD, a decrease of the MSS of the packets coming through the VPN link resolves the problem. The following example demonstrates how to decrease the MSS value via mangle:

/ip firewall/mangle/ add out-interface=WG protocol=tcp tcp-flags=syn action=change-mss new-mss=1360 chain=forward tcp-mss=1301-65535

anav · Fri Jul 28, 2023 4:02 pm

We use a similar rule in case a third party provider is giving issues........ wasnt expecting that from your VPS.
Called mSS clamping
/ip firewall mangle
add action=change-mss chain=forward comment="Clamp MSS to PMTU for Outgoing packets" new-mss=clamp-to-pmtu out-interface=wireguard1 passthrough=yes protocol=tcp tcp-flags=syn

One thing that breaks PTMUD etc. is not allowing ICMP ping hence why one of hte default rules on MT RoS is:
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp

What if any rules exist on the VPS regarding ICMP???

========================
The solution you found is also available on the earlier link provided --> viewtopic.php?t=182340 see Sub para (9) d.MTU-MSS ISSUES

Kamaz · Sun Jul 30, 2023 10:31 am

We use a similar rule in case a third party provider is giving issues........ wasnt expecting that from your VPS.
Called mSS clamping
/ip firewall mangle
add action=change-mss chain=forward comment="Clamp MSS to PMTU for Outgoing packets" new-mss=clamp-to-pmtu out-interface=wireguard1 passthrough=yes protocol=tcp tcp-flags=syn

One thing that breaks PTMUD etc. is not allowing ICMP ping hence why one of hte default rules on MT RoS is:
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp

What if any rules exist on the VPS regarding ICMP???

========================
The solution you found is also available on the earlier link provided --> viewtopic.php?t=182340 see Sub para (9) d.MTU-MSS ISSUES

Hello. There is one ICMP rule on my VPS:
-A INPUT -i eth0 -p icmp -j ACCEPT

Kamaz · Mon Jul 31, 2023 2:33 am

And one more thing. Can you please share a little bit of additional info how routing works in current conditions. In a simple words if it's possible.

You have currently created the required components for WG.
/routing rule
add action=lookup src-address=192.168.33.0/24 table=use-WG-table
/routing table
add fib name=use-WG-table

Now you have to add the IP route ( i see its there but disabled, so just enable it! )
/ip route
add dst-address=0.0.0.0/0 gateway=WG_to_VPS table=use-WG-table

Now lets look at the logic,
All traffic coming from the LAN is captured and sent out WG, so to ensure we dont inadvertently do that for LAN to LAN traffic, add a another route rule ORDER IS KEY SUCH THAT..

/routing rule
add action=lookup-only-in-table dst-address=192.168.33.0/24 table=main
add action=lookup src-address=192.168.33.0/24 table=use-WG-table

Does these thoughts are correct?

/routing table add fib name=use-WG-table - a table creation
/routing rule add action=lookup-only-in-table dst-address=192.168.33.0/24 table=main - all traffic TO LAN 192.168.33.0/24 will be in a main table and appropriate rules will be applied.
/routing rule add action=lookup src-address=192.168.33.0/24 table=use-WG-table - if our traffic goes from LAN 192.168.33.0/24 elsewhere it will use route connected with use-WG-table table. This is the only one above mentioned route. But in case WG tunnel is unreachable, router will try (action=lookup) to find needed route in another tables (main). So my traffic will go directly via WAN interface.

Looks like I'm missing something or misunderstanding. Because If the WG tunnel is down, the internet not working. But it should because of the action=lookup option.
Besides that if I disable this rule "/routing rule add action=lookup-only-in-table dst-address=192.168.1.0/24 table=main" I don't see any changes, my traffic goes as previously, via WG.

Here is my latest config:

/ip firewall/nat/add chain=srcnat action=masquerade out-interface=WG_to_PT log=no log-prefix=""
/routing table add name=use-WG-table fib
/routing rule add action=lookup-only-in-table dst-address=192.168.1.0/24 table=main
/routing rule add action=lookup src-address=192.168.1/24 table=use-WG-table
/ip route add dst-address=0.0.0.0/0 gateway=WG_to_NL routing-table=use-WG-table

Thanks in advance.

anav · Mon Jul 31, 2023 8:48 pm

Okay I find two things funny in your short config snippet,

/routing rule add action=lookup-only-in-table dst-address=192.168.1.0/24 table=main
/routing rule add action=lookup src-address=192.168.1/24 table=use-WG-table

First, the second rule should be 192.168.1.0/24
Secondly, why are you using the same subnet in both cases??
Okay I see why, that the example I provided previously............ will have to think on this one.

I can see needing the rule for other vlans/subnets but not sure about the same subnet. I dont think it could hurt..........
and may be necessary.

Kamaz · Mon Jul 31, 2023 10:59 pm

First, the second rule should be 192.168.1.0/24

The first thing I want to say "thank you" for your help during this year!
And looks like this is my typo. I have 3 routers with similar configuration and I spent last days reading about routing and trying various things.

I can see needing the rule for other vlans/subnets but not sure about the same subnet. I dont think it could hurt..........
and may be necessary.

Yes, I used it because you told so.

And it helped! One year ago I was hurrying up and it was very important to do that ASAP. But now I'm trying to understand how all these rules/routes/tables work together. And fix some issues.

But if you can explain how this rule works, I'll be very appreciating.

/routing rule add action=lookup src-address=192.168.33.0/24 table=use-WG-table - if our traffic goes from LAN 192.168.33.0/24 elsewhere it will use route connected with use-WG-table table. This is the only one above mentioned route. But in case WG tunnel is unreachable, router will try (action=lookup) to find needed route in another tables (main). So my traffic will go directly via WAN interface.

Looks like I'm missing something or misunderstanding. Because If the WG tunnel is down, the internet NOT working. But it should because of the "action=lookup" option.

anav · Tue Aug 01, 2023 12:02 am

Yes that is correct, if the Route via WG is not available, then the router will go to the main table and find an available routing if there is one.
Without seeing the whole config, not sure if i could pinpoint any particular area to look........

Wireguard configuration

Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Re: Wireguard configuration

Who is online