On 7/25/23 16:55, Polarian wrote:
Also, I didn't choose OpenBSD cause it was easy, I choose it for
security, if I slapped OpenWrt I could be done in seconds, but I want to
learn and I want to use OpenBSD for security, even at the hit of
performance, so I don't care about the complexity, only to know that it
is possible and find out how to do it. I have attempted to find others
with a similar setup without any luck.
You've already been justifiably scolded for inflammatory and ignorant
remarks regarding the "performance" of OpenBSD in the past, and here
you are again. Now you're adding "complexity" to this too. You need to
stop. Stuart is quite patient and can look past this, but there are
enough people in the community that won't even bother trying to help if
this nonsense keeps being spewed.
How is this for performance? I have four physical interfaces, nine
vlan(4), and two wg(4) pseudo-devices distributed across two rdomain(4)s
with 110 pf(4) rules according to pfctl -sr | wc. I run
dhcpcd(8), dhcpd(8), dovecot(1), httpd(8), nsd(8), ntpd(8), rad(8),
rspamd(8), smtpd(8), sshd(8), unbound(8), and the Vaultwarden password
manager. Despite all that, my system _easily_ saturates 2.5 Gbps links.
Shucks! What "terrible" performance.
As for "complexity", I believe you are victim to the common fallacy of
conflating _familiarity_ with simplicity. Worse, you likely haven't
even attempted to do what you want on a Linux-based OS or other OS. I'd
be interested to see just how "simple" such a config would be. A naive
metric would be number of keystrokes. We can contrast the two setups.
On 7/26/23 18:59, Polarian wrote:
However, NAT on the other hand does provide some security, without
redirecting the ports to internal addresses, none of the containers are
wan facing, which does add additional security, on top of the existing
firewall within the containers of course.
Stop yourself. No it does not. There is nothing more secure about NAT
to "hide" devices on your (V)LAN side than assigning globally routable
IPs to those devices. In both cases, the devices are not on the WAN
side and both rely on a firewall to prevent traffic from coming into
the WAN interface and being passed out the (V)LAN interface to the
device. False security is _worse_ than none since you are more likely
to falsely believe you are protected from certain attack vectors making
it more likely you will let your guard down.
A pedant would perhaps argue NAT makes it more _insecure_ since that is
more code that has to be executed increasing the probability of
encountering a bug (e.g., a zero-day exploit).
If anyone is wondering, I run both external and internal services,
therefore yes having a LAN is useful.
Cool, so do I; and some of the devices don't rely on NAT either. The
ones that do do so because I don't have enough globally routable IPv4
addresses to assign and not because the absurd notion that it's "more
secure". You better be using NAT for IPv6 too; otherwise you can add
inconsistency to your "logic" that NAT is more "secure". If not,
congrats your logic is now trivialism
(https://en.wikipedia.org/wiki/Trivialism).
I think it is pretty clear that attempting to route aliases is not
going to work, so is the next step trying to vlan? Because vlan's
increase complexity by a lot, and the most simple solution (apart from
another physical interface, as that is not currently possible) would
be preferable.
"vlan's [sic] increase complexity by a lot"? Seriously? You have an
absurdly low bar on what you consider "complex" let a lone "very
complex". We are not doing homotopy type theory here. Let's see how
"complex" setting up VLANs are on OpenBSD 7.3-stable shall we?
router$ cat /etc/hostname.ixl0
up
router$ cat /etc/hostname.vlan0
parent ixl0
vnetid 10
inet6 fdb5:d87:ae42:1::1 64
inet 192.168.1.1 255.255.255.0 NONE
If that is "complex", then you should stop now as you will and likely
already have encountered things _a lot_ more "complex".
Maybe you were referring to how "complex" the setup is on the switch
side. Without knowing the specific OS, I cannot say for sure; but I
doubt it is "complex" to set up VLANs. Some switches have nice pretty
GUIs you can use where you point, click, and type what VLAN ID you want
to use: extremely simple. Even on more "advanced" switches, it's still
easy to configure VLANs. "Proof" on my Juniper switch running
JUNOS 22.4R1-S2.1:
zack@switch> edit
Entering configuration mode
{master:0}[edit]
zack@switch# set vlans foo vlan-id 10
zack@switch# set interfaces mge-0/0/4 unit 0 family ethernet-switching vlan
members foo
zack@switch# set interfaces xe-0/1/0 unit 0 family ethernet-switching
interface-mode trunk vlan members all
zack@switch# commit
The reason it is recommended to separate traffic on both L2 and L3
networks is that it usually makes the most sense. Why would one want to
separate traffic at the IP layer but not lower? It can be done; and if
you are doing it for an academic exercise, fine. Personally, the reason
I put devices in separate IP networks is that I don't want them to
send traffic to each other without going through a firewall; but if
they are on the same L2 network, then that's not the case since traffic
can and will be sent.
