From nobody Thu Mar 07 17:36:28 2024 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TrGgl25fHz5DQHL for ; Thu, 7 Mar 2024 17:36:35 +0000 (UTC) (envelope-from dracolich@airmail.cc) Received: from mail.cock.li (mail.cock.li [37.120.193.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TrGgh6Cp5z4Lkm for ; Thu, 7 Mar 2024 17:36:32 +0000 (UTC) (envelope-from dracolich@airmail.cc) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=airmail.cc header.s=mail header.b=oiYcyBfJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of dracolich@airmail.cc designates 37.120.193.123 as permitted sender) smtp.mailfrom=dracolich@airmail.cc List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1709832988; bh=QGpmiQppmIM+A4QTTW/8iQYuaqqE0b09NKg4leCrTYM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=oiYcyBfJUVgeG5eACkxGHis2RGAekKXMsABFACthNxbilDhWj7HXF0gfwpQUqkASo sIcu97J5CsQm8/qHfS3XESiplzJxo/Q98XO55r4u7/zbjOrXU4eozPobSFjnLdvuuc WMwRTjs0FvS+bwaOzYtyHAvbiEerl7wYDUcuNXROzkp9o3Fbf7SEcX1E3Ro7q0vNYd 23uGsrYE1hHyAnW3gqJdGVq29Dw9NJXDrt1TPNur1opMcCkpWWDgU327BgnM1xI6v9 kGWS2cjzGgI0A/bBkN5jZsFZXs57A0+vlG0ciLAEHpRXfBbVcof0HD6J77oaM0Y8Kv 87xMoCJeBR/IA== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 07 Mar 2024 17:36:28 +0000 From: Christopher Waldbach To: questions@freebsd.org Subject: Re: Setting up a Wireguard router (with FreeBSD) In-Reply-To: References: <00f7b360407633f787f061b4d15740b9@airmail.cc> <17ae35e240ce2ec5cb414251e4fca43c@airmail.cc> User-Agent: Roundcube Webmail/1.4.15 Message-ID: <5355beb513e7b1f3e975130886b14ade@airmail.cc> X-Sender: dracolich@airmail.cc X-Spamd-Bar: / X-Spamd-Result: default: False [-0.97 / 15.00]; RBL_VIRUSFREE_BOTNET(2.00)[37.120.193.123:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.97)[-0.973]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; R_SPF_ALLOW(0.00)[+ip4:37.120.193.120/29]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; ASN(0.00)[asn:9009, ipnet:37.120.193.0/24, country:RO]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[airmail.cc]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; R_DKIM_ALLOW(0.00)[airmail.cc:s=mail]; DKIM_TRACE(0.00)[airmail.cc:+] X-Rspamd-Queue-Id: 4TrGgh6Cp5z4Lkm On 2024-03-07 00:09, Kurt Hackenberg wrote: >> I should habe known someone would be pedantic. :-) >> My ISP does not give me _my own_ public IPv4 address. :-D >> My ISP only provides a DS-Lite connection, which in my case means my >> router is assigned an IP within the >> 100.64.0.0/10 realm. > Not pedantic, confused, by a major lack of information about your > setup. Sorry, no offense intended! > I'd never heard of that shared address space or of DS-Lite. Just > looked them up, got the idea. > [...] This practice is so common in Germany and in other European countries, that I assumed my (rather brief) reference would be enough to let people know what I was going on about. I thought it was well known. In Germany just about all ISPs use this method - some better than others. The only ISP who still gives out public IPv4 addresses (that I know of) to consumers is Deutsche Telekom - however, this knowledge isn't exactly current. If you get a cable connection with Vodafone, you're outa luck, unless you pay for a company line. On a Vodafone DSL it was possible, but I don't know if that is still the case. 1&1 still give you one, but you have to ask nicely. Just about anyone else will only give you a public IPv4 address if you are prepared to shell out some major cash. For example, I pay 60€ for my connection per month, a public IPv4 address is not an option. The prices for plans for firms who want one are not made public ATM, but a while back they were and I'd have had to shell out upwards of 240€ for one - with less bandwidth than I have now. There will be other differences (mainly in the area of reliability), but you get the idea. Most people will not need a public IPv4 address or know what to do with one, so in most cases, noone cares. Considering this, I can get behind the approach of 1&1. > All this is to squeeze the last drop out of IPv4 public addresses, > which ran out in 2011. Of course. IPv4 is still a way too important part of the net for it to be optional. My current ISP is one of the newer ones and as such only got a pretty small pool of IPv4 addresses. This is a way for them to function while plenty of bigger companies sit on there largely unused pools of addresses. > So, I guess you're putting a tunnel inside an existing tunnel that > goes to some faraway IPv4 NAT. And I guess there's another NAT in > your router, between your private IPv4 network and a single address on > the other side of your router, within 100.64.0.0/10. Is all that > right? Complicated. Not surprising there's some trouble. You are making it sound much more complicated than it is. :-) The CGN and everything my ISP does is completely transparent to me. It works fine. Even the VPN-tunnel works fine: When I fire up the interface and do a traceroute (mtr), I can see that the route is completely different and begins in a different country. I can download things and everything. What now no longer works is using this little machine as a router. Once the wg0 interface is fired up, the Pi no longer passes on anything from a machine behind it. So the problem is more within the Pi itself. Put a little more graphically: Case 1 (!Wireguard): Pi -> [genet0] -> inet Case 2 (!Wireguard): comp -> [genet0] -> Pi -> [genet0] -> inet Case 3 (Wireguard): Pi -> [wg0] -> inet Case 4 (Wireguard): comp -> [genet0] -> Pi -> [wg0] -> inet Cases 1-3 all work, only case 4 does not. In cases 1 and 3, the traffic originates in the Pi, in the other two cases the traffic originates on a different computer. A Pi4 only has one ethernet connector (device genet0) and thus the traffic goes in and leaves via the same port. What it looks like to me is that no packets are moved between genet0 and the virtual device wg0. wg0 works in a different IP-space, so some NAT would clearly be required. But does this actually require a firewall config? Best regards, Chris