from pogodem0n@lemmy.world to selfhosted@lemmy.world on 20 Feb 18:36
https://lemmy.world/post/43381650
Hi, c/selfhosted! This is my first post on Fediverse and I am glad to be making it here.
I recently got fed up with having to use Tailscale to access my server at home and decided to expose it publicly. A friend recommended segregating the server into a dedicated VLAN. My router’s stock firmware does not allow that, so I flashed OpenWrt on it (I am amazed how simple and easy the process was).
Getting the router to actually assign an IP address to the server was quite a headache (with no prior experience using OpenWrt), but I managed to do it at the end with a help from a tutorial video on YouTube.
Now, everything is working perfectly fine and as I’d expect, except that all requests’ IP addresses are set to the router’s IP address (192.168.3.1), so I am unable to use proper rate limiting and especially fail2ban.
I was hoping someone here would have an experience with this situation and help me.
Edit: Solved thanks to @PotatoesFall@discuss.tchncs.de.
I messed around with the port-forward settings with no luck in the past. Instead, disabling the “Masquerade” option in the firewall settings for the server’s VLAN worked.
threaded - newest
Welcome to Lemmy! Unfortunately I can’t be of help, but if you’ll indulge me, I’m curious why you got “fed up” with using Tailscale.
Thanks. I have been lurking ever since Reddit’s third-party client shenanigans, actually. 😅
The Android client has a recurring bug where the connection to the Tailnet and the DNS break about half the time when switching between Wi-Fi and cellular networks. Plus, I can’t use it and a VPN at the same time.
I can remedy that by toggling the connection off and on from the notifications panel, but it still keeps breaking with stuff that use a persistent connection, like ntfy (a UnifiedPush server).
Yeah, Tailscale’s “zero-config” idea is great as long as things actually work correctly… But you immediately run into issues when you need to configure things, because Tailscale locks you out of lots of important settings that would otherwise be accessible.
For instance, the WiFi at my job blocks all outbound WireGuard connections. Meaning I can’t connect to my tailnet when I’m at work, unless I hop off the WiFi and tether to my personal cell phone (which has a monthly data cap). Tailscale is built on WireGuard, and WireGuard only. If I could swap it to use OpenVPN or IKEv2 instead, I could bypass the problem entirely. But instead, I’m forced to just run an OpenVPN server at home, and connect using that instead of using Tailscale.
Try experimenting with the masquerade setting on the VLAN its on.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
[Thread #107 for this comm, first seen 20th Feb 2026, 20:01] [FAQ] [Full list] [Contact] [Source code]
I’m not really experienced with VLANs but this seems interesting. Is this only for requests from within the network or also for requests coming from outside the network, i.e. from your phone via cellular data or from a VPS?
Both.
Is it possible that you have something called “masquerading” enabled on the firewall zone that the server is in?
That was it! I messed around with the port-forward settings with no luck in the past. Disabling the “Masquerade” option in the firewall settings for the server’s VLAN worked. Thanks a bunch.
You would typically want to use static ip addresses for servers (because if you use DHCP the IP is gonna change sooner or later, and it’s gonna be a pain in the butt).
IIRC dnsmasq is configured to assign IPs from .100 upwards (unless you changed that), so you can use any of the IPs up to .99 without issue (you can also assign a DNS name to the IP, of course).
Sounds like you are using masquerade and need DNAT instead. No idea how to configure that in openwrt - sorry.
In this case, he controls the local DHCP server, which is gonna be running on the OpenWRT box, so he can set it to always assign whatever he wants to a given MAC.
Yeah, this is my preferred way of doing it. That way I always have a nice compiled list of IP addresses, and if I ever need to change any of them, I have them all in a single menu instead of needing to access each device individually. Just let the server use DHCP, then assign it a static IP in your DHCP server.
I’d guess that however the network is configured, you have the router NATting traffic going from the LAN to the Internet (typical for a home broadband router) as well as from the home LAN to the server.
That does provide security benefits in that you’ve basically “put the server on the Internet side of things”, and the server can’t just reach into the LAN, same as anything else on the Internet. The NAT table has to have someone on the LAN side opening a connection to establish a new entry.
But…then all of those hosts on the LAN are going to have the same IP address from the server’s standpoint. That’s the experience that hosts on the Internet have towards the same hosts on your LAN.
It sounds like you also want to use DHCP:
I’ve never used VLANs on Linux (or OpenWRT, and don’t know how it interacts with the router’s hardware).
I guess what you want to do is to not NAT traffic going from the LAN (where most of your hardware lives) and the DMZ (where the server lives), but still to disallow the DMZ from communicating with the LAN.
considers
So, I don’t know whether the VLAN stuff is necessary on your hardware to prevent the router hardware from acting like a switch, moving Ethernet packets directly, without them going to Linux. Might be the case.
I suppose what you might do — from a network standpoint, don’t know off-the-cuff how to do it on OpenWRT, though if you’re just using it as a generic Linux machine, without using any OpenWRT-specific stuff, I’m pretty sure that it’s possible — is to give the OpenWRT machine two non-routable IP addresses, something like:
192.168.1.1 for the LAN
and
192.168.2.1 for the DMZ
The DHCP server listens on 192.168.1.1 and serves DHCP responses for the LAN that tell it to use 192.168.1.1 as the default route. Ditto for hosts in the DMZ. It hands out addresses from the appropriate pool. So, for example, the server in the DMZ would maybe be assigned 192.168.2.2.
Then it should be possible to have a routing table entry to route 192.168.1.1 to 192.168.2.0/24 via 192.168.2.1 and vice versa, 192.168.2.1 to 192.168.1.0/24 via 192.168.1.1. Linux is capable of doing that, as that’s standard IP routing stuff.
When a LAN host initiates a TCP connection to a DMZ host, it’ll look up its IP address in its routing table, say “hey, that isn’t on the same network as me, send it to the default route”. That’ll go to 192.168.1.1, with a destination address of 192.168.2.2. The OpenWRT box forwards it, doing IP routing, to 192.168.2.1, and then that box says “ah, that’s on my network, send it out the network port with VLAN tag whatever” and the switch fabric is configured to segregate the ports based on VLAN tag, and only sends the packet out the port associated with the DMZ.
The problem is that the reason that home users typically derive indirect security benefits from use NAT is that it intrinsically disallows incoming connections from the server to the LAN. This will make that go away — the LAN hosts and DMZ hosts will be on separate “networks”, so things like ARP requests and other stuff at the purely-Ethernet level won’t reach each other, but they can freely communicate with each other at the IP level, because the two 192.168.X.1 virtual addresses will route packets between each the two networks. You’re going to need to firewall off incoming TCP connections (and maybe UDP and ICMP and whatever else you want to block) inbound on the 192.168.1.0/24 network from the 192.168.2.0/24 network. You can probably do that with iptables at the Linux level. OpenWRT may have some sort of existing firewall package that applies a set of iptables rules. I think that all the traffic should be reaching the Linux kernel in this scenario.
If you get that set up, hosts at 192.168.2.2, on the DMZ, should be able to see connections from 192.168.1.2, on the LAN, using its original IP address.
That should work if what you had was a Linux box with three Ethernet cards (one for each of the Internet, LAN, and WAN) and the VLAN switch hardware stuff wasn’t in the picture; you’d just not do any VLAN stuff then. I’m not 100% certain that any VLAN switching fabric stuff might muck that up — I’ve only very rarely touched VLANs myself, and never tried to do this, use VLANs to hack switch fabric attached directly to a router to act like independent NICs. But I can believe that it’d work.
If you do set it up, I’d also fire up
sudo tcpdumpon the server. If things are working cor