Network problems

nszeek · 2024-12-21 11:57:07

UPDATE
It seems my client uses TLSv1 when it's connected to the server but if I connect the client directly to the modem then it uses TLSv1.3. What?

Not sure TLS was the problem but I just did a fresh arch install on a second computer to work as the server and I get the same problem. I'm out of ideas.
/UPDATE

Sorry if this is not the best place to post this.

I'm having trouble with my arch home router, some pages won't load (time out) on clients of the network while some pages load without problems. Long story short, I've tried a lot of stuff until I called my ISP to pay me a visit and connecting the modem directly to a computer that couldn't load the page makes so that it works and can load the page (and they say it's a "my server" issue). The computers that can't load the pages still can ping the pages and traceroute them but can't access them using a browser. I tried four different browsers, clearing caches, clearing DNS caches, clearing SSL caches and even booting linux from a usb stick and still couldn't access the sites. Pasting the IP directly into the browser doesn't work either.

Here's the layout of my network:
(enp5s0/ppp0) (enp1s0)
Modem --- Server (arch) --- Cisco Switch --- LAN
\--- wireless router (also LAN)

I'm not using any wireless connection but decided to put the wireless router there for the sake of completion. I also connected the server directly to a client computer to bypass the cisco switch and the problem persists.

enp5s0/ppp0 connects to the modem and uses pppoe to make the connection to my ISP

# cat /etc/systemd/network/enp5s0.network
[Match]
Name=enp5s0

[DHCPv4]
UseDNS=true

and the pppoe part (I changed my username so it doesn't show):

# cat /etc/ppp/peers/provider
plugin pppoe.so

enp5s0
name "username"
usepeerdns
persist
defaultroute
hide-password
noauth

enp1s0 has the 192.168.0.1 address and is the shares the internet with my LAN:

# cat /etc/systemd/network/enp1s0.network
[Match]
Name=enp1s0

[Network]
Address=192.168.0.1/24
DHCPServer=true
IPMasquerade=ipv4

For the sake of trying to make things work, I switched to a very basic iptables rule set that I think is correct (still have the problem):

# iptables -L -n -v
Chain INPUT (policy DROP 2406 packets, 666K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
    4   240 ACCEPT     0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 2860  788K ACCEPT     0    --  enp1s0 *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
11141 4073K ACCEPT     0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 8686 3165K ACCEPT     0    --  enp1s0 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  enp1s0 ppp0    0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 2203 packets, 361K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0

I don't think I have any conflicts with network packages but I could be wrong so:

# systemctl list-unit-files --state enabled
UNIT FILE                            STATE   PRESET
dhcpd4.service                       enabled disabled
fail2ban.service                     enabled disabled
getty@.service                       enabled enabled
httpd.service                        enabled disabled
ipset.service                        enabled disabled
iptables.service                     enabled disabled
mariadb.service                      enabled disabled
php-fpm.service                      enabled disabled
postgresql.service                   enabled disabled
sshd.service                         enabled disabled
systemd-network-generator.service    enabled enabled
systemd-networkd-wait-online.service enabled enabled
systemd-networkd.service             enabled enabled
systemd-resolved.service             enabled enabled
systemd-networkd.socket              enabled disabled
remote-fs.target                     enabled enabled

16 unit files listed.

My DHCP server:

# cat /etc/dhcpd.conf
authoritative;
ddns-update-style   interim;
get-lease-hostnames true;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range                         192.168.0.100           192.168.0.199;
  default-lease-time            259200;
  max-lease-time                518400;

  option subnet-mask            255.255.255.0;
  option broadcast-address      192.168.0.255;
  option routers                192.168.0.1;
}

Some stuff about DNS:

# resolvectl
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 10.8.8.8
         DNS Servers: 10.8.8.8
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net
                      2001:4860:4860::8888#dns.google

Link 2 (enp1s0)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (enp5s0)
    Current Scopes: LLMNR/IPv6
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 4 (ppp0)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Not sure I should leave IPs visible like this, I can edit later I guess.

# ip route
default dev ppp0 scope link
172.31.255.254 dev ppp0 proto kernel scope link src 187.120.181.58
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.1

For this too:

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:3e:aa:0c:db:e0 brd ff:ff:ff:ff:ff:ff
    altname enx503eaa0cdbe0
    inet 192.168.0.1/24 brd 192.168.0.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::523e:aaff:fe0c:dbe0/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:f1:f3:a7:60:b8 brd ff:ff:ff:ff:ff:ff
    altname enx00f1f3a760b8
    inet6 fe80::2f1:f3ff:fea7:60b8/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet 187.120.181.58 peer 172.31.255.254/32 scope global ppp0
       valid_lft forever preferred_lft forever
    inet6 2804:2968:5000:7f4:f1:f37b:eca7:60b8/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 2591216sec preferred_lft 2591216sec
    inet6 fe80::f1:f37b:eca7:60b8 peer fe80::c6b8:b4ff:fe34:ab46/128 scope link nodad
       valid_lft forever preferred_lft forever

Forwarding:

# sysctl -a | grep -P '^(?=.*ipv4)(?=.*forward)'
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.enp1s0.bc_forwarding = 0
net.ipv4.conf.enp1s0.forwarding = 1
net.ipv4.conf.enp1s0.mc_forwarding = 0
net.ipv4.conf.enp5s0.bc_forwarding = 0
net.ipv4.conf.enp5s0.forwarding = 1
net.ipv4.conf.enp5s0.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.ppp0.bc_forwarding = 0
net.ipv4.conf.ppp0.forwarding = 1
net.ipv4.conf.ppp0.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

I can access the pages from the server, in text mode, using links:

# dig duckduckgo.com

; <<>> DiG 9.20.4 <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43832
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;duckduckgo.com.                        IN      A

;; ANSWER SECTION:
duckduckgo.com.         545     IN      A       191.235.123.80

;; Query time: 6 msec
;; SERVER: 10.8.8.8#53(10.8.8.8) (UDP)
;; WHEN: Sat Dec 21 08:37:38 -03 2024
;; MSG SIZE  rcvd: 59

and this is from a client computer:

# dig duckduckgo.com

; <<>> DiG 9.20.4 <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53067
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;duckduckgo.com.                        IN      A

;; ANSWER SECTION:
duckduckgo.com.         413     IN      A       191.235.123.80

;; Query time: 3 msec
;; SERVER: 10.8.8.8#53(10.8.8.8) (UDP)
;; WHEN: Sat Dec 21 08:39:52 -03 2024
;; MSG SIZE  rcvd: 59

The /etc/systemd/resolved.conf file is unchanged, with an empty [Resolve] section.
The system is up to date as per pacman -Syu.
The datetime of the server seems correct and match the datetime of the clients.
Changing the DNS in the server didn't work, tried 8.8.8.8, 8.8.4.4, 208.67.222.222 and 208.67.220.220.
Changing the DNS in the clients didn't work as well, tried the same ones.

Using a VPN in the clients does work but then again, if I connect the modem directly to any client it also works without the VPN.

Last edited by nszeek (2024-12-21 20:27:09)

cryptearth · 2024-12-21 12:13:53

well - if you have only a pure modem without integrated nat-router one simple solution would be to buy an of-the-shelf one - either with integrated modem (if your isp supports this) or a device with rj45 for both lan and wan
you could also try openWRT instead of vanilla arch
if ping and traceroute works this sounds that either there's an issue on the clients (i.e. the dhcp config) or some routing problems with tcp connections
it sure is fun to tinker with such stuff on your own hardware - but for something as your main uplink I would just go with a modern modem/router(/wifi) combo instead of having the 90s call me wanting thier splitter back

Last edited by cryptearth (2024-12-21 12:15:03)

nszeek · 2024-12-21 12:45:45

cryptearth wrote:

well - if you have only a pure modem without integrated nat-router one simple solution would be to buy an of-the-shelf one - either with integrated modem (if your isp supports this) or a device with rj45 for both lan and wan
you could also try openWRT instead of vanilla arch
if ping and traceroute works this sounds that either there's an issue on the clients (i.e. the dhcp config) or some routing problems with tcp connections
it sure is fun to tinker with such stuff on your own hardware - but for something as your main uplink I would just go with a modern modem/router(/wifi) combo instead of having the 90s call me wanting thier splitter back

I thought it was my client's problems for the some time and tried a lot of different things: flushing dns, forcing fixed IPs, forcing DNS servers, booting linux from a ubs stick, trying different computers, clearing caches, ... but it turns out if I connect the modem directly to the client, it works, all the pages load.

Also, this setup was working for years, until Wednesday (18). I'm thinking it could be some update since I update the system but not always reboot it right after. I rebooted it at Wednesday and I feel it stopped working at about the same time.

cryptearth · 2024-12-21 13:05:14

well - although only really required for kernel updates I recommend reboot after every update no matter what it is

anyway - if the clients can access the internet when connected directly to the modem it clearly is some routing problem - and as vpn helps by just tunnel through your "router" it's likely something more higher up the logical chain
the dns resolve seems to work - does something more lowlevel like wget/curl work?
I suggest to setup wireshark and look into the packets how the clients communicate with the router and if there even is outbound traffic - maybe it's an issue with the incoming traffic blocked by the firewall - have you tried what happens when you just disable the firewall (or flush it)? also there seems the chains PRE-ROUTE and POST-ROUTE missing

nszeek · 2024-12-21 13:23:58

wget worked from the server but not from the client, had to CTRL+C it after a few minutes (removed my username from the log):

# wget --debug duckduckgo.com
DEBUG output created by Wget 1.25.0 on linux-gnu.

Reading HSTS entries from /home/username/.wget-hsts
Prepended http:// to 'duckduckgo.com'
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2024-12-21 10:10:26--  http://duckduckgo.com/
Resolving duckduckgo.com (duckduckgo.com)... 191.235.123.80
Caching duckduckgo.com => 191.235.123.80
Connecting to duckduckgo.com (duckduckgo.com)|191.235.123.80|:80... connected.
Created socket 3.
Releasing 0x0000624700704db0 (new refcount 1).

---request begin---
GET / HTTP/1.1
Host: duckduckgo.com
User-Agent: Wget/1.25.0
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... ^C

The server doesn't have a X interface (or a graphics card or even a graphics output plug) so I don't know how I would setup Wireshark there. I did try Wireshark on the client side to check for DNS requests and could confirm the request working and getting a correct response, I'll try to check for further traffic on the client.

As for the iptables rules, I'm not the most savvy with those, is this what you mean?

# iptables -L -n -v
Chain INPUT (policy DROP 48 packets, 13310 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  199 29038 ACCEPT     0    --  enp1s0 *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  393  141K ACCEPT     0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  323  107K ACCEPT     0    --  enp1s0 *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  enp1s0 ppp0    0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 182 packets, 18646 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0

With the following iptables' rules, it still doesn't work:

# iptables -L -n -v
Chain INPUT (policy ACCEPT 402 packets, 79285 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 4507 packets, 2523K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 290 packets, 37081 bytes)
 pkts bytes target     prot opt in     out     source               destination

nszeek · 2024-12-21 13:56:45

This is from Wireshark on a client (192.168.0.21) and duckduckgo.com is 191.235.123.80.

Disregard the start marked with red, that's from a previous attempt.

nszeek · 2024-12-21 14:17:29

Is this my server blocking TSLv1? I tried some other sites that work and they all use higher versions, tried a couple sites that are blocked and they use TSLv1. Could this be it? How do I unblock the use of TSLv1?

cryptearth · 2024-12-21 14:19:57

you can use wireshark from terminal via ssh - no need to plug in anything into the "server"
the client log doesn't help as wget already tells the issue: there's no reply from the remote - so likely either the client tries a direct connection without even trying to route through the server or the server doesn't route properly
also: what exactly is the server? some single board system? arm architecture?
you could also go the lame route and install squid on it and use it as proxy instead of a router
https://wiki.archlinux.org/title/Router might help

-- edit

if some remote still uses tls 1.0 or 1.1 and doesn't offer tls 1.2 contact its admin and don't use it until its updated

Last edited by cryptearth (2024-12-21 14:21:11)

nszeek · 2024-12-21 14:45:14

The server is a computer that I put together:

# neofetch
                   -`                    root@section-ten
                  .o+`                   ----------------
                 `ooo/                   OS: Arch Linux x86_64
                `+oooo:                  Kernel: 6.12.4-arch1-1
               `+oooooo:                 Uptime: 16 hours, 2 mins
               -+oooooo+:                Packages: 522 (pacman)
             `/:-:++oooo+:               Shell: zsh 5.9
            `/++++/+++++++:              Terminal: tmux
           `/++++++++++++++:             CPU: Intel Xeon E5-2670 0 (16) @ 3.300GHz
          `/+++ooooooooooooo/`           Memory: 643MiB / 32020MiB
         ./ooosssso++osssssso+`
        .oossssso-````/ossssss+`
       -osssssso.      :ssssssso.
      :osssssss/        osssso+++.
     /ossssssss/        +ssssooo/-
   `/ossssso+/:-        -:/+osssso+-
  `+sso+:-`                 `.-/+oso:
 `++:.                           `-/+/
 .`                                 `/

From the wireshark output, is that the server using TSLv1 or is that my client sending a request using TLSv1? Because it seems like it's my client but that doesn't make much sense to me.

nszeek · 2024-12-21 14:52:18

So, I think this might be it, I have no idea why or how but if I connect using the server then my client uses TLSv1 (wireshark above) but I connected the client directly to the modem and now my client makes a TLSv1.3 request:

1043	12.234083	187.120.181.58	191.235.123.80	TLSv1.3	745	Client Hello (SNI=duckduckgo.com)

What even is this?

Last edited by nszeek (2024-12-21 14:56:28)

nszeek · 2024-12-21 20:31:21

I edited the first post to include some update information but, just for the sake of completion, I'll post it here too.

I just did a fresh arch install with the latest iso and I still get the same problem. Followed the suggested link (https://wiki.archlinux.org/title/Router) to setup the new server, using just systemd-networkd, systemd-resolved, iptables and ppp.

I'm out of ideas of what to try next.

seth · 2024-12-21 21:10:00

Also, this setup was working for years, until Wednesday (18).

Check your pacman log for relevant updates.

curl -vL https://duckduckgo.com > /dev/null

uses TLSv1 ???
Did you cross-check this w/ a "working" url (that then uses TLSv1.3)?

Also make sure the involved system times are correct.

nszeek · 2024-12-21 22:48:42

seth wrote:

uses TLSv1 ???
Did you cross-check this w/ a "working" url (that then uses TLSv1.3)?
Also make sure the involved system times are correct.

I thought it was TLSv1 because of the Wireshark capture that showed TLSv1 twice for duckduckgo.com and then showed TLSv1.3 when I connected directly but maybe I misread the Wireshark capture?

I had previously installed and ran ntp to make sure the time was correct.

It's working and I have no idea why
I ended up trying a bunch of different things, not sure which of them worked so I'll make a list for whoever gets here later:
- Changed openssl.conf to include "MinProtocol = TLSv1.2" and "SSL_PROTOCOLS="TLSv1.2 TLSv1.3"
- Moved the folder /etc/ssl/certs to /etc/ssl/certs.old (because I was going crazy with this, I'm pretty sure this didn't help and might have created more problems: can't pacman -Sy now, might move the folder back)
- Reinstalled openssl
- Followed the instructions from https://wiki.archlinux.org/title/Router and ended up disabling kea-dhcp4 in favor of systemd's dhcp (which I don't think made a difference)
- resynced the time server again
- created a sysctl.d/40-forward.conf file with ipv4 and ipv6 forwarding (these already had "1" values but I was trying anything at this point)
- changed the base iptables from ACCEPT, ACCEPT, DROP to ACCEPT, ACCEPT, ACCEPT (I think forward table was drop by default at some point but some sites worked so I doubt it was this)

Might've forgotten something, I'll edit the list if I remember something else that I did.

On the other hand, I'm having some problems with DHCP now where some machines get the wrong IPs but that's probably the new dhcp server.

Thanks for everyone who helped me.

seth · 2024-12-22 08:51:32

I thought it was TLSv1 because of the Wireshark capture that showed TLSv1 twice for duckduckgo.com and then showed TLSv1.3 when I connected directly but maybe I misread the Wireshark capture?

No, but I was curious about what curl would be going for on the client (and what would happen then)

From your list and the symptoms
* Changed openssl.conf to include "MinProtocol = TLSv1.2" and "SSL_PROTOCOLS="TLSv1.2 TLSv1.3"
* Reinstalled openssl
* resynced the time server again
sound the most reasonable, removing MinProtocol from openssl.cnf could challenge that vector, the other two would become a mystery, but SSL is time sensitive.

cryptearth · 2024-12-22 09:06:21

although you seem to have solved it and maybe one day I'll tinker with it my personal recommendation still is:
1) request a modem/router combo from your isp
2) if your isp doesn't offer such ask if your own hardware is supported and buy your own modem/router combo
3) if you stuck with the isp modem by a cheap router without modem
4) if you want to avoid buying new hardware use something established like pf-/open-sense or openWRT

yes, sure, any linux on a system with two nic should be able to work as a router - and the wiki gives a good guide - but please remember: when you do something wrong you either kill yourself from the internet - or open your lan to the world
so my recommendation isn't about to not tinker but about security of your home network

nszeek · 2024-12-22 12:39:28

seth wrote:

No, but I was curious about what curl would be going for on the client (and what would happen then)

I do have a wget log posted but I already changed stuff and it was working when I read your message.

cryptearth wrote:

although you seem to have solved it and maybe one day I'll tinker with it my personal recommendation still is:
1) request a modem/router combo from your isp
2) if your isp doesn't offer such ask if your own hardware is supported and buy your own modem/router combo
3) if you stuck with the isp modem by a cheap router without modem
4) if you want to avoid buying new hardware use something established like pf-/open-sense or openWRT
yes, sure, any linux on a system with two nic should be able to work as a router - and the wiki gives a good guide - but please remember: when you do something wrong you either kill yourself from the internet - or open your lan to the world
so my recommendation isn't about to not tinker but about security of your home network

