2 Wireguard servers and Mikrotik CHR

RouterOS Beginner Basics
1

I have VPS server run Docker Wireguard ready image. When i connect from client side, its working and traffic its going through there. I need redesign solution, add in between Mikrotik CHR with static IP. And client side should be connect through new Mikrotik CHR though that static IP.
So in the end i would like to connect to Mikrotik CHR static IP from client end Mikrotik and traffic pass through VPS docker Wireguard via Mikrotik CHR. Like in the scheme bellow.

VPS Docker Wireguard <--------> Mirkotik CHR (with static IP) <-------------------> Client Mikrotik.

Configuaration in Docker Wireguard

# Server
[Interface]
PrivateKey = xxxxxxxxxxxxxTwO2VU=
Address = 10.10.10.1/24
ListenPort = 51820
PreUp =
PostUp =  iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE; iptables -A INPUT -p udp -m udp --dport 51820 -j ACCEPT; iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j >PreDown =
PostDown =


# Client: gw01 (xxxxx)
[Peer]
PublicKey = xxxxxxxxxxxxxl8OTkI=
PresharedKey = xxxxxxxxxxxxxxFzGs=
AllowedIPs = 10.10.10.2/32

My configuaration on Mikrotik CHR like that

# may/16/2023 11:05:44 by RouterOS 7.9
# software id = 
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
/interface wireguard
add listen-port=13231 mtu=1280 name=wireguard1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
set 1 name=serial1
/interface wireguard peers
add allowed-address=10.2.0.0/24,0.0.0.0/0,::/0 endpoint-address=x.x.x.x \
    endpoint-port=51820 interface=wireguard1 persistent-keepalive=10s \
    public-key="xxxxxxxuiMKQ4="
add allowed-address=10.10.10.4/32 interface=wireguard1 persistent-keepalive=10s \
    public-key="xxxxxxxgr+RwI="
/ip address
add address=51.x.x.x/29 interface=ether1 network=51.x.x.128
add address=10.20.20.63/24 interface=ether2 network=10.20.20.0
add address=10.10.10.2/24 interface=wireguard1 network=10.10.10.0
/ip dhcp-client
add interface=ether1
/ip dns
set servers=1.1.1.1
/ip firewall filter
add action=accept chain=forward in-interface=wireguard1
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=\
    wireguard1 protocol=tcp tcp-flags=syn
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=51.x.x.x routing-table=main \
    suppress-hw-offload=no
/routing rule
add action=lookup disabled=no src-address=51.x.x.x/32 table=main
/system note
set show-at-login=no

Configuration in client Wireguard

