I'll have to go read up on masquerading. I was copying another router on the network that has masquerading enable for both Lan and Wireguard, which didn't work in this case. But on with Lan and off Wireguard has worked, thanks.
Regarding the DNS server specified on the peer profile, I have this as the router's internal IP as shown on the main router, but this changes occasionally without apparently impacting my ability to connected. What would the correct value be for the DNS server on a peer profile?
And last question, not strictly related to openwrt, when I activate Wireguard on android, I access the remote network and for example 192.168.1.1 takes me to the remote location's main router admin page. On Mac even though my IP address appears to be that of the remote location, 192.168.1.1 takes me to my local router admin page. How do I get around this so on Mac so I cam access the remote network when connected through Wireguard?
The the IP addresses themselves as well as the likelihood and frequency of a change is dependent on the way that the DHCP server is implemented. If the OpenWrt router's address on the main router does change, I would expect you will be unable to connect via Wireguard (the port mapping will not map to the correct IP anymore). So if you want to ensure that the OpenWrt IP address is always consistent, there are 2 methods you can use to fix this (typically either/or):
set the lan network interface on the OpenWrt router to proto 'static' and then provide the relevant information (from your existing example, it would likely be address 192.168.1.6, subnet mask 255.255.255.0, gateway 192.168.1.1, DNS 192.168.1.1). If you go this route, make sure that this address is not within the DHCP pool of the main router.
On the main router, set a DHCP reservation for your OpenWrt router. This will ensure that it is always issued the same IP from the DHCP server.
I'm not sure which one you are referring to as local vs remote in this situation. But it doesn't really matter... change the subnet of your home network (at least I'm assuming this is your home network we've been working with) so that it doesn't conflict with the remote network. This way there is no ambiguity of which one you are trying to access. 192.168.1.0/24 is extremely common, so the chances of overlap are significant. If you change it to any RFC1918 address range that is less common, you should be able to alleviate the issue. For example -- I'm selecting randomly... 172.16.23.0/24 would probably be pretty uncommon and unlikely to conflict.