I'm indeed stuck with my ISP's modem that only has one RJ45 port but I could just hook that one port to a wifi router and use openwrt with a computer hosting stuff behind it, but I've had this computer host a few web pages, some services and a couple projects for some years now. I did have quite a few network attacks so I ended up blocking several countries to the point the attacks are just a few now (and fail2ban is up too). I also used a clean iptables without any blocking while trying to solve this because you never know.

Again, thanks for the help and suggestions.

seth · 2024-12-22 13:55:54

The wget call defaulted to http and apparently didn't even see a redirect from 80 to 443 (or hid that part as well as the tls handshake)

cryptearth · 2025-01-08 13:56:03

sorry for necrobumbing - but to get some input for others:

I have "re-created" OPs setup with the help of VMs and virtual bridges - and at least from my testing I can't find any issue when just following the linked wiki article - but I have to admit that I cheated a bit: no pppoe (couldn't find a server to simulate that link), using systemd for dhcp instead of dhcpd or dnsmasq, using dns of upstream router instead of providing one, no firewall - but I don't think any of these have anything to do with OPs issue about TLSv1.0 vs 1.2/1.3 as TLS is already at layer 4 and all that routing stuff only happens up to layer 3

TLDR: whatever OP has setup - as hooking up the clients directly to the modem works without issues it has to do something with how OP has setup the arch router
anyway - although it seems easy (maybe setting up proper firewalls can be a bit tricky) I still recommend to use existing solutions like openwrt of pf-/opensense unless you really know what you're doing
the wiki makes it quite clear: use the route only as such - for lan services use an additional system

Arch Linux

#1 2024-12-21 11:57:07

Network problems

#2 2024-12-21 12:13:53

Re: Network problems

#3 2024-12-21 12:45:45

Re: Network problems

#4 2024-12-21 13:05:14

Re: Network problems

#5 2024-12-21 13:23:58

Re: Network problems

#6 2024-12-21 13:56:45

Re: Network problems

#7 2024-12-21 14:17:29

Re: Network problems

#8 2024-12-21 14:19:57

Re: Network problems

#9 2024-12-21 14:45:14

Re: Network problems

#10 2024-12-21 14:52:18

Re: Network problems

#11 2024-12-21 20:31:21

Re: Network problems

#12 2024-12-21 21:10:00

Re: Network problems

#13 2024-12-21 22:48:42

Re: Network problems

#14 2024-12-22 08:51:32

Re: Network problems

#15 2024-12-22 09:06:21

Re: Network problems

#16 2024-12-22 12:39:28

Re: Network problems

#17 2024-12-22 13:55:54

Re: Network problems

#18 2025-01-08 13:56:03

Re: Network problems

Board footer