Re: Routing multiple IPv4 blocks
On Fri, Jul 28, 2023 at 10:09:31PM +0100, Polarian wrote: > I do have one question, if anyone is willing to answer it, so I have on and > off specified "keep state" depending on when I wrote the rule, but the > following specifies it is the default: > https://www.openbsd.org/faq/pf/filter.html > > So why do a lot of examples I see specify keep state if it is the default, > is there any benefit of specifying it which I am missing? I would guess that some of the examples are based on something that was written long enough ago that "keep state" was not the default. I personally only add "keep state" when I also need to add state options such as pflow or state tracking options. If you do a "pfctl -vnf /etc/pf.conf" and compare the output to the stored file, you will see that "keep state" and possibly other defaults will be appened (and things like lists of ports generating several rules and so on). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Routing multiple IPv4 blocks
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.
Re: Routing multiple IPv4 blocks
>> It can be done, but 1) it means that it's possible for hosts on RFC1918 >> addresses to reach the routable addresses directly without going via the >> router and vice-versa (which may or may not be a problem), 2) you'll >> need to think about how you want to arrange things if you use DHCP, and >> 3) it complicates things for firewall and nat rules. > > 1. I do not believe this should be a problem, as far as I am aware this > is routed based on MAC address (Layer 2), but IP addresses are a higher > layer (Layer 3). It means that your directly internet-accessible hosts have a way that they can reach your internal-network hosts without going through the firewall. Many network admins would consider this a problem. > 2. DHCP is simple, it is only for the private block (192.168.2.1/24) > which devices will use by default, global addresses from the /29 block > is assigned manually, this is because most containers are internal, > which the NAT is just so they can still access the internet, but not > expose themself fully (and before you say "why not use a global > address" that's fine, you have thought about how to arrange things for this > IPv4 addresses are expensive and I am lucky to have a /29, fwiw, you're using an expensive ISP which has ample spare addresses, there's a faorly good chance they'll give you more if asked. > 3. I don't think so, because I specify the "from" address as either from > 192.168.2.1/24 or the static block, which clearly distinguishes between > them. Also the "quick" rules are above the NAT, this should pick up and > pass out the traffic respectively before it even gets to NAT, I doubt > this is the issue and I believe it lies within the routing table. it's common to be able to use the network interface on which a packet is received as part of the decision whether to accept that packet. most example rulesets you'll find do that, so be aware if cribbing from other setups. >> 217.169.18.56 is a network address (mask it out against the netmask, >> the remaining "host bits" are all zeroes), you cannot use this (or the >> broadcast address) as a host address >> >> $ ipcalc 217.169.18.56/29 >> address : 217.169.18.56 >> netmask : 255.255.255.248 (0xfff8) >> network : 217.169.18.56 /29 >> broadcast : 217.169.18.63 >> host min : 217.169.18.57 >> host max : 217.169.18.62 >> hosts/net : 6 > > Ah my mistake, I totally forgot about the loopback address which would > be 217.169.18.56, this is from my own stupidity. > t's not a loopback, it's the network address. > But in theory, can I assign IPs from the /29 without having a default > gateway from that block, could I put the gateway as the /32 and keep all > 6 of the usable IPv4s? > > A router does not need 2 IPv4's, only one, so is it possible to keep one > or is it a requirement to have an IPv4 from the block assigned to the > router? hosts within that subnet need to be able to send ethernet paclets that reach the router. this is normally done by ARP which requires that the router has a host address (not a network or broadcast address) within the subnet. there are other ways to do it but they are fiddly, more fragile (requiring changes on every host if the router hardwarw address is changed), and really not recommended to go down that route unless you have a solid grasp of the basics. > > But the fact remains is, I believe all the addresses are bound to by the > router not according to what you've shown in your mail. > nmap'ing all the IPv4s in the block return the ports open by the > router. there's going to be some reason for this but it'll be easier to fix what's obviously a problem first and then go from there. > So it should be: > > inet alias 217.169.18.57 255.255.255.248 217.169.18.63 > > correct? yes, or you can leave off the broadcast address, it's set by default anyway. (remember to renumber the existing .57 host if you're going to use .57 for the router) -- Please keep replies on the mailing list.
Re: Routing multiple IPv4 blocks
On 2023-07-25, Zack Newman wrote: > On 7/25/23 06:03, Stuart Henderson wrote: >> 217.169.18.56 is a network address (mask it out against the netmask, >> the remaining "host bits" are all zeroes), you cannot use this (or the >> broadcast address) as a host address > > I am sure you were not trying to be "technical"; but for people that > don't already possess the knowledge, I just wanted to say that there > are two exceptions to the rule that you shouldn't assign the network or > broadcast address to a host: /31 (https://www.rfc-editor.org/rfc/rfc3021) > and /32 networks. I also have a /29 network of globally routable IPv4 > addresses, and I use all 8 of those precious IPs by carving out 8 /32s > and assigning each one to a host. true, though Nx/32 won't let you route it to other hosts without a lot of hassle, and /31 may work or may not work depending on the other host's IP stack and other software in use (some things don't expect /31), and it doesn't actually give you any more available addresses unless you only have a routed /30. you can also put the all-0/all-1 addresses as /32 aliases and use them for NAT (i.e. nat-to, rdr-to, or binat-to, to a machine on an RFC1918-numbered network) while using the rest as normal on another nic. or there's a bodge if you don't need to talk to people on the surrounding addresses, where you set the netmask wider than you really have, say you have 192.0.2.80/28 from the ISP $ ipcalc 192.0.2.80/28 address : 192.0.2.80 netmask : 255.255.255.240 (0xfff0) network : 192.0.2.80 /28 broadcast : 192.0.2.95 host min : 192.0.2.81 host max : 192.0.2.94 hosts/net : 14 you could configure as /26 $ ipcalc 192.0.2.80/26 address : 192.0.2.80 netmask : 255.255.255.192 (0xffc0) network : 192.0.2.64 /26 broadcast : 192.0.2.127 host min : 192.0.2.65 host max : 192.0.2.126 hosts/net : 62 and actually use the 16 addresses .80-.95 (depending on how the routed subnet is aligned you may need to go to a wider prefix length, maybe as much as /23 if it starts on .0 or ends on .255). but none of these are things I think the OP should be concerned with at this time hence not suggesting them. :)
Re: Routing multiple IPv4 blocks
An individual was kind enough to reach out and inform me that they believe I should have not said "I am sure you were not trying to be 'technical'..." but instead "I am sure you were trying not to be 'technical'..." as the former sounded like I was suggesting Stuart was giving bad advice by being lazy. In the event that was the interpretation by other people, most notably Stuart; then I apologize. The intent of what I was saying was merely to add a potentially relevant "technical" detail that for most people is _not_ relevant. For almost all things (short of FOL proofs), there are exceptions; so it is understandable and even desirable often times to be "loose" with the technical details. When one has gathered enough preliminary knowledge, then they can revisit some of those things with a more precise perspective (e.g., in physics one learns about Newtonian mechanics before relativity even though "technically" it is not quite correct or Ohm's law despite it rather obviously falling apart when resistance is 0 or even approaches 0). I said what I said because I didn't want it to be misconstrued as "one upping" Stuart with the rather obnoxious "actually" response (https://www.youtube.com/watch?v=GAyt3KUVkrY) which of course is exactly what I ended up doing. :( I do believe that stating network or broadcast addresses shouldn't be assigned to a host is a reasonable and perhaps correct thing since most people won't find themselves in the position of needing or even desiring to use /31 or /32 IPv4 networks.
Re: Routing multiple IPv4 blocks
On 7/25/23 06:03, Stuart Henderson wrote: 217.169.18.56 is a network address (mask it out against the netmask, the remaining "host bits" are all zeroes), you cannot use this (or the broadcast address) as a host address I am sure you were not trying to be "technical"; but for people that don't already possess the knowledge, I just wanted to say that there are two exceptions to the rule that you shouldn't assign the network or broadcast address to a host: /31 (https://www.rfc-editor.org/rfc/rfc3021) and /32 networks. I also have a /29 network of globally routable IPv4 addresses, and I use all 8 of those precious IPs by carving out 8 /32s and assigning each one to a host.
