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 );