3

We have 16 IP addresses from our ISP, and are setting up a SonicWall Firewall. I'd like to have the SonicWall do NAT for the LAN, but act as a firewall only (no NAT) for the servers which are using some of the 16 addresses. How do I set this up? If I set the WAN's subnet to include the 16 IPs, the SonicWall won't route the traffic to the LAN interface. Should I set the WAN subnet to only include the ones we are dedicating for NAT, and then keep the others on the LAN?

Related point: How can I set multiple IP addresses for a SonicWall LAN interface?

CLARIFICATION: The servers are not NAT'd; they're using their public IPs directly.

Improve this question
3
  • 1
    Have you read the SonicWall documentation? This is very clearly explained there. You will have a source NAT rule for standard internet access, and static one to one NAT mappings for the servers.
    – SpacemanSpiff
    Jan 16, 2011 at 17:15
  • Thanks, Tom - Can you be more specific where to look in the docs? But I'm also looking for more background: Why do I need 1:1 NAT if the servers are using the public IP directly (not a RFC1918 or Natted IP)?
    – SRobertJames
    Jan 16, 2011 at 18:36
  • It has to do with routing and ARP: you could physically put the servers on the outside beside your firewall (on a switch) and give them those IP addresses because they would respond to ARP requests for some.public.ip.address, but you'd a) have to set their gateway as your next-hop gateway (provided by your ISP) b) you'd have no benefit of a firewall save for any host-based firewalls the servers are running.
    – gravyface
    Jan 16, 2011 at 20:25

2 Answers 2

Reset to default
6

As Tom suggested in the comments, what you need to do is setup a static 1:1 NAT for your (I hope) DMZ'ed public-facing servers. Your source NAT (many-to-one likely) will allow your LAN subnet to NAT out as one of your /16 accordingly.

For example:

  • LAN subnet: 192.168.0.0/24
  • DMZ subnet: 192.168.1.0/24
  • WAN subnet: 200.200.200.0/16

By setting up your LAN and your DMZ networks on separate subnets (whether you use VLANs or a separate interface on your firewall; it should have a "DMZ" or "Optional" interface), which are routed and filtered by your firewall, you can now setup 1:1 NAT to statically assign a DMZ address to a public address, but also have filtering setup to permit inbound traffic from the Internet and from your LAN (and vice-versa, say if one of your servers needs to talk to a Domain Controller internally) on only the ports and source IP addresses you wish.

To the rest of the world, your servers appear to be on the "outside", but they're really isolated to/from the Internet and to/from your LAN, improving security by allowing you to create inbound rules for Internet traffic but also outbound rules to say only permit a Webserver from accepting established inbound 80/443 connections, but not allowing it to initiate outbound connections to any TCP/UDP port (and thus adding a layer of defense against zombified botnet traffic, or spam bots, etc. should your Webserver because compromised).

If your servers are NOT behind your firewall, you get no benefit of firewalling, centralized firewall logging, etc. and that's not a Good Thing.

Improve this answer
5
  • Right. I should clarify: We are migrating a legacy system and need to keep the public IP as is on the servers. Of course, with new systems NAT is best; but the constraints are clear here.
    – SRobertJames
    Jan 17, 2011 at 0:16
  • But you understand that with 1:1 NAT, nobody will know the difference; it'll appear as though it's on the outside. Obviously that would require changing the IP on the NIC and/or any other configurations where the IP was set, but this should be negligible.
    – gravyface
    Jan 17, 2011 at 0:48
  • any computers on the inside might know the difference when the servers change IP address. It's also conceivable that the IP can't be changed for some random reason like the software is licensed for a particular IP.
    – Chris S
    Jan 17, 2011 at 4:35
  • @Chris S: you're right, but he's still going to have to cross that bridge because he has to change them to something else anyways.
    – gravyface
    Jan 17, 2011 at 14:46
  • That's similar to how we do it. We have our WAN interface into our SonicWall NSA 3500, with something like a 200.200.200.0/28 subnet. Then each server we have behind the sonicwall has it's own 192.168.10.0/24 address. We then do 1:1 NAT for each server and it's public IP, so 200.200.200.5 is NAT'd to the 192.168.10.5 server. 200.200.200.6 is NAT'd to the 192.168.10.6 server. This way, the world sees each server as a public facing server out on the web when in fact they're sitting behind a firewall and they themselves have a private IP address. In your case with a bigger LAN, use the DMZ idea.
    – Safado
    Dec 13, 2011 at 14:58
1

Digging a bit further (and taking a step back to think about this), you could do a transparent subnet gateway with proxy ARP as described in RFC 1027 and also in this KB document from SonicWall. I'm not sure if your firewall is one of the supported models, but this should work for you.

EDIT: depending on what you're doing, you might need to use Layer 2 Bridging mode vs. Transparent mode; see this document for a comparison of the two.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .