If you've never had to open a port on your router, you probably never will — Netflix, Zoom, Xbox Live and basically every consumer app work without it. Port forwarding only matters the moment you want the opposite: a device on your home network that a stranger on the internet can reach directly, like a game server or a security camera you check from work. Here's how to tell which camp you're in, and the actual steps if you're not.
What port forwarding actually does
Every device behind your router shares one public IP address. When you request a webpage or start a video call, your router remembers who asked and routes the reply back to the right device automatically — that's outbound traffic, and it needs no configuration. Port forwarding solves the opposite problem: letting an unsolicited *inbound* connection reach a specific device, on a specific port, instead of hitting your router and going nowhere. It's a rule that says "if someone knocks on port 25565, send them to the game console in the office," not something you need for anything that starts the conversation from inside your house.
When you actually need it
- Hosting a game server that friends connect to directly — a Minecraft Java server, an ARK or Valheim dedicated server, anything where you're the host and others type in your address.
- Self-hosting media or files you want to reach from outside your home — a Plex or Jellyfin server you want to stream from at a friend's place, or a home NAS you access remotely.
- Checking a security camera or NVR system from your phone, if it doesn't route through the manufacturer's own cloud app (most modern ones do, and don't need this at all — check before you assume).
- Remote access to a home computer for work, if you're not using a service like a VPN or remote-desktop tool that already tunnels through for you.
When you don't
Console and PC gaming (Xbox, PlayStation, Steam multiplayer against someone else's server), video calls, streaming, smart-home apps and almost every cloud-backed camera or doorbell all use outbound connections or automatic NAT traversal (UPnP) to work without you touching a router setting. If an app or device doesn't specifically tell you it needs a forwarded port, opening one does nothing for it — you'd just be leaving a door open for no reason.
How to set it up
The exact screens vary by router, but the steps are the same shape everywhere. oxio's own setup guide for its routers lays out this order [1]:
- Find the port number and protocol your app needs. The app's own setup instructions will say — usually a specific number and whether it's TCP, UDP, or both.
- Give the device a fixed local address first. On oxio's SmartRG routers, that means assigning the device a static IP before you touch port settings; on the Adtran 841 or oxio Wi-Fi pod, it means reserving an IP for the device in the app if it doesn't already show up in the device list [1]. Skip this step and your forwarding rule can silently break the next time the device reconnects and gets a different address.
- Open the router's port-forwarding settings. SmartRG models are configured at 192.168.1.1 in a browser; the Adtran 841, oxio Wi-Fi pod and eero are configured through their apps [1].
- Create one rule per protocol if there's no combined option. Some router interfaces let you pick "TCP/UDP" or "Both" in one rule; others make you create separate TCP and UDP rules for the same port [1].
- Avoid ports 80 and 443. Those two are reserved for oxio's own use and can't be redirected or closed [1].
- Write down what you set up. If a support call ever needs your router reset, that wipes custom port rules, and you'll want to redo them from your own notes rather than reconstruct them from memory [1].
Worked example: a Minecraft Java server
Minecraft's own setup documentation is specific: a Java Edition server listens on port 25565 by default, and the wiki's own port-forwarding instructions say to set the rule to "TCP/UDP" or "Both" for that port, splitting it into two rules if your router doesn't support a combined type [2]. Concretely: install the server software on the machine that'll stay on, note that machine's local IP, forward port 25565 (TCP and UDP) to it following the steps above, then share your public IP (or a free dynamic-DNS name, since home IPs can change) with whoever's joining.
Worked example: Plex remote access
Plex's default port is 32400 (TCP) [3]. Plex Media Server tries to configure this automatically through UPnP the moment you turn on remote access in its settings, and only asks you to forward the port by hand if that fails — so try the automatic option first and only fall back to a manual rule if Plex itself tells you to.
What oxio blocks, and what it doesn't
oxio blocks exactly two categories of inbound traffic, and says why: SNMP on UDP port 161, because older versions of that protocol are unencrypted and blocking it stops outsiders from probing or taking over routers remotely, and outbound SMTP on TCP ports 25, 465, 587 and 2525, which stops a compromised home device from being hijacked to blast out spam or phishing email [4]. That second one means you can't run your own mail server from home on an oxio connection — but it doesn't touch normal email use through Gmail, Outlook or iCloud, since those don't go over the blocked ports [4]. Every other port and protocol oxio lists as fully open [4], and separately, oxio doesn't throttle traffic or block VPNs on any plan [5] — the two restrictions above are the entire list, not a starting point.
The one caveat worth taking seriously
Every port you open is a door a stranger can knock on. Before you forward anything, change the default admin password on whatever service you're exposing (a Minecraft server, an NVR, a NAS) and keep it updated — the port-forwarding step itself is safe; a weak password on the thing behind it is where actual problems start.
None of this changes what you're already paying for. If you're weighing a switch and want to run this exact setup on your own connection, code takes your first month at oxio to zero while you test it.