Try this, for the office, with a complementary configuration at home:
/etc/config/network:
[...]
config interface 'wg_s2s_b'
option proto 'wireguard'
option private_key 'OFFICE PRIVATE KEY'
option listen_port '51250'
list addresses '192.168.8.1/24'
config wireguard_wg_s2s_b
option public_key 'HOME PUBLIC KEY'
option description 'Site B, home.dynamicdns.name'
list allowed_ips '192.168.8.2/32'
list allowed_ips '192.168.0.0/24'
option route_allowed_ips '1'
option endpoint_host 'home.hostname'
option endpoint_port '51250'
option persistent_keepalive '25'
[...]
/etc/config/firewall:
[...]
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'wg_s2s_b'
[...]
config rule
option name 'WireGuard'
list proto 'udp'
option src 'wan'
option dest_port '51250'
option target 'ACCEPT'
option family 'ipv4'
I just spun up that as a test configuration and it worked. This was the routing table:
root@OpenWrt:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 xxx.xxx.xxx.xxx 0.0.0.0 UG 0 0 0 eth1
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx 255.255.255.255 UGH 0 0 0 eth1
xxx.xxx.xxx.xxx 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg_s2s_b
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.8.2 0.0.0.0 255.255.255.255 U 0 0 0 wg_s2s_b
Only one extra firewall traffic rule needed, beyond the default out-of-the-box rules, to allow WireGuard inbound at the WAN interface. No extra NAT rules needed; the default SNAT/Masquerade rule for the WAN is sufficient.
The WireGuard VPN itself is part of the LAN zone (assumed safe in line with other forum member's observation about the purpose of the site-to-site VPN and the corresponding trust) so no extra traffic rules needed.
Now, if your ISP genuinely does filter UDP packets (bear in mind that DNS is 53/udp, so your ISP won't be filtering all UDP packets...), you might find that picking other ports may help. I happen to like and use 51250, but it's not mandatory.
If juggling port numbers still doesn't do the trick, then you're going to have to get to grips with tunnelling UDP over TCP, or even a different VPN altogether, one which can use TCP.
A useful tool for this scenario is tcpdump. It's not included by default so it would have to be installed manually.
If you use tcpdump to listen for traffic on every interface in the path, both physical and logical, you may be able to determine where - or if - traffic is being dropped.
For example:
Kick off a constant ping from 192.168.0.100 to 192.168.2.100
Use tcpdump to sniff the lan interface on OpenWRT HOME for ICMP traffic from192.168.0.100to192.168.2.100
Use tcpdump to sniff the wg_s2s_b interface on OpenWRT HOME for ICMP traffic from192.168.0.100to192.168.2.100
Use tcpdump to sniff the wan interface on OpenWRT HOME for 51250/UDP traffic toOpenWRT OFFICE (change the port number to match your configuration).
Use tcpdump to sniff the wan interface on OpenWRT OFFICE for 51250/UDP traffic fromOpenWRT HOME (change the port number to match your configuration).
Use tcpdump to sniff the wg_s2s_a interface on OpenWRT OFFICE for ICMP traffic from192.168.0.100to192.168.2.100
Use tcpdump to sniff the lan interface on OpenWRT OFFICE for ICMP traffic from192.168.0.100to192.168.2.100
You may also wish to sniff the same interfaces in reverse, also reversing the sources and destinations where appropriate, to track the progress of any replies. Even if traffic can flow one way it does not always mean that the responses flow back the same way.