[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxo0WsrV0=
Address = 10.10.10.4/24
DNS = 10.2.0.100
MTU = 1280

[Peer]
PublicKey = xxxxxxxxxxxxxxxgr+RwI=
AllowedIPs = 10.2.0.0/24, 0.0.0.0/0, ::/0
Endpoint = 51.x.x.x:51820
2

Just to be clear.
The virtual CHR is what both client user and MT docker attach to?
OR
The client attaches to virtual CHR but CHR attaches to MT docker

{ in terms of client to server initial handshakes is what I mean… }

The clarity is needed as your config is hosed and will not work.

So detail the requirements,
a. which has publicly accessible WANIP?
(i)–> if only the CHR, then the CHR has to be Server for both MT docker instance and any remote clients on the net.
(ii) —> if both the CHR and MT Docker have one, then the Docker makes more sense to host remote clients and you dont need CHR at all.

b. Purpose of CHR - following the logic trail… if the MT Docker has a publicly accessible IP address CHR is not required UNLESS..
your intention is to send
a. MT docker users out CHR for internet via wireguard
b. remote users out CHR for internet via wireguard and not MT docker…

So you see a much clearer description of your requirements, a common understanding, is required prior to discussing config.
https://forum.mikrotik.com/viewtopic.php?t=182340

3
  • Client: The client wants to establish a connection to a MikroTik CHR device using its public IP address.


  • MikroTik CHR: This device serves as the entry point for the client’s connection. It will receive the client’s connection request and handle it.


  • WireGuard Docker on VPS: After the client successfully connects to the MikroTik CHR, the traffic will be routed through a WireGuard Docker container. The WireGuard Docker container will act as a gateway to pass the internet traffic.

To summarize the flow:

The client initiates a connection to the public IP of the MikroTik CHR device.
The MikroTik CHR device receives the connection request from the client.
Upon successful connection, the client’s internet traffic is routed through a WireGuard Docker container.

4

You didnt answer my questions but will assume the following.
The CHR has the public IP, the whatever hosting the docker does not.

I will assume two uses for client
a. admin user needs access to internet via the docker access
b. admin user needs access to CHR remotely ( for config purposes )

Client-User1 ( 10.10.10.4/32 )
DNS —> Should match the DNS provided at the VPS docker host device, or use 1.1.1.1
MTU → All the MTUs should match at all three sites, docker/chr/client. START WITH Default 1420 ( not sure how you got 1280 ), if that doesnt work then try 1500.

Peer Settings
AllowedIP=0.0.0.0/0 ( nothing more is required as this covers all possible address - required for internet but then covers any remote subnets or wireguard IPs etc.. )
Persistent-Keep-Alive → set to something like 35s
Endpoint —> PORT is 13231 !!! (+Address of CHR public IP)

CHR (Server for initial handshake for both client-User and Client-Docker)
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
comment=docker add allowed-address=0.0.0.0/0 { The client-User terminates at CHR, that traffic will re-enter tunnel to docker with any internet address possible }
endpoint-port=51820 interface=wireguard1 { persistent keep alive is not required at the server for initial handshake }
public-key=“xxxxxxxuiMKQ4=”
comment=client-user add allowed-address=10.10.10.4/32 interface=wireguard1 { persistent keep alive is not required at the server for initial handshake }
public-key=“xxxxxxxgr+RwI=”

Note: This rule should NOT be required. Its typically for connecting the MT to a third party provider!!!
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=
wireguard1 protocol=tcp tcp-flags=syn

/ip address
…
add address=10.10.10.2/24 interface=wireguard1 network=10.10.10.0

+++++++++++++++++++++++++
You have no firewall rules in place and thus all traffic is permitted on CHR, making this a very unsafe proposition.
Suggest the minimum following:
…

/interface list
add name=WAN
add name=LAN
/interface list members
add interface=ether1 list=WAN
add interface=wireguard1 list=LAN
add interface=ether2 list=LAN
/ip firewall filter
{Input Chain}
(default rules)
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
(admin rules)
add action=accept chain=input dst-port=13231 protocol=udp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" *****
{forward chain}
(default rules)
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=input comment="defconf: drop invalid" connection-state=invalid
(admin rules)
add action=accept chain=forward in-interface=wireguard1 out-interface=wireguard1  comment="allow relay of traffic"
add action=accept chain=forward in-interface=wireguard1 out-interface=ether2 comment="allow user to local subnet"
add action=accept chain=forward comment="allow CHR internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat  disabled=yes  {  enable if required }
add action=drop chain=forward comment="drop all else"

…

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

/IP routes… WHY the routing rule, get rid of it, NOT REQUIRED!
add disabled=no dst-address=0.0.0.0/0 gateway=51.x.x.x routing-table=main
suppress-hw-offload=no

Traffic to Wireguard addresses is auto-handled by the DAC route created by the wireguard1 ip address.
However, if you wanted the user-client to visit a subnet on the docker host it would need to be included here. lets say there was a subnet 10.2.0.0/24
Additionally all the internet traffic deposited at the CHR by the user client, and allowed to re-enter the tunnel in firewall rules needs the path for that traffic.

/routing table add fib name=useWG

/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=51.x.x.x routing-table=main
suppress-hw-offload=no
add dst-address=10.2.0.0/24 gateway=wireguard1 routing-table=main disabled=yes { enable if required }
add dst-address=0.0.0.0/0 gateway=wireguard1 routing-table=useWG

/routing rule add src-address=10.10.10.4 action=lookup-only-in-table table=useWG

===============================================================================

vps docker considerations
IP address → 10.10.10.1/24

Peer settings
AllowedIPs: 10.10.10.0/24
Persistent keep alive=40s
endpoint port 13321 (+address of CHR public IP)

Firewall rules to allow
wireguard traffic to internet
wireguard traffic to local subnet 10.2.0.0/24 ( if required )

Other
any special routes, or masquerades to ensure wireguard traffic makes it through host device to internet (easy part) and the return traffic gets routed back to vps docker and back out wireguard tunnel( the hard part );