1

We have a SonicWall TZ 400 with a Comcast Modem in Bridge Mode. Everything works fine, except the fact that the exposed services on the LAN couldn´t be reached using the public IP of the WAN from the LAN zone.

We tried these steps with NAT Policies but doesn´t work.

https://www.sonicwall.com/en-us/support/knowledge-base/170505780814635

This is the NAT policy configured only for test the access of the dot200 Services:

NAT Policy

These are the firewall rules WAN-LAN:

enter image description here

This is the only LAN-WAN rule configured:

enter image description here

Monitoring the packets we have this log:

*Packet number: 1220*
Header Values:
 Bytes captured: 62, Actual Bytes on the wire: 62
Packet Info(Time:01/25/2019 12:53:49.112):
 in:X0*(interface), out:--, DROPPED, Drop Code: 717(Packet dropped - Policy drop), Module Id: 27(policy), (Ref.Id: _2118_qpmjdzDifdl), 2:1)
Ethernet Header
 Ether Type: IP(0x800), Src=[b8:ca:3a:9a:83:69], Dst=[xx:xx:xx:xx:xx:xx]
IP Packet Header
 IP Type: TCP(0x6), Src=[10.1.10.6], Dst=[xx.xx.xx.xx]
TCP Packet Header
 TCP Flags = [SYN,], Src=[61006], Dst=[81], Checksum=0x7bd7
Application Header
 Not Known

What we done wrong?

Improve this question
18
  • Not only do you need to forward port through NAT, but you are going to need to create firewall rules to allow traffic originated from outside to inside. Firewalls default to blocking all outside originated traffic.
    – Ron Maupin ♦
    Jan 25, 2019 at 18:30
  • You should consider using split-brain DNS so you can bypass the firewall from LAN.
    – Zac67 ♦
    Jan 25, 2019 at 18:36
  • 1
    If you are doing LAN-to-LAN traffic, then your traffic will not pass through the firewall because it should never be routed. Your firewall rules and NAT are for traffic from the outside to the inside, not inside to inside. Traffic on the inside to the inside should use inside addressing, not the outside addressing.
    – Ron Maupin ♦
    Jan 25, 2019 at 19:16
  • 1
    "Basically the traffic is LAN-LAN the only fact is we want to use the public IP of the WAN to access the services. No, you don't. That causes suboptimal routing and places an unnecessary burden on your firewall. You want your internal DNS to translate to the internal services addresses. You can ask about that on Server Fault. If you insist on doing it the way you are trying, then understand that is a rookie mistake, and you need to search for hairpin routing.
    – Ron Maupin ♦
    Jan 25, 2019 at 19:24
  • 1
    @Joseph "Split-brain DNS" is pretty simple, it just requires you to run some kind of DNS service (off-topic here). On that, you enter an A record for e.g. www.example.com -> 192.168.0.10 and that's it.
    – Zac67 ♦
    Jan 25, 2019 at 19:35

1 Answer 1

Reset to default
3

It sounds like what you want is hairpin routing. This is not a good idea because it is suboptimal routing, involving NAT (a kludge that should be avoided whenever possible), and it unnecessarily burdens your firewall and slows your communication.

If you really want to do it, there are documents describing how. For example, this one:

Configuring access to a server behind the SonicWall from the LAN / DMZ using Public IP addresses

Last Updated: 12/6/2018 35339 Views 101 Users found this article helpful

Description

This document describes how a host on a SonicWall LAN or DMZ can access a server on the SonicWall LAN or DMZ using the server's public IP address or FQDN.

This document describes how a host on a SonicWall LAN can access a server on the SonicWall LAN using the server's public IP address (typically provided by DNS). Imagine a NSA 4500 (SonicOS Enhanced) network in which the Primary LAN Subnet is 10.100.0.0 /24 and the Primary WAN IP is 3.3.2.1. Let's say you have a Web site for your customers, and its hostname is . You have already written the policies and rules needed so that outsiders can get to the web site, but it's really running on a private side server 10.100.0.2. Now imagine that you are a person using a laptop on the private side, with IP of 10.100.0.200. You want to reach the server using its public name, because you do the same thing when your laptop is with you on the road. If you sit on the private side, and request http://www.domain.com>, loopback is what makes it possible for that to work, even though the server is actually right next to you on a local IP address.

To allow this functionality you need to create a loop-back policy.

Resolution

The idea behind this policy is that you must translate your source into a public object if you wish to talk to the public IPs from the LAN.

  • Login to the SonicWall Management GUI.
  • Navigate to Manage | Policies | Rules | NAT Policies submenu.
  • Click on the Add button.
  • Create the following NAT Policy.
  • Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
  • Translated Source: WAN Interface IP
  • Original Destination: WAN Interface IP
  • Translated Destination: (LAN server object)
  • Original Service: Any
  • Translated Service: Original
  • Inbound Interface: Any
  • Outbound Interface: Any

enter image description here

Improve this answer
2
  • Definitely, hairpin routing is not the best choice. I like to do things right from the start.
    – José Miguel Rodríguez García
    Jan 25, 2019 at 19:40
  • Then you should accept this answer because it answered the original question so that the question doesn't keep popping up forever, looking for an answer. You can then ask about setting up DNS on Server Fault. Unfortunately, server configurations and protocols above OSI layer-4 are off-topic here.
    – Ron Maupin ♦
    Jan 25, 2019 at 19:48

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.