sonicwall log shows that is is pushing traffic out of 172.31.0.1 and that is where is should be going.

It really sounds like a routing problem. As soon as you plug in a laptop that has a default gateway of 172.31.0.2 you can hit your webserver. Check the routing tables on the SonicWall to be sure it knows how to get to 10.1.1.1. You said it reaches 172.31.0.1. So, what happens after that? Another good TS'ing step would be to setup a capture on the 172.31.0.2 interface to see if the traffic is actually getting that far. If it does then see if the traffic reaches the webserver with Wireshark/tcpdump on the webserver. If it does and you see the return traffic trying to go back maybe you don't have the routes setup properly on the ASA. Does the ASA know to get to the internet (default route)? Follow the packet.

Another thing it could be is internet traffic isn't allowed through the ASA. I know you said a laptop with the IP 172.31.0.1 can hit the webserver... maybe you have allowed the network with 172.31.0.1 and not internet traffic. Also, does the SonicWall allow the network with 10.1.1.1 to the internet? It's been a while since I've messed with a SonicWall but I think you'll have to add that as a "trusted source" (or something similar) to allow traffic to pass. Same with the way in. Does the SonicWall allow internet traffic to destination IP 10.1.1.1?

Too many variables. Sell the SonicWall on eBay. ;)

Ok, here is a better drawing of what I need to do. This is driving me nuts and I know is should be possible, but I am fairly new at this.

That's a good drawing. Did you happen to get a capture on the 172.31.0.2 interface or webserver? We need to make sure the packet is getting to the ASA or webserver. If it is then we can focus on the ASA.

Also, I don't really understand how your SonicWall knows traffic from 216.x.x.1 is NAT'ed. By the time the SonicWall gets the packet it should already be NAT'ed by the Adtran so, the SonicWall would see a packet that has a source address of the person on the internet making the request and a destination address of 192.168.0.2. It shouldn't see the destination address of 216.x.x.1 if the Adtran is doing the translation. Here's how it would work:

Let's say someone is on the internet with IP address 5.5.5.5. They make a request to your webserver at 216.x.x.1:80. So, the packet would look like:

src: 5.5.5.5:5464 dst: 216.x.x.1:80

(**note, I made up the source IP and port)

Once the Adtran sees the packet it will change the dst address to 192.168.0.2:80. So, the packet will look like the following when the X1 interface on the SonicWall gets it:

src: 5.5.5.5:5464 dst: 192.168.0.2:80

Now, assuming the SonicWall has a route to the 192.168.0.2 network and is allowed to send packets there it will route the packet to E0/7. When E0/7 gets the packet it will look like:

src: 5.5.5.5:5464 dst: 192.168.0.2:80

Once E0/7 gets the packet it will see 192.168.0.2 is on a connected interface and send the packet out E0/6 (assuming it is allowed to).

Let's get a capture on the E0/7 interface as well as the webserver and we'll be able to see what's going on a little better.

Ok, I've got my NAT working from the ISP. The Sonicwall is forwarding traffic to 192.16.0.2 like is should. On the ASA I am getting this each time I try to browse to my webserver.

A duplicate TCP SYN was received during the three-way-handshake that has a different initial sequence number than the SYN that opened the embryonic connection

Does the packet get to the webserver?

It looks like it does, but I don't get my webpage. I think this message is because it is a multihomed server. Is there a way to bypass this message for this one server?

Deny TCP (no connection) from 172.16.0.2/80 to 216.48.9.65/24496 flags SYN ACK on interface inside

Setup a sniffer on your webserver and see if the packet gets to the webserver. I don't know what to do about the error you're getting. To me the error looks like the SYN/ACK packet isn't getting back to the client therefore the client is retransmitting the SYN. Maybe someone else can clarify. At this point we have no idea where it's failing. Setup a sniffer on the webserver. We need to follow the packet to see what's going on.