If your ISP assigns you multiple IP addresses and you can route them to the WAN IP on the SonicWall, you can create additional one-to-one NAT policies. Those NAT policies can point to services running on non-standard ports on the internal server.
Let's say that you run Apache on port 8080. You could set that up as a service on the SonicWall and then make that service the translated service for the policy. The original service would be HTTP (port 80). The original IP for the policy would be one of the routed IPs and the translated IP would be the server's private IP address. You of course need access rules to go with the NAT policies.
A variation on this would be to give the server a second private IP and then bind Apache to port 80 on that IP address only. That second private IP would then be the translated IP for the one-to-one NAT policy. This can make things a little easier on internal users who would otherwise have to add the port number to the Apache-served URLs.
Toward the same end, you can create a DNS loopback on the SonicWall so that internal clients can access the server using the external address/port. This eliminates the need for split DNS and multiple IPs on the server.
Please note that I am basing all of this on the version of SonicOS that I run on my company's Pro 2040: 4.0.0.1-49e (e=Enhanced). Not all versions of the SonicOS will work this way. The SonicWall web site has documents on all of this.
As for the ADSL router, what is the method of connection? Bridged? Routed? PPPoE/PPPoA? If your SonicWall is a NAT client to the ADSL router, there may be a better way to do things. Ideally, you want that ADSL router operating as a bridge so that the SonicWall can pick up all those IPs, the first of which being its WAN IP and the rest of the IPs being routed to the WAN IP. The private IPs should all be behind the SonicWall, if possible. At least that's how I would do it.
Dave  |