_only_? That’s, give or take, ⅓ of the full range. If everything in your network did something similar, you couldn’t have more than 3 devices in your network (and with 3, the stars would have to align for there to be no overlap between the ranges. If, for example, your tv needs 15000-35000, the largest contiguous range remaining would have about 15000 ports.
Try getting ~10 years old uplay game to work and despair. Not sure what network engine they used at the time but there is an entire set of games that basically can't connect properly without using random ports anywhere in the 10k/60k range, it's ridiculous.
And let's not ever talk about two people in the same home playing the same game together. I loved splinter cell blacklist's multiplayer but damn did it take long to get anything connected.
I'm not even sure why I mean this was with internet gaming already being the norm, I assume it's because they made games for console and then ported, and on console port issue are handled for them or whatever ? Anyway this was stupid
"And let's not ever talk about two people in the same home playing the same game together."
This is my fiance and I constantly struggling with Halo:MCC. At least once a night one of us fails to join a game, and I'm convinced it's some poor NAT punch through solution that doesn't always work.
Most readers of HN will understand (or at least understand the goal of) the checklist for debugging network issues.
Skipping straight to Port Forwarding eliminates any issues on whether UPnP is actually working correctly. Growing up, some of my friends had routers struggled to handle UPnP correctly. If I knew they were the only one needing port forwarding, I'd simply turn that on for them instead of trying to figure out if UPnP was actually working correctly.
Even a restricted NAT should allow for this without explicit port forwarding configuration?
Unless you're doing something like active FTP where it's replying to a different port than the one the request originated from. Which would be a interesting choice for a console designed in like 2018.
It’s a firewall thing not a batting thing. You need a stateful firewall to do that kind of smart port forwarding. Which, to be fair, all consumer routers should have.
Stateless firewalls, however, need to have explicit rules for UDP traffic. So that’s what Nintendo are addressing here.
NAT functionality especially for UDP can be incredibly flaky in a lot of consumer hardware, mangling payloads, randomly dropping associations or having extremely short timeouts, and other plain buggy behaviour.
Although I will say that if you are forwarding all ports, at least it’s to a device you know about. Not some random IoT or PC software or whatever opening up ports without your knowledge.
Using DMZ doesn't completely solve my problem, the AT&T gateway is still routing every packet (at less than line speed) and randomly dropping some of them.
UPnP is a security risk (as is forwarding all UDP ports to a single device). Nintendo should set up STUN servers so the Switch can do UDP hole punching.
Enabling UPnP on your router enables a malicious app to permanently forward ports from the outside to the inside. The malicious app could also forward ports to other devices on your network. For example, installing a bit of malware on your laptop could set up a port forwarding rule from the internet to your NAS's web interface.
UDP hole punching via STUN requires continuous work on the part of a malicious app to keep that port open. Work that could be noticed much easier than a rogue UPnP-using bit of malware. And it can't open ports to other devices on your network.
The most common problem I have seen over and over is double NAT or CGNAT. For the home networks I manage (my parents, in-laws, and my own), I put the ISP modems in bridge mode or passthrough mode.
It's pretty good advice, if you're Nintendo and spending a fortune trying to provide support advice to people with crappy router config/connections. Yes it's entirely likely to cause other problems - but probably going to get that switch working.
Other problems will go to other vendors - and if their advice stops your switch from working, that's on them.
Exactly. Just like on the Apple's website: "If someone starts shooting at your iPhone: guard it with your body. Layers of tissue and fat should prevent the bullets from scratching iPhone's screen."
It's not on their website - all bullets know that even scratching an iPhone offends Jony Ives design sensibilities so if someone is shooting at you, show them you've got an iPhone and the bullets will refuse to leave the barrel.
I guess they don't like it.
If the device is not broken, but the user is dead, they have fewer consumers and more good devices in the secondhand market, no profit.
But if the user survives and the device is broken, he or she continues to buy Apple products, at least the next one immediately, profit!
This seems like an obvious case of Support-Team knowledge topic: people are having issues with their switch getting on to the Internet, here is a support article describing a one size fits all solutions. But as a network guy I hatte the assumptions they made. It's the same as telling a user: Just disable the Firewall and it will work.
I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
Something like putting your Switch on a /30 or Configuring DHCP to assign IPs in decreasing order.
> I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
The very first question they ask on the page explaining how to find the network information [1] is which operating system is the client using. The choices are Windows 10, Windows 8, Windows 7, and Mac OS. I would bet that a significant portion of HN readers have already subverted that question before it was asked.
A shocking number of game publisher troubleshooting instructions include "just run it as administrator" among their troubleshooting steps, which is pretty horrifying. It's considered standard advice in PC gaming circles among the 20-and-under or tech-uneducated adult segments.
It also assumes that your DHCP range is the top half of the last byte. That's a de facto convention in consumer routers, but not codified anywhere and the kind of thing that could change and probably isn't even correct for some routers shipping today.
Definitely not codified anywhere, and not in any of the routers I’ve used (to be fair they are more prosumer).
The main dhcp server used in most routers, dnsmasq, also assigns IPs using a MAC algorithm by default for consistent IP addressing of devices in a LAN. You would need to explicitly configure it for sequential first come first serve.
Tbf, this is the fault of network people, not the poor support guys left holding the bag of shit. The whole stack is still dangerous and obscure, 25 years after the internet went mainstream. UPnP was an effort at simplifying the situation and seems to have failed, so now we're back trying to teach IT toddlers to spell "characteristic" when they don't even know the ABC (nor do they care about it). It's inevitable that shortcuts will be taken.
Just a quick advice, as I struggled with this as my daughter complained that she could not join network games in Animal Crossing because she had only “NAT Type D”.
Forwarding all these ports was the recommended solution in Nintendo’s docs. However, it did nothing to resolve this problem. What helped was to ensure not to modify source ports in the NAT setup (“static-port” in pf).
When i use routers provided by my ISP the switches always just work. when i was running pfsense (i need to set it up again soon :) ).. I just had to set a rule for them to always get the same IP and the correct NAT type and it worked perfectly.
It does make me wonder if all ISP provided routers are pretty insecure in some way?
What is this needed for? I never set up any port forwarding and don't remember having any issues with network connectivity. But then again I don't play that much online.
I came to ask the same thing - I haven't picked up my Switch in a couple of months but I never touched my router settings for this and it was always working fine. Maybe it's just something from a recent Switch firmware update? Or perhaps just for online play in specific games.
Typically you'd do this for enabling peer-to-peer connections. I run some Minecraft servers in my house this way. I have no idea what kind of peer-to-peer gaming Switch enables. Social gaming is done over the internet with a cloud subscription that costs like $20/year.
I dunno if this had anything to do with it but there is peer to peer online gaming with Divinity Original Sin 2, and I tried grouping up with many folks I friended online and not in the same time zone and it never worked for us. Borderlands also appears to use peer to peer connections.
Yeah this is what I thought, I remember fiddling around with this to make Soulseek (or something) work on my old Linksys WRT54G back when I was at university. I wonder what Switch services/games work this way
My s/o and her sister (CS student) regularly play Animal Crossing over the Internet. I (and the SIL) wanted to curse Nintendo to hell and back for requiring users to essentially put their Switches available to the wide Internet (meaning, as long as the Switch is powered on, any RCE exploit on the Switch turns it into a full, unrestricted gateway into my home network!) simply because Nintendo doesn't want to follow basic Internet standards like UPnP or, heaven forbid, provide STUN/TURN proxies paid for by the Nintendo Online subscription.
Hell it took years for them to implement Bluetooth audio on the Switch, and that's output-only, no microphone. What stuff is their software division smoking?
They don't understand a lot of things, even some of which they've lucked into, like the competitive Smash scene. Or fan remakes and tributes (of which Sega notoriously doesn't send their lawyers after).
But they still make some incredibly compelling games.
Yes networking is def not a core competency. Strange though, the senior people are super technical (I recall the stories of Iwata writing compression algos in Pokemon)
Maybe the DNA of the company is just too focused on games specifically
This is just an aside, but this might explain why their (online) shop sucks so hard (and no browser on what amounts to a phone without a SIM card?)...
It's not just that the UX is a bit clunky, it's that it's a veritable morass of junk, a lot of which is regurgitated ports of PC titles...
They didn't understand how online shops work, to be fair all titles still at least play, but there is not as high quality control as I would have expected.
I say this as, Nintendo has a reputation and clout as a games developer (honestly none of their consoles have ever been great - they have mishaps in the software world but it is rarer), looking at their store you see a suspicious similarity to steam with sales - in fact as far as software goes a humble bundle subscription is probably a better value proposition. It's just not the rich and high quality, unique catalog people have come to associate with them. Maybe it was always like that regarding 3rd party games, but it just underlines how much they don't understand the internet...
I’ve played Animal Crossing with friends over the internet and I certainly didn’t touch anything on our router to do so. Any idea if there is a particular scenario where this becomes required?
Maybe if the network administrator has disabled UPnP that is a hint that they don't want to allow random devices to expose themselves to the entire internet?!
The buggy firmware that allowed control from outside had nothing to do with UPnP, it was... just buggy firmware implementing it wrong. And it can be easily detected with online testers.
I always leave UPnP on, and I've never seen it disabled by default, nor would I ever want them to do that.
When the router does it right, it's just a small extra convenience for malware that can only be used when they already compromised your system. If they are in your network already, they can already do whatever they want.
Malware running on your network requests port over UPnP. Router accepts it. Hacker has direct inbound access to code they control.
* Scenario 2:
Malware running on your network requests port over UPnP. Router denies it (UPnP is disabled). Malware doesn't know how to open a reverse tunnel. No inbound access.
* Scenario 3:
Same as 2, but malware sets up reverse tunnel. Hacker is in.
* Scenario 4:
Buggy and/or sloppy firmware that's not otherwise malicious requests port over UPnP even though it doesn't need to receive connections from the Internet. Router allows it. Hackers know about this slop and other CVEs on device. Network compromised.
* Scenario 5:
Same firmware from 4, but this time UPnP is disabled on router. It's safe to say this non-malicious firmware doesn't set up a reverse tunnel. No inbound access.
This is obviously a very simple threat model but from here you can see that 2 out of 5 attack scenarios would have been prevented by disabling UPnP on the router.
> Malware doesn't know how to open a reverse tunnel.
So this is useful if malware authors are just incredibly dumb?
Unconvincing. The only reason to disable UPnP seems to be "it might be really buggy" but that's true of all software and we don't disable all software. Yes, security in depth but that's taking it to a ridiculous extreme.
No, the malware authors just target the least secure userbase. Because there's plenty of them to exploit. Why put in the extra work if you have plenty of weak targets?
Physical security works the same way. The point is to have better locks on your bike than the one beside it.
And opening ports reduces the need for central infrastructure for the malware makers, which leads to less chance of being discovered (no money trails etc).
PS Speaking of run of the mill malware/ransomware here obviously. If you get targeted by state actors you can kiss your ass goodbye either way :)
It's disabled on all AT&T Residential Gateways and can't be enabled, you have to use port forwarding or put another router behind it using IP Passthrough. It's also disabled by default on EdgeRouters and can only be enabled in the ConfigTree or CLI. On UniFi it's disabled, but can be enabled in the GUI.
It's a convenience over control item. Most things do NAT traversal pretty well anyway, UPnP IGD has run it's course at this point. PCP is better in every way, push for that instead.
I don't think that's really a problem you can solve regardless. A STUN server would make most NAT irrelevant anyway. Most firewalls are setup to allow established connections, so you just need to create an outbound connection to allow the inbound. You can basically use the same techniques as SIP/RTP when they do NAT traversal.
PCP is better than UPnP IGD, most importantly because it time limits the opening so port reuse is easier. I wouldn't use either in practice. I wouldn't suggest NAT-PMP either. I wouldn't use port forwarding if I could avoid it as well. I'd use destination NAT with a source IP range I knew in advance so it wouldn't show as easily in port scans. Someone is likely to tell me why that's a terrible idea, but it's my (current) preferred method.
Malware that's already on your system can do whatever it wants. NAT punching is not some complicated dark art for people who already have working exploits...
What? It's used by tons of legitimate applications as well. Not only malware benefits from being able to accept connections from the Internet. Games, torrents and other p2p services, etc.
I play a lot of games and I've never had any issues not having UPnP. They got used to working around it. Probably with centralised servers. I never liked the P2P model anyway, dedicated servers are more fun because you can influence the gamemode, add mods etc.
For torrents I don't know... If I were to torrent I would not do it without VPN anyhow.
PlayStation is pretty bad too, they want 80, 443 (and 1935, 3074, 3478-3479), if you don't you can get all sorts of really annoying problems joining games, delays joining voice chats etc....
Yeah except of course they do not actually need most of these. It’s all BS and it’s my favorite pet peeve with port forwarding guides. For whatever reason they almost always put all ports for both incoming and outgoing traffic in a list and call it a day.
They aren't. They need _outbound_ access to TCP ports 80/443, and Sony are too cheap to hire people who actually know what they're talking about to write support articles.
Don't most ISPs already use NAT and therefore disallow all inbound traffic to devices behind it? I personally had to use WireGuard to work around it for some of my homelab servers that i wanted to publish: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
Do you mean the need to configure your CPE to allow incoming traffic to specific devices? Not really, with v6 you have to put in allow-rules too if you have the normal default-deny firewall rules in the CPE. It could be automatic with UPnP, but it could be automatic with v4 + NAT too. The article doesn't say if the Switch supports that.
In a normal NATed setup your ports are closed from the outside until a client from inside your network Starts sending packets to the outside.
The Router will keep track of network package going through to the Internet and store it in a table. in case there is an answer from outside of your network the router will look up whether a client started this conversation (there is a corresponding entry in his table) and will forward the incoming packet to the client that started the conversation.
What nintendo is asking you to allow here is to allow any outside packet coming in over UDP to get to the switch whether it first asked for it or not.
This means in practice you won't be able to run any other service which needs an UDP port fowarded in your network. It also means anyone can talk directly to your switch on any port they like whether you want to or not.
And it means, that should something ever take/get the same IP as the switch it will be exposed to the Internet directly
It's not a firewall acl, it's a port forwarding rule. In a NAT, UDP connections you initiate will be added to NAT table temporarily to handle replies. Nintendo's port range covers all the ephemeral ports that OS will naturally give to UDP connections. So your computer may attempt to start a UDP communication but the reply traffic will be forwarded to your switch instead of using NAT table. So nothing else can use UDP properly. That DNS request to port 53 has a source port of 42981 (for example), and the switch gets the reply.
I'm not sure if most routers prioritize port forwarding rules or NAT tables. That's really up to implementation.
It’s about redirecting. Following these instructions means that the Switch, and only the Switch, can receive UDP on behalf of the other network. Which will break a lot of things. Supposedly this also means that more than one Switch on the same network is a no-go.
I know very little about networking, but i know that my kids can play multiplayer at the smae time together that wont work until i set up thier NAT correctly.
My naivity says that its either NAT handles it or the swithces are choosing random ports (or maybe negotiating through plug and play).
Absolutely nothing else on the network will be able to receive anything over UDP. To begin with, this completely breaks DNS, though maybe if your devices use the router as the DNS server and it does the recursion it’ll be OK.
Next, just about all real-time communications uses UDP, so your Skype, Zoom, &c. are all broken. And it just goes on. Some, like HTTP/3, will happily fall back to TCP when they observe it’s broken (HTTP/3 will fall back to HTTP/1 or HTTP/2), but various things will just be broken.
They are talking about UDP, which is connectionless. There are just packets, going in or out. So you can send a DNS request, but the response will go to the switch, not to you.
Which is arguably a security issue if things do work as you've described.
Scenario A:
I've forwarded anything sent to UDP/80 to 192.168.1.20.
You're on 192.168.1.30 and you send a packet to 10.20.30.40:50 using UDP, source port 80.
An incoming packet from 10.20.30.40:50 now goes where? 192.168.1.20:80 or 192.168.1.30:80?
What stops me at 192.168.1.30:80 sending out packets to every IP, flooding the connection state table and effectively DoSing 192.168.1.20:80 without ever touching it?
...or should the connection actually go to 192.168.1.20:80 always, because that's what I've statically defined for all traffic on UDP/80 to do?
I guess the question is: which should take precendence, the dynamic session table, or the static configuration?
If all ephemeral ports (1024-65535) are forwarded to the Nintendo Switch, it means that the NAT gateway can't allocate ports for the other devices that require to send or receive something on UDP. Also, even if "it did only affect incoming connections", where do you expect to receive your reply if all UDP traffic is redirected to the Switch?
Sure, you can send a DNS query, but how do you propose to receive the response? The response is an incoming connection from the WAN to your router. (UDP doesn’t do sessions, remember.)
(I dunno, I’m not a network engineer, perhaps routers ignore the port forwarding and keep doing their normal NAT stuff in cases like this, but I would expect them not to because… well, you told them you wanted all the ports to go to a certain place, and nothing says UDP has to symmetrical anyway, maybe you honestly do only want tot send UDP from other machines and not receive it.)
Ehm, no? Your router still do kind-of connection tracking while NATting UDP requests to, say, outside DNS servers, otherwise UDP would not work at all in a NATted environment. There might be stupid or very stupid home routers but I'd expect the port forwarding rules to be applied only if an incoming UDP packet doesn't match any NAT connection tracking tuple in the router.
As I say, I don’t know, but I would expect port forwarding rules that essentially reserve all the ports to cause connection tracking to give up and go home. zaarn cites personal experience of this being the case on smaller ranges.
Completely up to your router’s firewall implementation whether it prioritizes explicit dstnat port forwards (as suggested in the OP) over srcnat connection tracking.
I suspect that most routers will support a “DMOZ” host, while at the same time supporting srcnat for outgoing connections, but I’m not sure whether it’ll recognize it as such when you also set a port range.
And the router has a clue about those UDP "sessions"? They're not sessions either, it's just an application declaring that incoming UDP packets with a certain destination port (and optionally destination IP, source IP or source Port) be delivered to it. Nothing about sessions.
If you send from local ip/port X to remote ip/port Y, your router will see both pairs. The router has no problem sending responses back your way after it has stored the tuple, assuming you're receiving responses on the same port you sent from. UDP connection tracking is nothing new at all.
If you haven't sent anything at all, then you're not a normal client, you're a server and need port forwarding anyway (or you're ftp and should be shot).
UDP Connection Tracking is not well implemented on all routers, more than once I've found that forwarding a UDP port makes that UDP port unavailable for other devices to use.
Yes but your router might not interact well with Connection Tracking and UDP port forwards. Especially with such wide range ones. I know more than one case where port forwarding disables connection tracking for UDP on those ports.
Switch wants all the common ports, and then some. If this is requested via UPnP/NAT-PMP via the router, other services which rely on those ports may be negatively impacted if they are not designed to allocate ports outside this range.
Switch is requesting ALL of the ports, which is going to make the above a bit difficult, to say the least.
I'll try an analogy. Your router is an apartment building. The switch is one of the many tenants. The problem: Mail for the switch does not arrive in the correct pidgeon hole of the building.
Problem one: Nintendo wants you to take your IP and add 20. So if you live in blahstreet 1 box 7, they tell you to send all Switch post to blahstreet 1 box 27. If someone else happens to own that box, bad luck for him. Worse, the IPs are dynamic via DHCP, so a box unused today may be used tomorrow. But that's the minor part.
Problem 2: Nintendo wants you to tape a big paper above the pidgeon holes, saying: Postmaster, please drop all mail in box 27, no matter what box it specifies. Technically only for UDP, so the TCP traffic will be delivered. Even so, a lot of post will be wrongly delivered to the Switch and thrown away. Other tenants will wonder why they don't get their mail.
Problem 3: You become very vulnerable. The router will send every hacking attempt to the Switch. The tiniest bug in its networking is now critical, as outsiders can just assume your Switch will receive anything they send.
To recap, Nintendo is making sure their device receives traffic by throwing every other device you own under the bus. Even a second Switch will suffer. The advice is Dilbert PHB level idiotic but will seem to work for a while.
It is also a massive security liability as any vulnerable software running on the Switch could be used to compromise the console remotely and by extension compromise your home network since your Switch is likely connected directly on it.
No, it is not. NAT is not a firewall; its goal is to let traffic through, not prevent it. The fact that it sometimes happens to behave like a firewall is very dangerous since it leads people into a false sense of security.
I have early 2000s routers that would basically forward all UDP traffic from $IP to the last computer that had sent any traffic to $IP. This did wonders for most games, but you were in for a nasty surprise if you were relying on NAT to protect your fragile Win9x network...
If you follow Nintendo steps, what happens is that anybody will hit your Switch directly if they connect to any port on your public IP. If some services on the Switch are running and listening on the Switch public interface, they will answer. If one of the those service has a security vulnerability, you are in trouble. You just don't want to expose your entertainment devices to the whole world like this.
This setup could make some sense for a DMZ but not a gaming console connected to your local lan.
This is exactly why I say that NAT gives a false sense of security.
The point is that even without manual port forwarding your Switch is _already_ exposed to the public internet. You can't assume that NAT is going to forever hide your device from the public internet because the role of NAT is to pass traffic, not prevent it. The example I mentioned is to show that NAT's heuristics may end up exposing your device anyway, manual port forwarding or not. So if you really run a device with vulnerable services, you either add a real firewall or disable NAT.
If the Switch had any vulnerable ports, they were exposed already long ago. Not to mention: IPv6 networks, public Wi-Fi hotspots, etc.
From the little I understand of networking, this might mean that other machines on the network will never get that traffic (unless the Switch routes it and those machines use it as gateway, which is unlikely).
I think we can safely assume something that needs 20k odd ports forwarded to it won't be doing anything like re-routing and acting as a secondary gateway on the network. It doesn't strike me that a lot of thought went into how a Switch would be used behind a firewall during the design if you need that many ports.
No port can be used by any other computer or server (since all are required by Switch), and any port listening on your Switch will be automatically reachable by anyone which is a potential security risk. Does a Switch work if you are IPv6-only? Cause if it'd work with IPv6, a mitigation could be to only use IPv6. It wouldn't solve the security issue, but it would solve the problem of all (external IPv4) ports being used.
When you connect to a remote machine, you send traffic to a specific port on that remote machine but also from a specific port on your machine. The remote port would probably be well-known (eg, port 80 on TCP is the well known port for HTTP), but the local port would be chosen from a random range of available ports. As a result, every connection could be described based on a combination of parameters - the local IP, the remote IP, the local port and the remote port.
But these days most users don't connect to remote servers directly. Instead, they're on a local network that connects through a router that only has a single world-routable IPv4 address. That means that while the combination of local and remote IPs and ports is still nominally a unique identifier, the local IP could now refer to multiple different devices. NAT handles this by keeping track of which machine behind the NAT triggered a local connection, mapping its local port to a local port on the publicly routable IP, and then rewriting traffic and forwarding it appropriately so this is mostly invisible (eg, you send traffic to 142.250.189.174 on port 80, and your local port is 31337. Someone else on your network may also be using port 31337 to talk to port 80 on 142.250.189.174, so your NAT router rewrites your local port to 31338. When it sees incoming traffic on port 31338 from 142.250.189.174, it rewrites the packet to be sent to you and as far as you're concerned you're directly communicating with 142.250.189.174)
This basically works fine for TCP, because TCP requires you to explicitly make a connection. That means the NAT router can tie the combination of a remote host and a local port to a unique mapping to an internal machine. But UDP is, at the transport layer, stateless - when you send traffic to a remote machine over UDP, the expectation is that that remote machine can just send traffic back to the same UDP port at some arbitrary point in the future and, if the local client is still listening, that'll got through.
If you port-forward literally every UDP port to a specific device, when another local device tries to connect to an external service over UDP, your router will probably be confused - it can't just say "Ok, you connected to something over UDP, I rewrote your local port to 31337, traffic to 31337 will be sent to you", because 31337 is already configured to be forwarded to the Switch. You can potentially send traffic to a remote service, but the responses may be forwarded to the wrong device.
In theory you could say that because a machine with a specific internal IP sent traffic to a specific remote IP and you rewrote that to a specific port, any traffic from that remote IP to that port should be forwarded to that internal IP even if there's a general port forwarding rule that would instead forward it to the Switch. I have no idea whether that's how routers behave, and it's far too late for me to dig into the kernel source to check that (I've spent the evening fighting Linux's in-kernel ASN1 parser, I'm not inclined to do more)
I imagine the Switch might collect information about traffic that isn't relevant to the features the user is interested in. Seems a bit careless to just send all of it to the device.
Let's make it constructive then and talk about something that grinds my gears.
Throwing all ports in the direction of a single host has nothing to to with a DMZ. I know consumer router manufacturers like to call it that but it isn't. It's an Exposed Host setup.
A DMZ is a multi-tiered firewall approach where you have a Firewall between the internet and your DMZ and another one between your DMZ and your LAN
