Site-to-Site VPN, UTM to SonicWall, Connection made but no traffic

I'm not sure why you are using NAT. Are 192.168.168.222 and 10.242.3.222 also the actual IP-address at their respective local networks? If so, then no NAT should be needed. If you have different "real" local addresses, than you might need NAT.

In UTM did you tick the box to "bind tunnel to local interface" or didn't you? If you did, then there will be no route to the remote host/network. If the VPN is the only connection between the two hosts, then make sure to just turn this option off...

Yes the machine on the remote network is 192.168.168.222. The DHCP server is configured to hand out addresses from 0-167, GW .168, so I figured picking .222 would avoid any IP conflicts.  This setting works fine for ingress/egress communication from this remote host to the internet.  Clients within the DHCP scope can communicate with it as well.

I want to connect this single host to my local network at 10.242.3.222 (which is otherwise an unused IP) via S2S VPN.   This falls within the default L2TP subnet (10.242.3.0/24), unused in my configuration but not sure if that is cludging things up so I mentioned it.

I have again tried disabling all NAT traversal but the traffic will still not get routed through the gateway, which is why I thought I needed either a NAT or routing rule in the first place.  

I searched all over but didn't find the 'bind tunnel to local interface' tickbox so I'm going to assume that's disabled if it's the default setting.

Yes the machine on the remote network is 192.168.168.222. The DHCP server is configured to hand out addresses from 0-167, GW .168, so I figured picking .222 would avoid any IP conflicts.  This setting works fine for ingress/egress communication from this remote host to the internet.  Clients within the DHCP scope can communicate with it as well.

I want to connect this single host to my local network at 10.242.3.222 (which is otherwise an unused IP) via S2S VPN.   This falls within the default L2TP subnet (10.242.3.0/24), unused in my configuration but not sure if that is cludging things up so I mentioned it.

I have again tried disabling all NAT traversal but the traffic will still not get routed through the gateway, which is why I thought I needed either a NAT or routing rule in the first place.  

I searched all over but didn't find the 'bind tunnel to local interface' tickbox so I'm going to assume that's disabled if it's the default setting.

I now see in your own picture above that this option is unchecked (which is good).

Can you give us a screenshot of

Support -> Advanced -> Route table

(You can hide details not related to the remote subnet, but check whether there are multiple entries using the same subnet(s).

I don't know Sonicwall, but if possible can you also list a route table from that?

This way it's possible to determine if the routes to the other network from both firewalls are correctly in the route table.

Bind tunnel to local interface doesn't show if strict routing is enabled.  I always had issues if strict routing isn't enabled.  I am connecting to 3 different Sonicwalls and have strict routing enabled on all of them.  Make sure the hosts are pingable, run a ping from each side and check the firewall logs to make sure it's not an issue there.  SW always adds the rule automatically as will the UTM if auto firewall rule is selected.

On the Sonicwall routes are shown in Network>Routing, but VPN routes are not shown.  There are route based VPNs, but not needed for this setup.

He can go under System>Diagnostics and use find network path though.

Thanks for clearing up RE: strict routing & bind tunnel.

OK, here is my UTM route table.  It does not seem to have the 10.242.3.222/32 subnet in it that I'm using for the local subnet.  The remote subnet that I'm creating the link to (192.168.168.222/32) is first in the list.

10.242.2.0/24 is my SSL VPN subnet (default) that is successfully working through both the OpenVPN client and the Sophos-branded OpenVPN client.

SonicWall route table in its current state, though I have to preface I have tried creating routes direct from my 192.168.168.222 which in the remote site's context is a local address, and I feel I've iterated many settings...no doubt I'm missing something though.

For every setting I've tried, I've given it a metric of 1.

Even with the apparent wrong route configuration in SonicWall, the VPN tunnel is still up.  My traffic on the remote machine (192.168.168.222) is still traversing through the LAN to, say, ping Google successfully.  No ability to contact interfaces in my tunnel's LAN though, though I can ping the public IP's gateway from 192.168.168.222.

Obviously some communication is working as I can manage my SonicWall remotely (HTTP/S), and can even manage my ESXi box remotely...though this is a temporary rule because it's no doubt bad practice.

Let me know if I can provide more information.  Your recommendation of what the SonicWall's route should look like for my 192.168.168.222 machine would no doubt help a lot.

Route from UTM to Sonicwall seems okay and routes over IPSEC

Like Robert Yount said above, apparently routes for VPN are not shown in Sonicwall, but he also told to:

He can go under System>Diagnostics and use find network path though.

What does that give you?

Also, maybe the default L2TP VPN pool is what's causing all of this. Do you have L2TP over IPsec disabled under Remote access -> L2TP over IPsec?

If so, can you (just to be sure) change the default VPN Pool (L2TP) to something different and see if that changes something?

New developments.  I still suspect I'm facing a NAT issue.  L2TP VPN via remote access is and has been disabled.

I set the checkbox in SonicWall to use the VPN as the default route for only my DC-Roots remote host (overlooked before), which is now configured thus:

In my head that routes absolutely all traffic through the VPN for my one host.  From the remote context, I still cannot ping Google's 8.8.8.8, but that's probably a firewall issue.  I cannot ping my large local network 192.168.0.0/20 either, HOWEVER I can ping my local wireless network within 10.5.0.0/24.

That tells me either side is getting confused when trying to route packets from the remote 192.168.168.0/24 (192.168.168.222/32?) to the local 192.168.0.0/20 and vice versa.

I could still be wrong though, because the wireless network is managed via DHCP through the UTM, and the local network of 192.168.0.0/20 is managed via a DC's DHCP/DNS server.  An extra hop or three.

Regarding the "Find network path," forgive me if I haven't provided what you're looking for.  I tried a few, starting with a DC:

I'm sorry, but I get a bit lost in all the different subnets and start loosing the overview of what is located where. But since you are mentioning other DHCP servers involved; do these other DHCP servers hand out a default gateway that is either the Sophos UTM (on that side of the connection) or the Sonicwall (on the other side of the connection) or are more routers involved inbetween your hosts (other than the UTM and the Sonicwall).

If more routers are involved, all of them should know how and where to route packets to other networks....

Maybe adding a network diagram where you list all the subnets on both sides of UTM and Sonicwall could enlighten a bit.

Yes, sorry for the confusion.  If it's frustrating to someone who knows the network, I can't imagine your frustration coming in cold.  Thanks again btw.

I seem to have gotten it figured, if only by bashing my keyboard in random sequence.  As mentioned in my last post, I told my SonicWall to forward literally all traffic through the VPN for the 192.168.168.222 remote host.  That along with masquerading and DNAT rules on the UTM side allow me to ping the UTM remotely, as well as browse the internet through the VPN tunnel.

The rest of the problems I have, such as failing to ping DCs let alone use them for credential authentication (no logon servers available) are likely due to another misconfiguration I should be able to sort out.

Thanks 1000x for your time.  I will post back if I run into more tunneling problems, which I probably will.

EDIT: I have remedied the remaining communication issues by following your original recommendation of disabling NAT traversal options on both appliances.  Though as I said the above NAT rules are in place manually.

And I hope I haven't used the "sugged as an answer" incorrectly.  The above configuration options seem to have resolved my issues.