It's not so complicated.
On your side, you only operate with the 10.1.1 subnet. Every host address (like 10.1.1.222) is translated 1:1 into an address in 192.168.1 (like 192.168.1.222). That is, the remote address range is not visible on your side, and can therefore be used for other purposes.
You will have to learn new addresses for the remote hosts, or rather, your DNS.
OTOH, in order that routing on the remote side still be working, your source addresses need to be NATted as well. It might just happen that you use an address from 192.168.1, and that would be confused on the remote side with a local address (and thus not routed back into the tunnel).
So, the remote side will have to deal with, say, the 10.100.1 subnet if it addresses your LAN.
There is a write-up in the Knowledgebase (https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33872)
which contains a WORD document with screenshots. This might help to visualize the setup.Unfortunately
it contains a grave error in the setup of the second FGT (FG-311B). The VIP on this side must have an 'external IP' of 172.16.201.x, not 172.16.200.x (as this is used on the remote side).
I was too dumb to understand it properly...worked it through and it will work as documented.
I would strive to use subnet ranges for the 'virtual' subnets as distinct as can be, like for a VPN between a FG-40C and a FG-311B 172.16.40.x and 172.16.31.x, resp.
about DNAT: a VIP not only exchanges the destination IP, but for reply traffic going into the other direction it automatically replaces the source address, so that the 'hidden' server behind the VIP really is hidden. That's what I meant.
post edited by ede_pfau - 2019/05/22 01:06:58