Hi,

My thought is that you might be better with a different router that has a different switch chip. (eg. A Hap AC^2)

With these switch chips, you can set the bridge to be fully hardware forwarding, using switch rules to kick selected switched packets to the
CPU. (It then hits the bridge configuration of the CPU, and you can kick it again into the router section)

So the CPU is only doing work for those packets.
And the CPU on the Hap AC^2 is quite a bit faster than the hex.

If multiple vlans are being switched, things are possibly less easy.

Sorry for the amount of text here.

My thoughts.

1. You likely need to take some care with your customers networks.
2. The VPN connection to your server should look like a WAN interface to
your client,
- ie. Your clients can connect to your server.
- Your server can't open connections to devices on your clients network.
- If you have nat forwarding rules on the vpn, you should let your
clients know they are there, and what they are.
3. The address(es) to be redirected should be to a private IP address,
so if something goes wrong and packets destined for your server leave
via the normal gateway, the ISP will just drop them.

4. Your CHR should also treat the wireguard tunnel as a Wan interface,
and simply port forward (dst-nat) http(s) connections to the local
wireguard IP address to your web server.
Reply to pings over the wireguard tunnel.
Pretty much everything else should be dropped.

5. Please attempt to get rid of the IPIP tunnel, and just use wireguard.

A possibility.

Set the wireguard keepalive on the hex's to 25 S or so. On the CHR
and the Hex's under IP Firewall connection tracking set the UDP
timeout to 30S (Should be default on recent versions of RouterOS, but
was 10S for a long time)


How to:

Backup your current config.
Note: This is for something close to your stated requirements.

Start with the default configuration on the Hex using a recent version
of RouterOS.

And perform initial testing, using the Hex inside a trial network,
with your Laptop using the Hex as its default gateway.

To see that traffic from Laptop that should go via Wireguard/IPIP does, and
the rest goes via the main router.

(Making it do this from the bridge comes later, and is quite simple, but expensive)

From default config:

• Disable IPv6 on the Hex
• Move ether1 to the bridge
• Turn off the dhcp server
• Move the dhcp client to the bridge
• Temporarily disable the firewall filter rule that drops invalid packets
• At this time leave the 192.168.88.1/24 IP address on the Unit
• Give the Unit a suitable Identity, Username/Password etc

Create your Wireguard, (and if required IPIP configuration).
Limit the Wireguard allowed addresses to only the IP Addresses that
are going to be redirected.
In fact, as mentioned earlier, ideally just use the CHR's wireguard IP
address as the only allowed IP address.
Configure the Hex's wireguard IP address.

If for example you have 10.10.10.2/24 on your hex and 10.10.10.1/24 on
the CHR you only need 10.10.10.1 on the hex for the Peers allowed IP
address(es), and you don't need any routes added. (As a route will
automatically be added)

Otherwise make a routing entry for addresses that must go via Wireguard (in main)

Add both Wireguard (and the IPIP) to the Interface List as WAN.

Plug the hex into your trial client network, (Use Ether1)
Plug your Laptop into any of the other Ports on the Hex.

The Hex should get an IP address on the local network.

Unfortunately you don't know what it is, however the Hex should show up in
Winbox as 192.168.88.1/24, and you should be able to connect via it's
mac address, and find the address it has received from its DHCP server.
(Or set it up statically if no DHCP server) You can then disable the
192.168.88.1 IP address (or not).

Now configure your laptop with the Hex's IP address as its default gateway.

Test that traffic that should go via WG/IPIP does.
Test that rest of traffic goes via default gateway.

Adjust configuration until it works solidly.
You likely need MSS adjustment applied to the wireguard/IPIP traffic?

Once the above is configured and working, you can then rejig the bridge
to redirect the needed packets to the routing engine. Unfortunately this
is expensive.

Disable the Hardware offload on Port ether1 on the bridge.

Create a bridge nat rule
You can likely re-enable the Invalid Packet firewall rule that was
disabled earlier at this time.

You should now reconfigure the default gateway on your laptop to be the normal main gateway.

Check it is working.

Some alternate options to using the bridge NAT rule.

The bridge NAT rule is expensive in that it has to examine every
packet coming through the Hex. (ie. Coming from or going to the main
gateway)

Unfortunately these alternate options are likely to be PER client.

If you can setup DHCP option 121 (classless routing) on the client
network, you can get the clients to go via the hex to get to
10.10.10.1

If you can set a DNS entry on the client network, you could have the
name point to the IP address of the hex (which would be configured to
port forward port 443/80 to 10.10.10.1)

If only a small number of client PC's need to connect to your server,
you could configure static routes on them pointing at the Hex.
Or use the hex as their default gateway.
Disable or alter the invalid packet rule if using as default gateway.