From steve36lives at hotmail.com Fri Feb 6 11:29:40 2026 From: steve36lives at hotmail.com (Steve Schrader) Date: Fri, 6 Feb 2026 03:29:40 +0000 Subject: [plug] Plug in the Pub - March Message-ID: Happy New Year, Everybody !! The first Plug-in-the-Pub for 2026 has been booked. For a good time, meet us at: Durty Nelly's 397 Murray St (Shafto Lane) Perth Wednesday 11th March, 2026 6pm - 8pm Be there ... or be elsewhere !! Steve S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at spottedmouse.com Wed Feb 11 18:54:20 2026 From: alex at spottedmouse.com (Alex H.) Date: Wed, 11 Feb 2026 18:54:20 +0800 Subject: [plug] IPTables Message-ID: <000a01dc9b44$c6b16c30$54144490$@spottedmouse.com> Hi all, Just having some fun with iptables. I am trying to route traffic from AWS(10.0.0.1) to my local server (10.0.0.2) using wireguard. I have setup a connection on vpn0 on both servers, but I am struggling a little with iptables. While I am experimenting I setup the following iptables rules using this script on the AWS VPN server. I plan to include some of these inside the wireguard configuration once I have it all working. root at vpn:~# cat routeTraffic.sh #!/bin/bash iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -i vpn0 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 25 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 53 -j ACCEPT iptables -A INPUT -i ens5 -p udp -m udp --dport 53 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 80 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 443 -j ACCEPT iptables -A INPUT -i ens5 -p udp -m udp --dport 55107 -j ACCEPT iptables -A INPUT -i vpn0 -p udp -m udp --dport 55107 -j ACCEPT iptables -A INPUT -i ens5 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT iptables -A OUTPUT -j ACCEPT # 1. Redirect the incoming packet to the tunnel destination iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to-destination 10.0.0.2:53 iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.0.0.2:53 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:443 # 2. Allow the traffic through via the FORWARD chain iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p udp -d 10.0.0.2 --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -j LOG # 3. Apply Masquerading to ensure return traffic goes back through the server iptables -t nat -A POSTROUTING -o vpn0 -j MASQUERADE Initially I had "iptables -P FORWARD DROP" with the hope of adding a white-list of allowed rules. However, this didn't work. I then added the LOG statement which produces the following: Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=64296 RES=0x00 ACK SYN URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=42901 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42902 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42904 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 Feb 11 10:46:38 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.Y.Y LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=443 DPT=59476 WINDOW=64860 RES=0x00 ACK SYN URGP=0 Any suggestions on what FORWARD rule I need to add for this to work with FORWARD DROP ? It looks like these are the response packets which come from VPN0 and are going back to the internet on ENS5. I though the "NEW,ESTABLISHED,RELATED" statement would handle these as they are part of the response in return an accepted request. Any thought or suggestions would be most helpful. Kind regards Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From byronester at gmail.com Thu Feb 12 09:13:39 2026 From: byronester at gmail.com (Byron Hammond) Date: Thu, 12 Feb 2026 09:13:39 +0800 Subject: [plug] IPTables In-Reply-To: <000a01dc9b44$c6b16c30$54144490$@spottedmouse.com> References: <000a01dc9b44$c6b16c30$54144490$@spottedmouse.com> Message-ID: Not answering the question here but I just wanted to add that you will need to have `sysctl net.ipv4.ip_forward` enabled as well if not already. Google something like "ip4 forward sysctl" On Wed, 11 Feb 2026 at 18:54, Alex H. via plug wrote: > Hi all, > > > > Just having some fun with iptables. I am trying to route traffic from > AWS(10.0.0.1) to my local server (10.0.0.2) using wireguard. > > > > I have setup a connection on vpn0 on both servers, but I am struggling a > little with iptables. > > > > While I am experimenting I setup the following iptables rules using this > script on the AWS VPN server. > > I plan to include some of these inside the wireguard configuration once I > have it all working. > > > > root at vpn:~# cat routeTraffic.sh > > #!/bin/bash > > > > iptables -F > > iptables -X > > iptables -t nat -F > > iptables -t nat -X > > iptables -t mangle -F > > iptables -t mangle -X > > > > iptables -P INPUT DROP > > iptables -P OUTPUT DROP > > iptables -P FORWARD ACCEPT > > > > iptables -A INPUT -i ens5 -p tcp -m tcp --dport 22 -j ACCEPT > > iptables -A INPUT -i vpn0 -p tcp -m tcp --dport 22 -j ACCEPT > > iptables -A INPUT -i ens5 -p tcp -m tcp --dport 25 -j ACCEPT > > iptables -A INPUT -i ens5 -p tcp -m tcp --dport 53 -j ACCEPT > > iptables -A INPUT -i ens5 -p udp -m udp --dport 53 -j ACCEPT > > iptables -A INPUT -i ens5 -p tcp -m tcp --dport 80 -j ACCEPT > > iptables -A INPUT -i ens5 -p tcp -m tcp --dport 443 -j ACCEPT > > iptables -A INPUT -i ens5 -p udp -m udp --dport 55107 -j ACCEPT > > iptables -A INPUT -i vpn0 -p udp -m udp --dport 55107 -j ACCEPT > > iptables -A INPUT -i ens5 -m conntrack --ctstate RELATED,ESTABLISHED -j > ACCEPT > > > > iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT > > iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT > > > > iptables -A OUTPUT -j ACCEPT > > > > # 1. Redirect the incoming packet to the tunnel destination > > iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to-destination > 10.0.0.2:53 > > iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination > 10.0.0.2:53 > > iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination > 10.0.0.2:80 > > iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination > 10.0.0.2:443 > > > > # 2. Allow the traffic through via the FORWARD chain > > iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 53 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -p udp -d 10.0.0.2 --dport 53 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 80 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 443 -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -j LOG > > > > # 3. Apply Masquerading to ensure return traffic goes back through the > server > > iptables -t nat -A POSTROUTING -o vpn0 -j MASQUERADE > > > > Initially I had ?iptables -P FORWARD DROP? with the hope of adding a > white-list of allowed rules. However, this didn?t work. I then added the > LOG statement which produces the following: > > > > Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 > DST=176.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 > DPT=55784 WINDOW=64296 RES=0x00 ACK SYN URGP=0 > > Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 > DST=176.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=42901 DF PROTO=TCP SPT=80 > DPT=55784 WINDOW=502 RES=0x00 ACK URGP=0 > > Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 > DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42902 DF PROTO=TCP > SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 > > Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 > DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42904 DF PROTO=TCP > SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 > > Feb 11 10:46:38 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 > DST=176.X.Y.Y LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=443 > DPT=59476 WINDOW=64860 RES=0x00 ACK SYN URGP=0 > > > > Any suggestions on what FORWARD rule I need to add for this to work with > FORWARD DROP ? It looks like these are the response packets which come from > VPN0 and are going back to the internet on ENS5. I though the > ?NEW,ESTABLISHED,RELATED? statement would handle these as they are part of > the response in return an accepted request. > > > > Any thought or suggestions would be most helpful. > > Kind regards > > Alex > _______________________________________________ > PLUG discussion list: plug at plug.org.au > https://lists.plug.org.au/mailman/listinfo/plug > Committee e-mail: committee at plug.org.au > PLUG Membership: http://www.plug.org.au/membership > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at spottedmouse.com Thu Feb 12 11:03:05 2026 From: alex at spottedmouse.com (Alex H.) Date: Thu, 12 Feb 2026 11:03:05 +0800 Subject: [plug] IPTables In-Reply-To: References: <000a01dc9b44$c6b16c30$54144490$@spottedmouse.com> Message-ID: <003001dc9bcc$20ed5290$62c7f7b0$@spottedmouse.com> Thanks for this. My mistake was: iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT instead of: iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -d 10.0.0.2 -p tcp --dport 443 -m state --state NEW -j ACCEPT Having separate statements for the established, related packets and new package resolved my problem Thanks for all your help Alex From: plug On Behalf Of Byron Hammond via plug Sent: Thursday, 12 February 2026 9:14 To: Alex H. Cc: plug at plug.org.au Subject: Re: [plug] IPTables Not answering the question here but I just wanted to add that you will need to have `sysctl net.ipv4.ip_forward` enabled as well if not already. Google something like "ip4 forward sysctl" On Wed, 11 Feb 2026 at 18:54, Alex H. via plug > wrote: Hi all, Just having some fun with iptables. I am trying to route traffic from AWS(10.0.0.1) to my local server (10.0.0.2) using wireguard. I have setup a connection on vpn0 on both servers, but I am struggling a little with iptables. While I am experimenting I setup the following iptables rules using this script on the AWS VPN server. I plan to include some of these inside the wireguard configuration once I have it all working. root at vpn:~# cat routeTraffic.sh #!/bin/bash iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -i vpn0 -p tcp -m tcp --dport 22 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 25 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 53 -j ACCEPT iptables -A INPUT -i ens5 -p udp -m udp --dport 53 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 80 -j ACCEPT iptables -A INPUT -i ens5 -p tcp -m tcp --dport 443 -j ACCEPT iptables -A INPUT -i ens5 -p udp -m udp --dport 55107 -j ACCEPT iptables -A INPUT -i vpn0 -p udp -m udp --dport 55107 -j ACCEPT iptables -A INPUT -i ens5 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT iptables -A OUTPUT -j ACCEPT # 1. Redirect the incoming packet to the tunnel destination iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to-destination 10.0.0.2:53 iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.0.0.2:53 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:443 # 2. Allow the traffic through via the FORWARD chain iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p udp -d 10.0.0.2 --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -d 10.0.0.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -j LOG # 3. Apply Masquerading to ensure return traffic goes back through the server iptables -t nat -A POSTROUTING -o vpn0 -j MASQUERADE Initially I had ?iptables -P FORWARD DROP? with the hope of adding a white-list of allowed rules. However, this didn?t work. I then added the LOG statement which produces the following: Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=64296 RES=0x00 ACK SYN URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=42901 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42902 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 Feb 11 10:46:19 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.X.X LEN=2788 TOS=0x00 PREC=0x00 TTL=63 ID=42904 DF PROTO=TCP SPT=80 DPT=55784 WINDOW=502 RES=0x00 ACK PSH URGP=0 Feb 11 10:46:38 vpn.host.com kernel: IN=vpn0 OUT=ens5 MAC= SRC=10.0.0.2 DST=176.X.Y.Y LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=443 DPT=59476 WINDOW=64860 RES=0x00 ACK SYN URGP=0 Any suggestions on what FORWARD rule I need to add for this to work with FORWARD DROP ? It looks like these are the response packets which come from VPN0 and are going back to the internet on ENS5. I though the ?NEW,ESTABLISHED,RELATED? statement would handle these as they are part of the response in return an accepted request. Any thought or suggestions would be most helpful. Kind regards Alex _______________________________________________ PLUG discussion list: plug at plug.org.au https://lists.plug.org.au/mailman/listinfo/plug Committee e-mail: committee at plug.org.au PLUG Membership: http://www.plug.org.au/membership -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at spottedmouse.com Thu Feb 12 23:49:42 2026 From: alex at spottedmouse.com (Alex H.) Date: Thu, 12 Feb 2026 23:49:42 +0800 Subject: [plug] Bypass CGNAT for hosting website and email In-Reply-To: References: <003601dc431c$97764c90$c662e5b0$@spottedmouse.com> Message-ID: <000001dc9c37$3474dac0$9d5e9040$@spottedmouse.com> Thanks James, I have followed your advice and installed a wireguard based solution to forward a number of ports to my internal server. Did you find a solution to expose the original source IP address to the internal server. This would allow me to deploy fail2ban for extra security. Currently all requests on the internal server seem to be from the wireguard address. Which makes sense, since I am doing NAT with iptables. Any suggestions or thoughts are appreciated. Kind regards Alex -----Original Message----- From: James Henstridge Sent: Friday, 24 October 2025 14:32 To: alex at spottedmouse.com Cc: plug at plug.org.au Subject: Re: [plug] Bypass CGNAT for hosting website and email On Wed, 22 Oct 2025 at 14:25, wrote: > For some time I have been researching options to host a website and email behind CGNAT. Cloudflare tunnels seemed to address the website nicely, but doesn?t support SMTP etc. > > Hosting a VPS and directing traffic over a VPN is another option. Any recommendations ? > > Ideally I am not looking to spend a lot of money on this as it is only for my home lab. > > Much appreciate any guidance and advise. Having gone through some of this with the recent PLUG server move, you will want a static IP address with reverse DNS pointing to your domain. Without that, you may have difficulty getting other servers to accept email from you. This probably means renting a VM from some hosting provider. The new PLUG server is using Binary Lane (https://www.binarylane.com.au/), who are local and good value. They will set the PTR record for the IP address to whatever you want. They'll also give you console access to your VM via the website if you break things to a point where you can't ssh into the VM. While you could run your services on the VM, you could try something like described here: https://mjg59.dreamwidth.org/72095.html In essence, run a Wireguard VPN tunnel between your home and the VPS, and then use destination NAT and routing tricks to direct traffic down the VPN to home. He's glossing over a few steps in his description of the setup (e.g. I suspect he's not forwarding the same IP address as he is using as the VPN endpoint), so it might not be a beginner friendly option. James. From alex at spottedmouse.com Fri Feb 13 09:33:19 2026 From: alex at spottedmouse.com (Alex H.) Date: Fri, 13 Feb 2026 09:33:19 +0800 Subject: [plug] Bypass CGNAT for hosting website and email References: <003601dc431c$97764c90$c662e5b0$@spottedmouse.com> Message-ID: <0de601dc9c88$bc49c9f0$34dd5dd0$@spottedmouse.com> Hi James Thanks for this. After reading the link you suggested more carefully (https://mjg59.dreamwidth.org/72095.html) I got it working nicely. Learnt a lot as well in the process. Kind regards Alex -----Original Message----- From: Alex H. Sent: Thursday, 12 February 2026 23:50 To: 'James Henstridge' Cc: 'plug at plug.org.au' Subject: RE: [plug] Bypass CGNAT for hosting website and email Thanks James, I have followed your advice and installed a wireguard based solution to forward a number of ports to my internal server. Did you find a solution to expose the original source IP address to the internal server. This would allow me to deploy fail2ban for extra security. Currently all requests on the internal server seem to be from the wireguard address. Which makes sense, since I am doing NAT with iptables. Any suggestions or thoughts are appreciated. Kind regards Alex -----Original Message----- From: James Henstridge Sent: Friday, 24 October 2025 14:32 To: alex at spottedmouse.com Cc: plug at plug.org.au Subject: Re: [plug] Bypass CGNAT for hosting website and email On Wed, 22 Oct 2025 at 14:25, wrote: > For some time I have been researching options to host a website and email behind CGNAT. Cloudflare tunnels seemed to address the website nicely, but doesn?t support SMTP etc. > > Hosting a VPS and directing traffic over a VPN is another option. Any recommendations ? > > Ideally I am not looking to spend a lot of money on this as it is only for my home lab. > > Much appreciate any guidance and advise. Having gone through some of this with the recent PLUG server move, you will want a static IP address with reverse DNS pointing to your domain. Without that, you may have difficulty getting other servers to accept email from you. This probably means renting a VM from some hosting provider. The new PLUG server is using Binary Lane (https://www.binarylane.com.au/), who are local and good value. They will set the PTR record for the IP address to whatever you want. They'll also give you console access to your VM via the website if you break things to a point where you can't ssh into the VM. While you could run your services on the VM, you could try something like described here: https://mjg59.dreamwidth.org/72095.html In essence, run a Wireguard VPN tunnel between your home and the VPS, and then use destination NAT and routing tricks to direct traffic down the VPN to home. He's glossing over a few steps in his description of the setup (e.g. I suspect he's not forwarding the same IP address as he is using as the VPN endpoint), so it might not be a beginner friendly option. James. From bill at kenworthy.id.au Sat Feb 21 10:16:34 2026 From: bill at kenworthy.id.au (William Kenworthy) Date: Sat, 21 Feb 2026 10:16:34 +0800 Subject: [plug] Framework13 laptop Message-ID: <6ac83626-38a6-4dce-8671-e05af64482cd@kenworthy.id.au> Hi, my MS surface pro4 has hit its EOL - increasingly chronic overheating compiling gentoo so its replacement time! I am looking at a Framework13 Laptop (mid-range amd cpu) - does anyone have any experience with Framework hardware and can comment on its longevity and warranty etc? I can get a Dell or something similar at half the cost but I want to keep the new one 10 years or so without the unexpected compatibility issue that plagued the Surface - patching kernels for propriety hardware ... etc. - took a few years before hardware support caught up :( BillK From paul at thecave.ws Sat Feb 21 20:29:10 2026 From: paul at thecave.ws (Paul Dean) Date: Sat, 21 Feb 2026 20:29:10 +0800 Subject: [plug] Framework13 laptop In-Reply-To: <6ac83626-38a6-4dce-8671-e05af64482cd@kenworthy.id.au> References: <6ac83626-38a6-4dce-8671-e05af64482cd@kenworthy.id.au> Message-ID: <77bf08285aff5e0dc6df9a31fecee29b@thecave.ws> Hey Bill, I can highly recommend the Framework laptops, I got and have had mine for nearly 2+yrs now, running Debian 11,12 and now 13. Superb support for Linux, solid hardware, and completely modular, very easy to construct and then upgrade later doing the track. UFEI/BIOS well supported, including secure boot. We also just begun moving our staff at work onto the Framework and they are very happy with them(one lady, very picky, is raving about hers, said "She'll never use anything else, and told M$ to 'go shove it' and moved to Linux." So 'nuff said, enjoy open sause(source) software and now hardware. --- Thanks Paul Dean. "Life is not WHAT you make it, it's WHO you have in it..." On 2026-02-21 10:16, William Kenworthy via plug wrote: > Hi, my MS surface pro4 has hit its EOL - increasingly chronic > overheating compiling gentoo so its replacement time! > > I am looking at a Framework13 Laptop (mid-range amd cpu) - does anyone > have any experience with Framework hardware and can comment on its > longevity and warranty etc? > > I can get a Dell or something similar at half the cost but I want to > keep the new one 10 years or so without the unexpected compatibility > issue that plagued the Surface - patching kernels for propriety > hardware ... etc. - took a few years before hardware support caught up > :( > > BillK > > > _______________________________________________ > PLUG discussion list: plug at plug.org.au > https://lists.plug.org.au/mailman/listinfo/plug > Committee e-mail: committee at plug.org.au > PLUG Membership: http://www.plug.org.au/membership From bill at kenworthy.id.au Sat Feb 21 20:37:37 2026 From: bill at kenworthy.id.au (William Kenworthy) Date: Sat, 21 Feb 2026 20:37:37 +0800 Subject: [plug] Framework13 laptop In-Reply-To: <77bf08285aff5e0dc6df9a31fecee29b@thecave.ws> References: <6ac83626-38a6-4dce-8671-e05af64482cd@kenworthy.id.au> <77bf08285aff5e0dc6df9a31fecee29b@thecave.ws> Message-ID: <1d91b6b4-3951-4c3c-8eee-0a19be26f9fc@kenworthy.id.au> Thanks Dean, that's encouraging! BillK On 21/2/26 20:29, Paul Dean wrote: > Hey Bill, > > I can highly recommend the Framework laptops, I got and have had mine > for nearly 2+yrs now, running Debian 11,12 and now 13. > > Superb support for Linux, solid hardware, and completely modular, very > easy to construct and then upgrade later doing the track. > > UFEI/BIOS well supported, including secure boot. > > We also just begun moving our staff at work onto the Framework and > they are very happy with them(one lady, very picky, is raving about > hers, said "She'll never use anything else, and told M$ to 'go shove > it' and moved to Linux." > > So 'nuff said, enjoy open sause(source) software and now hardware. > > --- > Thanks > > Paul Dean. > > "Life is not WHAT you make it, it's WHO you have in it..." > > On 2026-02-21 10:16, William Kenworthy via plug wrote: >> Hi, my MS surface pro4 has hit its EOL - increasingly chronic >> overheating compiling gentoo so its replacement time! >> >> I am looking at a Framework13 Laptop (mid-range amd cpu) - does >> anyone have any experience with Framework hardware and can comment on >> its longevity and warranty etc? >> >> I can get a Dell or something similar at half the cost but I want to >> keep the new one 10 years or so without the unexpected compatibility >> issue that plagued the Surface - patching kernels for propriety >> hardware ... etc. - took a few years before hardware support caught >> up :( >> >> BillK >> >> >> _______________________________________________ >> PLUG discussion list: plug at plug.org.au >> https://lists.plug.org.au/mailman/listinfo/plug >> Committee e-mail: committee at plug.org.au >> PLUG Membership: http://www.plug.org.au/membership > > >