For this, you would need to create a Static Route to redirect all the traffic going from the devices behind the Sonicwall towards the XG, I would recommend you to connect to create a new interface in your XG and in the Sonic Wall, (avoid sending back the traffic to the switch where both devices are connected to LAN side) so in the Sonicwall you can create ...
You have two SSL connections here. One between the app and the netscaler, and second from the netscaler to the api service. The netscaler has no idea what the api service is going to require, so makes no demands of the app connection. When the api service asks for a client certificate, it's too late to ask the app, thus a re-negotiation is necessary but ...
It's a bug in "Cisco Packet Tracer" that causing NAT to no work properly.
See here: https://community.cisco.com/t5/routing/packet-tracer-asa-nat-problem/td-p/3936024
(Some workarounds are given in above link)
A simple solution (not ideal) is to use Router for NATing (the so called traditional way).
It's not just NAT but also routing in your case.
For NAT this should do:
nat (inside,outside) after-auto source dynamic any interface
For routing you will need to route "inside" networks to your inside router:
route inside 192.168.10.0 255.255.255.0 172.16.0.1
route inside 192.168.20.0 255.255.255.0 172.16.0.1
route inside 192.168.30.0 255.255.255....
allow for traffic between a DNS from a LAN (IP address) to a DNS server at (IP address)
permit udp <LANIPaddress> <LANIPwildcard> <DNSIPaddress> 0.0.0.0 eq 53
permit tcp <LANIPaddress> <LANIPwildcard> <DNSIPaddress> 0.0.0.0 eq 53
ping from a host PC (IP address) to any destination
permit imcp <hostPCaddress> 0.0.0....