From nobody Wed Apr 24 18:05:33 2024 X-Original-To: freebsd-net@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 4VPn396zJ0z5J4Sb for ; Wed, 24 Apr 2024 18:05:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPn395K7Yz40jP; Wed, 24 Apr 2024 18:05:41 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.17.1/8.16.1) with ESMTPS id 43OI5XKw014124 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Wed, 24 Apr 2024 14:05:33 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:50c:96ad:c667:424f] ([IPv6:2607:f3e0:0:4:50c:96ad:c667:424f]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43OI5Wsj061333 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 24 Apr 2024 14:05:32 -0400 (EDT) (envelope-from mike@sentex.net) Content-Type: multipart/alternative; boundary="------------yyOEuZIT3LtYQpKGACz0B0z1" Message-ID: <42ac4479-53bc-4576-a81a-f71ce4e03986@sentex.net> Date: Wed, 24 Apr 2024 14:05:33 -0400 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Source IPv4 address selection vs BGP IX connection To: Gregory Shapiro , freebsd-net@freebsd.org References: Content-Language: en-US From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== In-Reply-To: X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Queue-Id: 4VPn395K7Yz40jP This is a multi-part message in MIME format. --------------yyOEuZIT3LtYQpKGACz0B0z1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/23/2024 10:12 PM, Gregory Shapiro wrote: > Short version: > > Using FreeBSD as a BGP router has network issues caused by suboptimal > default IPv4 source address selection when connected to Internet > Exchanges (which are required to use IPs that aren't routable on the > Internet). I was hoping to find more elegant workarounds or encourage > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > address selection (no_prefer_iface and prefer_source). > > I assume that there is a group of BGP enthusiasts using FreeBSD lurking > on freebsd-net. What have you done to solve this problem? > For DNS in such situations I start unbound locally and bind it to an internal interface or an IP on lo0 and then tell unbound to just use that IP only  (outgoing-interface IIRC) that is advertised out as a work around.  Its not a proper solution, but will get your resolver working at least. I run into this problem in layered networks where the next hop is often RFC 1918 addrs. I bind applications to internal NICs that have addresses that have routing to/from.     ---Mike --------------yyOEuZIT3LtYQpKGACz0B0z1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 4/23/2024 10:12 PM, Gregory Shapiro wrote:
Short version:

Using FreeBSD as a BGP router has network issues caused by suboptimal
default IPv4 source address selection when connected to Internet
Exchanges (which are required to use IPs that aren't routable on the
Internet).  I was hoping to find more elegant workarounds or encourage
FreeBSD to add source IPv4 selection akin to the existing IPv6 source
address selection (no_prefer_iface and prefer_source).

I assume that there is a group of BGP enthusiasts using FreeBSD lurking
on freebsd-net.  What have you done to solve this problem?

For DNS in such situations I start unbound locally and bind it to an internal interface or an IP on lo0 and then tell unbound to just use that IP only  (outgoing-interface IIRC) that is advertised out as a work around.  Its not a proper solution, but will get your resolver working at least. I run into this problem in layered networks where the next hop is often RFC 1918 addrs. I bind applications to internal NICs that have addresses that have routing to/from.

    ---Mike

--------------yyOEuZIT3LtYQpKGACz0B0z1--