The value of the WAN addresses don't matter. If you're using a PSK, make sure it is identical on both sides (this is IMHO the most common error in failing VPN setups). In phase2, the Quick Mode selectors should be more specific than the '0.0.0.0/0' defaults.
If you need more support, please post the phase1 and phase2 config, along with the policy and the static route which are needed for this to work.
I generally prefer to avoid wildcards. When setting up a site2site VPN I know in advance which networks are involved. Pinning down the traffic to 'known' networks has a security aspect as well: introducing rogue devices with arbitrary network addresses (like the unbeatable 192.168.0.x) will not have any effect on VPNs then.
Of course, this can be controlled in the corresponding policy as well. In fact, it should be and usually is.
Besides, one look into the phase2 documents which traffic is meant to cross the link.
One more reason: the wildcard '0.0.0.0/0' is AFAIK Fortinet specific. Other vendors like Cisco require explicit subnet specs. So, it will work between FGTs (albeit with less control) but not if one side uses or changes to use a non-FTNT device.
The problem is ;1> FTNT KB/DOCs always demonstrates a 0.0.0.0/0:0 in most site2site vpn examples 2> in FTNT training classes & when they do the site2site w/OSPF they demo 0.0.0.0/0:0 3> wildcard will work for all address and services, but its MORE ideal to at least set the type as subnet and then specificy the exact src/dst-subnets ( aka local/remote networks )
IMHO the 0.0.0.0/0:0 is just a lazy way of doing it, but it does have it's PROs
1: it's a one-time cfg ( you never have to add multiple phase2-interfaces for other ranges that you latter want to encrypted , just ensure routes for the remote-vpn are in placed or added as required )
2: you can't screw it up ;) ( it's idiot proof to some degree )
1: It leaves you no specific show diagnostics outputs for per-local/remote vpn networks
2: make for more troubleshooting if just one local/remote networks connectivity is working or not without using diag sniffer or diag flow commands
3: it won't work for other firewalls that hates proxy-ids that have 0.0.0.0/0 as mention before ( e.g cisco ASA, openSense,Pfsense,checkpoint,etc.....)
I always try to stress the specific local/remote subnets with all my associates and avoid the easy and lazy way of a 0.0.0.0/0:0
I get your points, but if you have to deal with remote sites with many different networks, the configuration takes way longer, and also to change encryption parameters in the future is more work too.
I think there are a few vendors out there which support quad 0, but most of the technicians don't know how to configure it. Palo Alto for example also uses quad 0 as a default setting, but anyway, everybody should do it like he wants