Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

TL;DR Can a Sonicwall TZ200 series port-forward to a host not on the local internal subnet? If so, can that host be one accessed through a VPN tunnel with the Sonicwall as one endpoint?

We have an application running at a remote (third-party) site that we'd like to make available from outside the office networks. Setting up direct access to that site may be possible, but for a couple of reasons we'd like to funnel that traffic through the main office site if possible. There is an always-up IPSEC VPN between the sites, and the systems involved are all Windows-based servers. The third-party router is a Cisco/Linksys RVxxx.

I know I could probably do Rube Goldberg-ish things involving SSH tunnels from internal Linux boxes, but I'd either suck it up and relocate the server or get it opened up at the third-party site before doing anything like that.

Basically what I'm wondering is

  1. Is it possible?
  2. Is it feasible - maintenance nightmares, mystery connections and instability would all be problems, and even if I document an obscure and esoteric configuration (see SSH above), nobody reads documentation.
  3. If it's both possible and feasible, how should I be setting it up? I assume I'd be dealing with the NAT and Access Rules, anything else? My VPN experience is generally with site-to-site tunnels on routers with less configurability than Sonicwalls.
  4. What are the catches (e.g. the problem with spoof detection dropping packets that someone ran into with A-B-C routing)?

This question is similar to Client access cross location through VPN tunnel, but I'm not finding the sole answer to that one particularly useful and I'm unconcerned about DNS and WINS in this case.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

This is in fact both possible and feasible. Here's how I set it up for OWA access to an Exchange server that's currently hosted but will eventually move onsite. Port 443 was already in use so this also involves shifting Exchange 2007's OWA to respond on 40443. I had originally planned to also remap from 40443 (in the real world) to 443 (internally & over VPN), but decided I was just asking for trouble.

In the Network/Address Objects area, defined an Address Object for the specific remote machine, RemoteExchange on 10.11.12.13/255.255.255.255 as a Host in the VPN Zone.

In the Network/Serices area, defined a service RemoteOWA40443 as TCP with start and end ports of 40443.

In the Network/NAT Policies area, created a policy with

  • Source
    • Original: Any
    • Translated: Original
  • Destination
    • Original: WAN Primary IP
    • Translated: RemoteExchange
  • Service
    • Original: RemoteOWA40443
    • Translated: Original
  • Interface
    • Inbound: Any
    • Outbound: Any

In the Firewall/Access Rules, added an Allow rule

  • From Zone: WAN
  • To Zone: VPN (we're using IPSEC, this might be SSLVPN for other sites)
  • Service: RemoteOWA40443
  • Source: Any
  • Destination: Any
  • Users Allowed: (up to you)
  • Schedule: (up to you)
  • Comment: Redirect Exchange OWA from our address to hosted server (Really, use these comment fields - you'll thank yourself when you're reviewing & maintaining)
  • Enable Logging: Checked (I originally added multiple rules using All Zones for the From and To, then removed the rules with no traffic after I'd tested).

On the Exchange side this required changing the SSL port that it was listening on in the IIS Admin properties for the Default web site, setting the External host name for Outlook Anywhere, and setting the External URL for OWA to include the :40443.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.