DHCP clients & Option 121

Originally Posted by guanx The dhcp client could be confined to a dedicated network namespace. The default namespace can then be routed through this dedicated namespace through a pair of veth. It might be a good idea to add this setup to rc.inet1 considering rc.inet1 has already supported a bunch of miscellaneous configurations.

Irrelevant. This problem is not caused by any DHCP server or client implementation, but by network infrastructure poorly or not configured enough to protect real DHCP servers from malicious (or accidental) DHCP servers. You can add your DHCP server to any veth; if you don't tell the network "don't listen to any DHCP reply other than coming from this veth", this setting is moot.

Originally Posted by guanx The dhcp client could be confined to a dedicated network namespace. The default namespace can then be routed through this dedicated namespace through a pair of veth. It might be a good idea to add this setup to rc.inet1 considering rc.inet1 has already supported a bunch of miscellaneous configurations.

Personally, on my box at home, I get dhcp instructions from my router, and for better or worse, I trust that. So I could confine that to my home network. Sitting in a hotel, or Starbucks, I don't know what the network is going to be, so any mobile pc could not have the dchp client restricted. A malicious dhcp server could, I gather from all your comments read my traffic. To my mind, the ideal solution would be to compile or configure dhcpcd & dhclient to not use option 121 at all. Option 121 seems fine for an isp that has to log everything, but it's hardly much use to 99½% of Slackware users. Is there any way to configure our way out of this?

I'd also ask: How would it affect internet speed? If I have been exploited, every packet has to be sent to the VPN & the hacker, surely that would halve the internet upload speed?

Options 121 might be very useful for virtual networks, especially in labs and for containers etc. There are lots of reasons for wanting routing more complex than just send everything not on this subnet to the default gateway and just as many reasons why you might want to control all that from a central location update-able location rather than trying to embed static routing information in a bunch of places.

Is DHCP the only way to do that, obviously not but its a well understood, expected and canonical way to do it. IMHO this is one of those 'fake' security issues, designed to generate a bunch of clicks, but it boils down to everything is 'working as expected' but a lot of folks are ignorant.

Here the thing as far as mobile devices on untrusted networks (phones laptops iot stuff etc) you asking via DHCP hey what is an address I can use and how do I send traffic to various other networks. You don't know 'who' is giving you that information, unless you do something like EAP for DHCP and start requiring signed responses. Then you'd have to have some kind of user interaction, the DHCP server says its Starbucks #2403, and is verified by LetsEncrpt; do you want to accept the configuration? Its duplication in that you probably already accepted the EAP information for the wlan itself; but of course we don't know the dhcp server isn't a rogue

- which is why if you are operating any kind of guest network you really really should implement client isolation to prevent this and other forms of attacks on your users.

As user the local IP layer remains untrusty even if the dhcp server is legitimate. You need to ensure your VPN solution actually controls routing and pushes traffic that should go via your chosen gateway at that gateway. That is its job; if it does not do it, it is not dhcp's problem. DHCP for example does not know anything about iptables/nftables, on linux a VPN client should probably be using that to either set the next gateway explicitly if split tunneling isn't allowed or pushing traffic to its own named routing table/vrf. If not doing that then it really isn't a 'virtual private network' it just an ip tunnel; that might happen to be ciphered.

Similarly there is a defense in depth issue. While there might be a minimal privacy issue with seeing which hosts you are connecting to if you are using TLS or ssh etc, the attacker still isn't going to be able to eavesdrop on any content. They don't have the certificates. Don't go clicking 'go there anyway' or accepting host thumbprints that don't match and you'll be fine.

Originally Posted by HQuest Irrelevant. This problem is not caused by any DHCP server or client implementation, but by network infrastructure poorly or not configured enough to protect real DHCP servers from malicious (or accidental) DHCP servers. You can add your DHCP server to any veth; if you don't tell the network "don't listen to any DHCP reply other than coming from this veth", this setting is moot.

If you searched for the word "client" in my previous reply you wouldn't have made the conclusion that I was talking about the server side.

Originally Posted by business_kid //snip ... but it's hardly much use to 99½% of Slackware users. //snip

For the specific Slackware user, the OP, that's 100.0%;
For an average Slackware user, where did you get the statistics?