If the traffic is not being encrypted into the tunnel at all (I assume you are seeing an Accept action instead of an Encrypt action in the logs), you have a problem with your VPN domains. I'm assuming you are not trying to use route-based VPN via VTIs and you have all the default settings in NAT Global Properties selected. Here is the order of operations for determining whether traffic is "interesting" (to borrow a Cisco term) to a VPN tunnel:
1) Network/Firewall policy must accept traffic based on src/dst/service
2) Matching NAT rules determined for both destination and source
3) Destination NAT operation performed on packet (actual source NAT operation will happen later)
4) Gaia IP routing based on post-NAT destination - this should typically be towards the External interface
5) If packet's pre-NAT source IP is in your firewall's VPN domain AND the post-NAT destination IP is in your peer firewall's VPN domain, AND the VPN column of the rule matched in #1 is "Any Traffic" or explicitly set to the matching VPN Community, source NAT then encrypt the traffic into the matching Community tunnel of which both your firewall and the peer are members. If any of these are not true just source NAT if applicable and forward in the clear.
Make sure that the pre and post NAT destination addresses on the VPN peer's internal network are NOT defined in your own firewall's VPN domain or encryption will not happen. Also make sure that the destination peer's VPN domain does not overlap with any other VPN peers, use command vpn overlap_encdom communities -s to easily detect this.
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com