Recent searches

No recent searches

Search options

Only available when logged in.
shakedown.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A community for live music fans with roots in the jam scene. Shakedown Social is run by a team of volunteers (led by @clifff and @sethadam1) and funded by donations.

Administered by:

Server stats:

263
active users

shakedown.social: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.1

#nat

0 posts0 participants0 posts today
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://oldbytes.space/@drscriptt" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>drscriptt</span></a></span> Naive question: <em>WHEN</em> does the average <a href="https://infosec.space/tags/Internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Internet</span></a> <a href="https://infosec.space/tags/user" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>user</span></a> ever open up a webpage with an <a href="https://infosec.space/tags/IP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IP</span></a> address instead of a <a href="https://infosec.space/tags/domain" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domain</span></a> or even <a href="https://infosec.space/tags/FQDN" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FQDN</span></a>?</p><ul><li>Seriously, the only cases I saw were either some old, non-public - facing server in some B2B/API setting <em>or</em> a test that <a href="https://infosec.space/tags/httpd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>httpd</span></a> / <a href="https://infosec.space/tags/ngnix" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ngnix</span></a> / <a href="https://infosec.space/tags/ssh" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ssh</span></a> / … function properly on like a <a href="https://infosec.space/tags/VPS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>VPS</span></a> and that the <a href="https://infosec.space/tags/DNS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNS</span></a> hasn't been updated (yet!) to include said host / FQDN in the records, and even then it's <em>bad</em> cuz you'd rather want to use it's FQDN instead because with <a href="https://infosec.space/tags/IPv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4</span></a> shortages on one hand and tools like <a href="https://infosec.space/tags/Portainer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Portainer</span></a> on the other, one should not use an <a href="https://infosec.space/tags/IPaddress" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPaddress</span></a> as addressing method because <a href="https://infosec.space/tags/WAF" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WAF</span></a> / <a href="https://infosec.space/tags/Proxies" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Proxies</span></a> used to <em>"<a href="https://infosec.space/tags/MUX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MUX</span></a>"</em> / <em>"<a href="https://infosec.space/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a>"</em> services under one IP address or <a href="https://infosec.space/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> block may need that distinction by being queried for a specific FQDN... </li></ul><p>The Idea if !SSL / <a href="https://infosec.space/tags/TLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLD</span></a> for <a href="https://infosec.space/tags/IPaddresses" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPaddresses</span></a> makes me <a href="https://www.youtube.com/watch?v=g3j9muCo4o0" rel="nofollow noopener" target="_blank">feel like Jeff Goldblum!</a></p>
argv minus one<p>One of the great and wonderful things about the early <a href="https://mastodon.sdf.org/tags/Internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Internet</span></a> was that you could send a packet, containing whatever bytes you want, to *any* computer, anywhere in the world, at will and without ceremony.</p><p>Then dynamic addressing and <a href="https://mastodon.sdf.org/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> came along and ruined everything. 😭</p>
mkj<p>Do I have anyone within my reach who would be willing to help me debug a DNAT issue on OPNsense?</p><p>I can sincerely say that it's *probably* trivial, and I am *probably* just missing something obvious; but it's not obvious when you're not quite sure what you're looking for. Reading the documentation, browsing the forum and searching the web has not led me to find a solution.</p><p>Boosts appreciated.</p><p><a href="https://social.mkj.earth/tags/OPNsense" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OPNsense</span></a> <a href="https://social.mkj.earth/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> <a href="https://social.mkj.earth/tags/DNAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNAT</span></a> <a href="https://social.mkj.earth/tags/network" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>network</span></a> <a href="https://social.mkj.earth/tags/networking" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>networking</span></a> <a href="https://social.mkj.earth/tags/TCPIP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TCPIP</span></a></p>
Rynn 🌙 Professional Cyberwitch 🌙<p>Hey other <a href="https://furry.engineer/tags/network" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>network</span></a> folks I have a weird <a href="https://furry.engineer/tags/firewall" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>firewall</span></a> and <a href="https://furry.engineer/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> question. I'm looking at the firewall traffic log where my work laptop (I'm in the office) is the source, and I'm looking at the traffic connecting to my home plex server. </p><p>The plex server is a private IP behind NAT. In the log I show the putbound traffic from my work laptop to my home router IP, but I also see a following entry with the private IP that my router is forwarding plex's port traffic to. I thought anything done behind NAT wouldn't show up, especially because I'm only looking at the initial communication out, and not the return communication from my server to my me. Is my understanding of NAT wrong?</p>
Litchralee_v6<p>What Docker did was to intellectually limit the creativity that users could have had with containers, funneling everyone into the most trivial of network use-cases. When everything is server-client, it's really hard to develop peer-to-peer or avant guard applications.</p><p>The parallels to <a href="https://ipv6.social/tags/LegacyIP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LegacyIP</span></a> and <a href="https://ipv6.social/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> are staggering, as they too stymied progress in other, not-yet imagined scenarios. <a href="https://ipv6.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> should have been the go-to for hyperscalar from day-one. That it wasn't is forever a travesty.</p><p>7/n</p>
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://mstdn.jp/@landley" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>landley</span></a></span> <span class="h-card" translate="no"><a href="https://mstdn.social/@jschauma" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>jschauma</span></a></span> <span class="h-card" translate="no"><a href="https://infosec.exchange/@ryanc" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>ryanc</span></a></span> <span class="h-card" translate="no"><a href="https://infosec.exchange/@0xabad1dea" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>0xabad1dea</span></a></span> yeah, the exhaustion problem would've been shoved back with a <a href="https://infosec.space/tags/64bit" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>64bit</span></a> or sufficiently delayed by a 40bit number.</p><p>Unless we also hate <a href="https://infosec.space/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> and expect every device to have a unique static <a href="https://infosec.space/tags/IP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IP</span></a> (which is a <a href="https://infosec.space/tags/privacy" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>privacy</span></a> nightmare at best that <em>"<a href="https://infosec.space/tags/PrivacyExtensions" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PrivacyExtensions</span></a>"</em> barely fixed.) </p><ul><li>I mean they could've also gone the <a href="https://infosec.space/tags/DECnet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DECnet</span></a> approach and use the <a href="https://infosec.space/tags/EUI48" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>EUI48</span></a> / <a href="https://infosec.space/tags/MAC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MAC</span></a>-Address (or <a href="https://infosec.space/tags/EUI64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>EUI64</span></a>) as static addressing system, but that would've made <a href="https://infosec.space/tags/vendors" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>vendors</span></a> and not <a href="https://infosec.space/tags/ISPs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ISPs</span></a> the powerful forces of allocation. (Similar to how technically the <a href="https://infosec.space/tags/ICCID" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICCID</span></a> dictates <a href="https://infosec.space/tags/GSM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GSM</span></a> / <a href="https://infosec.space/tags/4G" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>4G</span></a> / <a href="https://infosec.space/tags/5G" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>5G</span></a> access and not the <a href="https://infosec.space/tags/IMEI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IMEI</span></a> unless places like Australia ban imported devices.</li></ul> <p>I guess using a <a href="https://infosec.space/tags/128bit" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>128bit</span></a> address space was inspired by <a href="https://infosec.space/tags/ZFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ZFS</span></a> doing the same <em>before</em>, as the folks who designed both wanted to design a solution that clearly will outlive them (<em>way harder</em> than COBOL has outlived Grace Hopper)...</p><ul><li>Personally I've only had headaches with <a href="https://infosec.space/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> because not only do I only have <a href="https://infosec.space/tags/IPv4only" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4only</span></a> <a href="https://infosec.space/tags/Internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Internet</span></a> but my <a href="https://infosec.space/tags/ISP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ISP</span></a> refuses to allocate even a singe /64 to me (but has no problem throwing in a free /29 of <a href="https://infosec.space/tags/IPv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4</span></a>'s in with my contract!)and stuff like <a href="https://infosec.space/tags/HurricaneElectric" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HurricaneElectric</span></a> / <a href="https://infosec.space/tags/HEnet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HEnet</span></a>'s <a href="https://infosec.space/tags/Tunnelbroker" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Tunnelbroker</span></a> fail face first due to <a href="https://infosec.space/tags/Geoblocking" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Geoblocking</span></a> and the fact that <a href="https://infosec.space/tags/ASNs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ASNs</span></a> get geolocated, not their <a href="https://infosec.space/tags/PoPs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PoPs</span></a>... </li></ul><p>If I was <span class="h-card" translate="no"><a href="https://social.bund.de/@BNetzA" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>BNetzA</span></a></span> I would've mandated <a href="https://infosec.space/tags/DualStack" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DualStack</span></a> and banned <a href="https://infosec.space/tags/CGNAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CGNAT</span></a> (or at least the use of CGNAT in <a href="https://infosec.space/tags/RFC1918" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RFC1918</span></a> address spaces) as well as <a href="https://infosec.space/tags/DualStackLite" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DualStackLite</span></a>!</p>
Ventor 🐧 <p>Interessante Beobachtung: Der Airbnb Hotspot verwendet irgendeine interessante Technologie um IPv6-Seiten zu erreichen:</p><pre><code>$ curl -v -6 <a href="https://icanhazip.com" rel="nofollow noopener" target="_blank">https://icanhazip.com</a> * Host <a href="http://icanhazip.com:443" rel="nofollow noopener" target="_blank">icanhazip.com:443</a> was resolved. * IPv6: ::ffff:104.16.184.241, ::ffff:104.16.185.241 * IPv4: (none) * Trying [::ffff:104.16.184.241]:443... </code></pre><p>Mein Gerät hat keine eigene IPv6-Adresse, dennoch funktioniert die Verbindung.</p><p>Ist das sowas wie DNS64 und NAT64 nur andersrum?</p><p><a class="hashtag" href="https://social.ventora.net/tag/ipv6" rel="nofollow noopener" target="_blank">#ipv6</a> <a class="hashtag" href="https://social.ventora.net/tag/nat" rel="nofollow noopener" target="_blank">#nat</a></p>
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://mastodon.online/@herrorange" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>herrorange</span></a></span> how?</p><p>Like I really wounder why...</p><p>Is it due to shitty <a href="https://infosec.space/tags/CGNAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CGNAT</span></a> at the <a href="https://infosec.space/tags/ISP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ISP</span></a> end and <a href="https://infosec.space/tags/Skype" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Skype</span></a> doing aggresssive <a href="https://infosec.space/tags/HolePunching" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HolePunching</span></a> through any <a href="https://infosec.space/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> or some other <a href="https://infosec.space/tags/ISP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ISP</span></a>-side shenanigans?</p>
bubbleb74I finally came around to give <a href="https://snac.doosom.com?t=bastillebsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#BastilleBSD</a> a try on a <a href="https://snac.doosom.com?t=freebsd" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> test system but I struggle with the rdr rules. I always get the following error when starting the vnet jail:<br><br>stdin:2: syntax error<br>pfctl: Syntax error in config file: pf rules not loaded<br><br>Here my pf.conf<br><br><pre>lo_if="lo1"<br>ext_if="vmx0"<br>jail_if="vmx0bridge"<br><br><a href="https://snac.doosom.com?t=set" class="mention hashtag" rel="nofollow noopener" target="_blank">#set</a> block-policy return<br>scrub in on $ext_if all fragment reassemble<br>set skip on lo<br>set skip on $jail_if<br><br>table &lt;jails&gt; persist<br>nat on $ext_if from &lt;jails&gt; to any -&gt; ($ext_if:0)<br><a href="https://snac.doosom.com?t=nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#nat</a> on $ext_if from $jail_if:network to any -&gt; ($ext_if)<br><a href="https://snac.doosom.com?t=nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#nat</a> on $jail_if from $jail_if:network to any -&gt; ($jail_if)<br><a href="https://snac.doosom.com?t=nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#nat</a> on $lo_if from $jail_if:network to any -&gt; ($lo_if)<br>rdr-anchor "rdr/*"<br><br><a href="https://snac.doosom.com?t=block" class="mention hashtag" rel="nofollow noopener" target="_blank">#block</a> in all<br>pass out quick keep state<br><a href="https://snac.doosom.com?t=antispoof" class="mention hashtag" rel="nofollow noopener" target="_blank">#antispoof</a> for $ext_if inet<br>pass in inet proto tcp from any to any port ssh flags S/SA keep state<br>pass in on $ext_if inet proto icmp to ($ext_if) icmp-type { unreach, redir, timex, echoreq }<br>pass in on $ext_if inet proto icmp to ($jail_if) icmp-type { unreach, redir, timex, echoreq }<br>pass in on $jail_if inet proto icmp to $jail_if:network icmp-type { unreach, redir, timex, echoreq }<br></pre><br>My BastilleBSD version is 0.13.20250126<br>
C.<p><span class="h-card" translate="no"><a href="https://mindly.social/@wanderinghermit" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>wanderinghermit</span></a></span> </p><p>"Silently die" is commonly caused on Linux by the system OOM killer if the program allocates enough memory to drive the system into an out-of-memory state. Turning off overcommit on the system can be used to confirm this, as it will generally result in the Python program running until a MemoryError exception is thrown, and it will exit with a stacktrace rather than be killed before it can do so. Offhand I don't know what the behaviour on other OSes would be.</p><p>The print-prevents-dying thing I have seen before, but only when running programs on a remote machine. If there is no I/O at all happening, a network connection can end up getting reset for various reasons, causing the exit-to-shell behaviour. Adding print statements that happen to get called often enough to prevent this papers over the problem.</p><p>If this is the problem, and you're running over SSH, there are SSH options to make the session not die like this - keepalives.</p><p><a href="https://mindly.social/tags/SSH" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SSH</span></a> <a href="https://mindly.social/tags/network" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>network</span></a> <a href="https://mindly.social/tags/timeout" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timeout</span></a> <a href="https://mindly.social/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> <a href="https://mindly.social/tags/KeepAlive" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>KeepAlive</span></a> <a href="https://mindly.social/tags/die" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>die</span></a></p>
Leeloo<p>The only place NAT should be allowed is lab/experiment networks, where you might need to duplicate a production IP range.</p><p>"But what about the office network, there is no reason that anyone should ever need to connect directly to an office PC". Once you use NAT there, your IP telephony software needs fragile workarounds just for Sally in marketing to be able to call Alice in legal. And in the next version, those fragile workarounds will be replaced with a cloud service that sells your trade secrets to your competitor.</p><p>"But Skype just works". Skype is a great example of the above, it used to have all kinds of NAT workarounds, now it goes via a server where Microsoft listens in on your calls.</p><p><a href="https://techhub.social/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> <a href="https://techhub.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a></p>
Felix Palmen :freebsd: :c64:<p>Ok I guess I'll have to give up again quite quickly 😦 </p><p><a href="https://mastodon.bsd.cafe/tags/Microsoft" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Microsoft</span></a> <a href="https://mastodon.bsd.cafe/tags/Teams" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Teams</span></a> is broken for me as soon as I disable <a href="https://mastodon.bsd.cafe/tags/IPv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4</span></a>. From what I could understand in this horrible mess of a "web app", the reason is probably some <a href="https://mastodon.bsd.cafe/tags/CORS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CORS</span></a> error. I have no idea how that could ever be related to <a href="https://mastodon.bsd.cafe/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> or <a href="https://mastodon.bsd.cafe/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> or anything. Tried temporarily disabling <a href="https://mastodon.bsd.cafe/tags/NAT64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT64</span></a> (to force direct v6 connections), tried adding all of Microsofts v6 networks to the "exclude" option of bind9 to have everything pass <a href="https://mastodon.bsd.cafe/tags/NAT64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT64</span></a> *avoiding* native IPv6, tried several ways to disable CORS, nothing helped. 🤬 </p><p>Anyone know about these issues with teams?</p><p>edit: to clarify, "everything" seems to work except for the main purpose: join an actual call ...</p>
Felix Palmen :freebsd: :c64:<p>Maybe it *is* about time to go <a href="https://mastodon.bsd.cafe/tags/IPv6only" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6only</span></a>. Currently running my desktop without <a href="https://mastodon.bsd.cafe/tags/IPv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4</span></a> for testing.</p><p>The outside <a href="https://mastodon.bsd.cafe/tags/IPv4" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv4</span></a> world is reachable with <a href="https://mastodon.bsd.cafe/tags/NAT64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT64</span></a> provided by <a href="https://mastodon.bsd.cafe/tags/tayga" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tayga</span></a> running on my <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> router/firewall (with pf for stateful <a href="https://mastodon.bsd.cafe/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> and actual firewalling), great! That's the most important part, I mean, nothing we can do about stubbornly operated v4-only stuff outside.</p><p>Now I identify all the stuff still not offering <a href="https://mastodon.bsd.cafe/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> in my home network. Already fixed parts of my mail system and my irssi-proxy (for IRC). But there's more to check ... none of my VPN tunnels currently transport v6 ... and I'm still a bit unsure about all the devices (e.g. switch and access points in my management segment, or stuff like a vacuum robot or a kitchen radio in my IoT segment ... oh boy 😂🙈)</p>
Larvitz :fedora: :redhat:<p>I don't need NAT/Port-Forwarding on my Home-Network anymore and disabled the last remaining "Port-Forwardings". </p><p>All the servers in my home-network, got publicly routed IPv6 addresses and incoming SSH is permitted on my Firewall/Gateway.</p><p>Since my mobile data-plan features modern networking, with IPv6, I can do any remote-access without any NAT via IPv6 now. </p><p>And in the rare case, I am on a network, that only supports a legacy IP protocol, I've built myself a road-warrior VPN on a Hetzner server, to get myself IPv6 connectivity in those situations.</p><p>IPv6 all the things !! 🙂 </p><p><a href="https://burningboard.net/tags/networking" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>networking</span></a> <a href="https://burningboard.net/tags/ipv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ipv6</span></a> <a href="https://burningboard.net/tags/nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>nat</span></a> <a href="https://burningboard.net/tags/homelab" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>homelab</span></a> <a href="https://burningboard.net/tags/moderninfrastructure" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>moderninfrastructure</span></a></p>
Stuart Longland (VK4MSL)<p><span class="h-card" translate="no"><a href="https://tech.lgbt/@dscw" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>dscw</span></a></span> <span class="h-card" translate="no"><a href="https://ioc.exchange/@mikemathia" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>mikemathia</span></a></span> </p><p><a href="https://mastodon.longlandclan.id.au/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> has <a href="https://mastodon.longlandclan.id.au/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> too 🙂</p>
WeatherMatrix (Jesse Ferrell)<p>Cyclone <a href="https://mastodon.world/tags/Nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Nat</span></a> is in the South Pacific approaching French Polynesia.</p><p>An E'ward track of a tropical cyclone below Tahiti has never happened on record. In fact, Tahiti has never had a landfall. It has had 2 close tracks by 2 Cat 2 storms, BOTH in 1983. <a href="https://mastodon.world/tags/Veena" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Veena</span></a> and Rewa.</p><p>1983 was an El Nino year, as was 1997 when two cyclones passed near French Polynesia. </p><p>The S Pac basin goes as far east as 120W even though few tropical cyclones have ever passed east of 130W (record was Ursula in 1998 @ 124.5W)</p>
Volker Stolz<p>Oooof... that's quite some <a href="https://mastodon.social/tags/nat" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>nat</span></a> here...</p><p>traceroute to ..., 64 hops max, 52 byte packets<br> 1 192.168.1.1 (192.168.1.1) 7.298 ms 1.063 ms 0.999 ms<br> 2 10.0.0.1 (10.0.0.1) 27.262 ms 25.505 ms 24.700 ms<br> 3 172.16.0.1 (172.16.0.1) 28.712 ms 53.205 ms 33.256 ms<br> 4 * * *<br> 5 81.196.118.208 (81.196.118.208) 217.442 ms 25.200 ms</p>
Jody Lemoine 🇨🇦<p>Sometimes I can’t decide whether I’m really an <a href="https://hachyderm.io/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> advocate or just a rabid opponent of <a href="https://hachyderm.io/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a>. Potato/Potahto? <a href="https://hachyderm.io/tags/NetEng" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NetEng</span></a></p>
Lewis Westbury 💛💙🌱<p>Working in <a href="https://mastodon.social/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a>, you may find you need to move your <a href="https://mastodon.social/tags/lambdas" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lambdas</span></a> out of the default <a href="https://mastodon.social/tags/VPC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>VPC</span></a> so they can talk to other services, eg. RDS. Granting <a href="https://mastodon.social/tags/internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>internet</span></a> access to lambdas in the non-default VPC isn't trivial...</p><p>💡 Here's a <a href="https://mastodon.social/tags/CloudFormation" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CloudFormation</span></a> gist with a working solution...</p><p>➡️ <a href="https://gist.github.com/instantiator/fc433a98bb6a58234602d67a69b3cda7" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">gist.github.com/instantiator/f</span><span class="invisible">c433a98bb6a58234602d67a69b3cda7</span></a></p><p><a href="https://mastodon.social/tags/CF" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CF</span></a> <a href="https://mastodon.social/tags/SAM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SAM</span></a> <a href="https://mastodon.social/tags/serverless" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>serverless</span></a> <a href="https://mastodon.social/tags/InternetGateway" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>InternetGateway</span></a> <a href="https://mastodon.social/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> <a href="https://mastodon.social/tags/NATGateway" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NATGateway</span></a></p>
Teri Radichel<p>VPC with a <a href="https://infosec.exchange/tags/NAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT</span></a> and a <a href="https://infosec.exchange/tags/VPC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>VPC</span></a> <a href="https://infosec.exchange/tags/Endpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Endpoint</span></a> Deployed With <a href="https://infosec.exchange/tags/CloudFormation" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CloudFormation</span></a><br>~~<br>ACM.276 Allow a <a href="https://infosec.exchange/tags/Lambda" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Lambda</span></a> function in a private network to access <a href="https://infosec.exchange/tags/GitHub" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>GitHub</span></a> via a NAT and <a href="https://infosec.exchange/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a> <a href="https://infosec.exchange/tags/CodeCommit" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CodeCommit</span></a> via a VPC <a href="https://infosec.exchange/tags/Endpoint" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Endpoint</span></a> <br>~~<br>by Teri Radichel | July 31, 2023<br><a href="https://infosec.exchange/tags/Network" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Network</span></a> <a href="https://infosec.exchange/tags/Cloud" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Cloud</span></a> <a href="https://infosec.exchange/tags/Security" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Security</span></a></p><p><a href="https://medium.com/cloud-security/vpc-and-nat-and-a-vpcendpoint-deployed-with-cloudformation-229870a3d008" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">medium.com/cloud-security/vpc-</span><span class="invisible">and-nat-and-a-vpcendpoint-deployed-with-cloudformation-229870a3d008</span></a></p>
TrendingLive feeds
About