1

Our small business uses a Sonciwall TZ210 on a fixed IP line in our office, subnet for this location is 192.168.3.0. This is connected to a Draytek 2850 router at my home address using an IPSec VPN tunnel, local subnet is 192.168.1.0.

I have a FreeNAS file server set up at my home address that hosts some files and stores backups. Out of necessity I now need to provide one of our suppliers with access to a file the sits on the FreeNAS box at my home address using SSH.

My intention is to use the public IP address of the router at the office to provide SSH access to the private server at the home address.

I have followed instructions on Sonicwall's site to configure the TZ210 to allow traffic from the WAN zone to the VPN zone for this service, and secondly to translate the source traffic from a WAN IP to a LAN IP so that it can traverse the VPN tunnel.

Whatever I try, the connection is refused when attempting to connect from the WAN zone. I can however access the server using the public IP address of the router from an office-based PC on the 192.168.3.0 subnet with a suitable NAT policy set up, however the auth log on the server does not show the translated IP (which should be the router), it shows its actual private address. With no NAT policy it doesn't work at all from that location.

I'd like to know if I'm missing any setup steps to get this working, or whether I've misconfigured something. I'm convinced there is an issue with NAT because the server log shows the original IP rather than the translated IP, but I don't understand why.

Pictures of both the NAT policy and firewall policy attached. Any help is appreciated.

NAT policy Firewall rule

Improve this question
5
  • You should edit your question to include the full text configuration of the SonicWALL (you can obfuscate the passwords and public addresses), not the GUI images. Use the preformatted text feature ({}). Network engineers prefer to use the CLI instead of the GUI.
    – Ron Maupin ♦
    Jan 20, 2018 at 17:45
  • From the NAS's perspective the traffic MUST come from your Office subnet (192.168.3.0/24) - even if you put your VPN into route/interface mode and allow 0.0.0.0/0 across the tunnel since your NAS's gateway is the Draytek router at your house, and unless you have a Policy Based Route sending the NAS's traffic over the VPN, the traffic with exit the Draytek's WAN interface and not the VPN. Ron is right, you will need to post more information about your setup on both sides. Why not just publish the NAS externally at your house using your Draytek instead of over the VPN?
    – PSaul
    Jan 21, 2018 at 4:57
  • How can this be the case when accessing the server using the office site's public IP address from within the office network? There is no route from the Draytek WAN to the private IP on the office site in question outside of the VPN, so it has to be that the NAT'd traffic is routing properly. All the same rules should apply for traffic reaching the public IP of the WAN from the WAN zone by my reckoning? I'll try to get some info when I'm in the office shortly. Thanks for help so far guys.
    – RapidScampi
    Jan 22, 2018 at 8:00
  • the home site uses a dynamic DNS service and I don't want to give this out to partners. Given that it's permanently connected to the main site I thought it would just be a case of setting up a few rules to enable this!
    – RapidScampi
    Jan 22, 2018 at 8:15
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin ♦
    Feb 21, 2018 at 18:16

1 Answer 1

Reset to default
1

Your security rule is wrong. The zone evaluation is POST-NAT. So, after applying NAT, your new IP packet have a source_zone=LAN and a dest_zone=VPN. However, you set WAN->VPN.

Change the source zone from WAN to LAN and try again.

(Using packet monitor would be also useful to troubleshoot the connection).

Improve this answer
4
  • I followed the giude here sonicwall.com/en-us/support/knowledge-base/170505256117325 which says VPN. I also drew the conclusion that the rule should be WAN to LAN and so added an access rule for this anyway, and it did not have an effect.
    – RapidScampi
    Jan 22, 2018 at 8:07
  • If you use Packet Monitor, do you see the packet arriving from your public external IP? Do you see the packet being NATted? Do you see the packet tranversing the Firewall to the VPN?
    – KorXo
    Jan 22, 2018 at 13:45
  • I just ran a PM and for the working connection it says (summarised, but in order): IP Type: ESP(0x32), Src=[OfficeWANIP], Dst=[HomeWANIP] IP Type: TCP(0x6), Src=[192.168.3.133], Dst=[OfficeWANIP] IP Type: TCP(0x6), Src=[OfficeWANIP], Dst=[192.168.3.133] Just running the same for the connection that's not working.
    – RapidScampi
    Jan 22, 2018 at 14:41
  • 1
    Thanks for your help with this. I was able to use Packet Monitor to determine the problem. It turns out that I'd set up the NAT rule to "firewalled subnets" as the source (192.168.3.0) instead of "any", so it was blocking any WAN traffic. All workin!
    – RapidScampi
    Jan 23, 2018 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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