• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4411
  • Last Modified:

Unable to externally access Synology DS1512+ via NAT and Static IP on SonicWall NSA 3500

I have an external IP NATing to an internal IP. I have verified the NAT is working by pointing it to an internal PC and testing various ports (mainly 6690, Synology's Cloudstation port). Currently for testing, I have all ports open for this IP so I do not think it is a port issue.

Internally the synology DSM and Cloudstation are accessible. The SonicWall and Synology syslog logs are surprisingly not of much help. I also called Synology and worked through some of their pre-tech support steps and ultimately they were not of much help other than to suggest buying a low-end home-based router.

Any help would be greatly appreciated,
Sean
0
Sean_Murphy
Asked:
Sean_Murphy
  • 11
  • 5
  • 4
  • +1
4 Solutions
 
Henk van AchterbergSr. Technical ConsultantCommented:
when you open 5000 from the outside to the synology, can you access the webinterface from the outside?
0
 
Sean_MurphyAuthor Commented:
I cannot. Externally, port 5000 is open just like 6690 but I can't access the DSM or the cloudstation.
0
 
Henk van AchterbergSr. Technical ConsultantCommented:
In the sonic wall did you open the port in the NAT section AND in the firewall (access rules) section?
0
Network Scalability - Handle Complex Environments

Monitor your entire network from a single platform. Free 30 Day Trial Now!

 
Sean_MurphyAuthor Commented:
I want to say of course, but since it isn't working...
For this issue, I'll use these dummy IPs in this thread:
10.10.10.5 = internal IP of Synology
25.35.45.55 = external static IP assigned to the Synology

Here are the NAT Policy rules:
NAT Rule #1
Original Source: 10.10.10.5
Translated Source: 25.35.45.55
Destination Original: Any
Destination Translated: Original
Service Original: Any
Service Translated: Original
Interface Inbound: Any
Interface Outbound: Any

NAT Rule #2
Original Source: Any
Translated Source: Original
Destination Original: 25.35.45.55
Destination Translated: 10.10.10.5
Service Original: Any
Service Translated: Original
Interface Inbound: Any
Interface Outbound: Any

Here is the Firewall Access Rule:
From: WAN
To: LAN
Priority: 31 (FYI, the deny priority is 33)
Source: Any
Destination: 25.35.45.55
Service: Any (Ultimately, this will just be Synology ports like 5000, 6690, etc)
Action: Allow
Users Incl: All
Users Excl: None

Thanks for your attention to this thread, henkva.
Sean
0
 
akahanCommented:
I'm not positive, but in the Firewall Access Rule, shouldn't the destination be 10.10.10.5 rather than 25.35.45.55?
0
 
Sean_MurphyAuthor Commented:
akahan, I do not believe so as the destination in this case is the destination the user is accessing, which is the external IP. The NAT rules then handle the translation of that data. That said, I tried it with 10.10.10.5 with no luck. I also tried having a Firewall rule for both 10.10.10.5 and 25.35.45.55. No success there either.
FYI, I have this sequence of NAT/Firewall rules for over a dozen other Windows and Linux servers and it works well translating all ports from the external IP to the internal IP. Just not for the Synology. I was hoping I was just missing something when it comes to "Port Forwarding" vs. NAT.
A second FYI, if I change the internal IP address in the NAT rules to point to an internal Windows pc, e.g. 10.10.10.6, running a service on port 5000 or 6690 and then go to http://www.yougetsignal.com/tools/open-ports/ to check the status I see the ports as open. However, when the NAT rules connect to the Synology that test shows the ports closed even though I know they are open because I can connect via the internal network.

Thanks for the assistance,
Sean
0
 
akahanCommented:
By any chance is the IP address from which you're doing the testing listed as among those which have been "auto-blocked" by the Synology in Control Panel/Network Services/Autoblock?
0
 
Sean_MurphyAuthor Commented:
No, and after I checked per your request I have disabled Auto-block altogether.
0
 
akahanCommented:
I am unable to think of any setting on the Synology that would cause it to treat packets from the WAN differently from packets from the LAN, other than auto-block.

Are you able to temporarily put the Synology in the DMZ on the SonicWall (or temporarily connect the Synology upstream from the SonicWall) to determine whether the SonicWall or the Synology is the problem?
0
 
Blue Street TechLast KnightCommented:
Hi Sean_Murphy,

Use the Public Server Wizard located at the top right named Wizards. Once the Wizards' pops up, select Public Server Wizard, Next then for Server Type select Other and specify the custom Service Objects under Create New Service or Group. This will auto create all the necessary NAT Policies and Access Rules needed for communications to flow. Here is a step-by-step: https://www.sonicwall.com/us/en/support/2213.html?fuzeurl=https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.asp?kbid=7027

It is a recommended best practice for setting up public servers.

Verify both the Synology DSM and Cloudstation are located in the LAN Zone.

Let me know how it goes!
0
 
Sean_MurphyAuthor Commented:
My apologies. I have been unable to attend to this until today. I will try the suggestions above and report back.

Thanks for your attention to this!
0
 
Sean_MurphyAuthor Commented:
diverseit, I deleted all the rules I had in place for the Synology and then setup the Synology using the wizard as you suggested. It still does not create a connection. I even tried to create a connection for the second NIC2 hoping it was related to the first NIC I was using for the private/public NAT but no avail. I can't help but think this is Synology related since changing the private IP to an internal pc (instead of the synology) verifies that the ports are indeed being properly translated.

Thoughts...
0
 
akahanCommented:
In the Synology's firewall (Control Panel/Firewall and QOS), under Allow/Deny, do you happen to have any rules there, or, alternatively, if there are no rules, is "Deny access" selected at the bottom of the page?
0
 
Sean_MurphyAuthor Commented:
No, All rules are disabled and each NIC has the option of Allow all if no rules match.
0
 
Blue Street TechLast KnightCommented:
Can you enable ping on the SonicWALL Interfaces or Access Rules in question and ping the devices' IPs?
0
 
Sean_MurphyAuthor Commented:
Under Interfaces the only option regarding Ping I see is under Management (States Allow Remote Management through Ping). Is this what you're referring to? In the Access Rules, all services are allowed for this IP. FYI, I am running SoincOS 5.9
0
 
Blue Street TechLast KnightCommented:
Yes, you may need to create an Access Rule in order to test ping...like WAN>LAN, service Ping. This is obviously only for testing so you limit your access by IP or simply remove thereafter your testing is complete.

BTW: Also, it's a security best practice to place public facing servers/resources in the DMZ rather than LAN that way if compromised the threats are isolated.
0
 
Sean_MurphyAuthor Commented:
Can Ping be disabled elsewhere in the SonicWall? Creating an Access Rule like the one you suggest doesn't work for any IPs even if I set the rule to allow from all WAN to all LAN.
From>To            Priority          Source     Destination      Service      Action      Users Incl Users Excl.
WAN>LAN      4            Any            Any                  Ping            Allow      All              None
0
 
akahanCommented:
Is there a way you could temporarily bypass the SonicWall for the Synology and expose the Synology box directly to the internet, so you can determine whether the problem is with the SonicWall or the Synology?
0
 
Blue Street TechLast KnightCommented:
OK. Delete that rule you created and follow the steps below:
1. Go to Network > Interfaces.
2. Click on the Notepad icon in the Configure column for the WAN or other Interface you want to configure.
The Edit Interface window is displayed.
3. To enable Ping on this interface, scroll down to Management and select the Ping checkbox.
4. Click OK.

Enabling Ping in this manner will automatically create the appropriate NAT policies and Access Rules.

This the default standard for enabling Ping. Let me know if you are still having issues, which could be an indication of other issues related to the firewall.
0
 
Sean_MurphyAuthor Commented:
I was able to expand the logs pushed to the syslog server. As a result info that used to look like
src=93.104.115.116:50495:X1 dst=25.35.45.55:6690:X0
now looked like
src=93.104.115.116:50495:X1 srcZone=Untrusted dst=25.35.45.55:6690:X0 dstZone=Encrypted
All successfull traffic had a dstZone=Trusted
Following this rabbit hole lead to me to discover that a group of 10 LAN IPs, 10.10.10.5-10.10.10.14, were assigned to a L2TP IP Pool which is in the VPN zone instead of the LAN.
I reassigned the private LAN IP of the Synology to one outside this pool, recreated my original NAT/Access rules and all is now working as originally expected. Geesh :) Regardless, it's an early Halloween treat!
Thanks to all who assisted on this. I'll mark answers appropriately.
Sean
0
 
Sean_MurphyAuthor Commented:
Although the solution to this particular problem was not directly solved by those who participated in this resolution, the comments marked as assisted solutions are typically the way this problem would have been resolved.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

  • 11
  • 5
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now