Conversation

Notices

1. Embed this notice
   นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 06:19:06 JST นาตาลี :bellsystem:

   certified hood classic

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 06:19:04 JST lamp

     in reply to

     • かき@GNUsocialJP

     @natalie what is this from

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 06:30:45 JST lamp

     in reply to

     • かき@GNUsocialJP

     @natalie h

   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 06:30:47 JST นาตาลี :bellsystem:

     in reply to

     • lamp

     @lamp@mastodong.lol asterisk administrator's guide

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 07:19:48 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @wizard @natalie i don't get the figurative language but the only problem with nat is the hosts not knowing what their external address is. the rest of it is the same stuff as stateful firewall, which you need anyway.

   • Embed this notice
     wlo (wizard@xyzzy.link)'s status on Wednesday, 19-Oct-2022 07:19:49 JST wlo

     in reply to

     • lamp
     @natalie @lamp the babies are punching back!
   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 07:19:52 JST นาตาลี :bellsystem:

     in reply to

     • lamp
     • wlo

     @wizard@xyzzy.link @lamp@mastodong.lol have to keep fighting right?

   • Embed this notice
     wlo (wizard@xyzzy.link)'s status on Wednesday, 19-Oct-2022 07:19:53 JST wlo

     in reply to

     • lamp
     @natalie @lamp this book makes it sound like you keep giving them out too
   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 07:19:55 JST นาตาลี :bellsystem:

     in reply to

     • lamp

     @lamp@mastodong.lol i just keep taking punches

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 08:13:43 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @natalie @wizard If the VoIP protocol is implemented on UDP or TCP, then the router configuration required will be practically the same, with or without NAT.

     The only real issue is the sender not knowing its src address. But why should it? The receiver will get it in IP, and any proxies could inject it into application layers.

   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 08:13:45 JST นาตาลี :bellsystem:

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @wizard@xyzzy.link voip + nat is kind of a special case, there are a lot more factors at play than usual simple client/server applications
     
     although it's definitely a case of "it didn't need to be this way", we're stuck with it though

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 08:14:03 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @natalie @wizard
     There is nothing wrong with NAT and it poses no hinderance to protocols designed with it in mind. It sounds like Asterisk wasn't, and for whatever reason they chose to blame it on NAT by putting their shitty opinions in their official manual, ironically implying that they themselves are a crybaby.

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 08:40:20 JST lamp

     in reply to

     • かき@GNUsocialJP
     • Kayden ❤️

     @nullobsi it appears the hindrance here is that this voip protocol depends on the sender knowing its real address in order to send it in the application layer. but there's no reason why it has to, as that address will already be included in the IP layer. if it weren't for that then there'd be no conflict with nat.

   • Embed this notice
     Kayden ❤️ (nullobsi@akko.unix.dog)'s status on Wednesday, 19-Oct-2022 08:40:22 JST Kayden ❤️

     in reply to

     • lamp
     • wlo
     @lamp @natalie @wizard "it poses no hindrance to protocols designed with it in mind"
     so it does pose a hindrance?
     you can have a firewall without NAT that works just as well, nat is just an annoyance and a wall when you need to establish P2P connectivity as is very common with VOIP
   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 08:42:40 JST lamp

     in reply to

     • かき@GNUsocialJP
     • Kayden ❤️

     @nullobsi > you can have a firewall without NAT that works just as well, nat is just an annoyance and a wall when you need to establish P2P connectivity as is very common with VOIP

     it's the same... you have to configure the firewall the same way as you'd have to do with nat

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 09:30:56 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @natalie @wizard This is about Asterisk, because NAT is innocent, yet whoever moron they hired to write the manual decided to take a shit on him in official documentation!

     IPv6 has no NAT yet we still use stateful firewalls. Why? Because otherwise all our individual devices will be subject to direct unsolicited attacks or become part of botnets due to misconfiguration or exploitation of whatever holes n shit windows has.

   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 09:31:00 JST นาตาลี :bellsystem:

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @wizard@xyzzy.link why are you so upset about this lol
     it has nothing to do with asterisk, the SIP protocol predates it by years
     do some research into SIP ALG (thank u nat boxes) and what it takes to receive inbound calls without prior registration

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 09:40:25 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @natalie @wizard So it's not "definitely a case of 'it didn't need to be this way'". It would be nice to have simple direct unfiltered access to devices, as this would allow peer-to-peer paradigms to function properly, but this is problematic. So all this complication is for the sake of security, which is necessitated by reality.

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 09:43:20 JST lamp

     in reply to

     • かき@GNUsocialJP
     • wlo

     @natalie @wizard It's relevant because the problems people attribute to NAT aren't NAT's fault.

   • Embed this notice
     นาตาลี :bellsystem: (natalie@nya.social)'s status on Wednesday, 19-Oct-2022 09:43:21 JST นาตาลี :bellsystem:

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @wizard@xyzzy.link i mean the latter paragraph is absolutely true but i don't see how it's relevant here

   • Embed this notice
     lamp@mastodong.lol's status on Wednesday, 19-Oct-2022 13:20:30 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard so some NATs prevent UDP hole punching by restricting the rule by ip address; couldn't a firewall do the same thing? how is this concept specific to NAT?

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Wednesday, 19-Oct-2022 13:20:31 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link it IS partly NAT's fault, or rather, an endpoint-dependent NAT's fault. With full-cone (1:1, endpoint-independent) NATs or stateful firewalls in front of publicly routable addresses, you can traverse them by simply coordinating the two ends to send packets to each other on some pre-determined port. This will not work when a stateful and endpoint-dependent NAT is involved, because there is no way to know which public port an internal port will be mapped to.

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 05:15:42 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard CGNAT isn't implicitly symmetrical NAT (mine isn't)

     But endpoint-independent NAT is just as easy to traverse as firewall? Cause even if PAT is performed, STUN server knows the external port

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 05:15:43 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link The problem is NOT the restriction; that is easily worked around by simple firewall traversal techniques. The problem is that under endpoint-dependent NAT (CGNAT), you cannot predict the mapped port of an endpoint device, rendering all traversal techniques useless. You have to do effectively a port scan in order to traverse this type of NAT.

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 06:14:48 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard >basically doesn't exist in today's IPv4-exhausted world and that isn't what we usually mean by NAT.

     xxxxxxxxxxxxxxxxxxxxxxxxxxxx

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 06:14:49 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link Endpoint-Independent NAT is the same as a firewall, but that basically doesn't exist in today's IPv4-exhausted world and that isn't what we usually mean by NAT.

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 06:44:11 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard What makes you say that? If it "basically doesn't exist", then P2P would be dead. I don't have symmetric NAT and don't know if I ever did. I think most people don't have it.

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 07:47:02 JST lamp

     in reply to

     • 
     • Neko McCatface v2023 :verified::makemeneko:
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @roboneko @PeterCxy @natalie @mint @wizard comcast doesnt do any cgnat as far as i'm aware

   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Thursday, 20-Oct-2022 07:47:03 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • 
     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @PeterCxy @lamp @natalie @mint @PeterCxy @lamp @natalie @wizard that probably explains why I've never had to deal with it. never purchased from comcast :cirno_heh:
   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Thursday, 20-Oct-2022 07:47:04 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @lamp @PeterCxy @natalie @lamp @PeterCxy @natalie @wizard yeah I've never had problems with CGNAT but iiuc there are a significant number of implementations in the wild that will vary the port assigned not only based on local ip+port but also on the remote one. and that does indeed break all the things and I don't understand why it exists but here we are :puniko_shrug:
   • Embed this notice
      (mint@ryona.agency)'s status on Thursday, 20-Oct-2022 07:47:04 JST 

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @roboneko @PeterCxy @lamp @natalie @wizard >I don't understand why it exists
     Jewing customers out of fully working connectibility and making them pay extra for static IPs.
   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 09:23:25 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard port conflicts are just resolved by port rewriting, how does that make it effectively "endpoint-dependant"? just allow from anywhere to the mapped port

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 09:23:26 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link Symmetric (endpoint-independent) My personal experience is that all carrier grade NATs are endpoint-dependent. Because, again, if your NAT needs to handle multiple client, even if you tried to make it endpoint-independent, the process of handling conflicts makes it effectively endpoint-dependent (when multiple clients tries to allocate the same port)

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 11:00:57 JST lamp

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @roboneko @PeterCxy @natalie @wizard i dunno i was thinking a simple nat could just leave the port number as is if it's fine

   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Thursday, 20-Oct-2022 11:00:58 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @PeterCxy @lamp @natalie @PeterCxy @natalie @lamp @wizard
     
     > when multiple clients tries to allocate the same port
     
     but why would you ever let the client select the port themselves? you just assign them one and they have to deal with it
   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 11:13:26 JST lamp

     in reply to

     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @PeterCxy @natalie @wizard it doesn't matter whether it's predictable if it's endpoint-independent. i don't get the implication that port rewriting means symmetric nat

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 11:13:27 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link and of course the way the port is rewritten is very much unpredictable. That is what makes it demonstrate symmetric NAT behavior.

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 11:13:28 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • lamp
     • wlo

     @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link except even nf_masquerade doesn't work this way?

   • Embed this notice
     lamp@mastodong.lol's status on Thursday, 20-Oct-2022 13:41:05 JST lamp

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • かき@GNUsocialJP
     • wlo

     @roboneko @PeterCxy @natalie @wizard yeah, it's not worth sacrificing all p2p functionality for that. IP4s arent THAT expensive; endpoint-independent CGNAT should be enough (just a few customers per IP saves a lot).

   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 13:41:06 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • lamp
     • wlo

     @roboneko@bae.st @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link I should have worded it better -- it's not that ports can conflict, but that people who make these NYAT gateways want to reuse the same port by multiplexing traffic using the (port, dst) pair (because they assume they will eventually have way more hosts in the network than there are ports). When multiple clients inside the NYAT'd network connecting to the same dst (say, another NYAT'd network) get mapped to the same port (like what MASQUERADE would do by default), then the port has to be reassigned, and it is this part that will inevitably be unpredictable. You cannot just send a packet to a TURN/STUN server and assume its observed src address will be the same when you try to communicate with the other client, because the TURN/STUN server may not be affected (no duplicate (port, dst) mapping).

   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Thursday, 20-Oct-2022 13:41:06 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @PeterCxy @lamp @natalie @PeterCxy @natalie @lamp @wizard
     
     ok the cause of the problem makes sense, thanks for explaining that
     
     > want to reuse the same port by multiplexing traffic using the (port, dst) pair (because they assume they will eventually have way more hosts in the network than there are ports
     
     seems like a really dumb premature optimization imo. ~65k (src_ip:src_port) pairs active at any given time per external ip address seems like it should be plenty. if you're routing that much traffic through a single appliance can you really not afford a second public ip? FFS
     
     the bulk of traffic from the typical client is going to originate from only a few ports so in practice at any given time you'd only be allocating a few ports per client on average. budget 10 active ports per client and you can manage over 6k clients per public ip. presumably at some point you're going to run out of bandwidth at the appliance
     
     I guess someone could attempt to DoS you but maybe deal with that when it comes up. I don't see why you'd need multiplexed mappings unless a single client had simultaneous active connections on something like hundreds of ports and even then it seems like you only need it for the one client that's consuming all the resources
   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Thursday, 20-Oct-2022 13:41:07 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • lamp
     • Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ
     • wlo
     @PeterCxy @lamp @natalie @PeterCxy @natalie @lamp @wizard ok I apologize for being a :brainlet: here but I'm not very experienced with network stuff. if you assign a public port (temporarily, on demand) based on the internal ip:port then how can you ever have a conflict? ie if 10.0.0.8:9999 gets assigned to 8.8.8.8:7777 on the public side (for any and all remote endpoints) how can it ever conflict since 7777 has been assigned to only a single internal ip:port pair?
     
     I'm aware that (at least as far as I understand) many CGNAT solutions also vary the port per-destination as well. and tbh I don't understand why you would ever do that unless you were intentionally trying to break stuff but I also realize that there might be some reason I don't know about since it's not as though I design network hardware or write firmware
   • Embed this notice
     Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ (petercxy@comfy.social)'s status on Thursday, 20-Oct-2022 13:41:08 JST Tᴀᴋᴀɴᴀsʜɪ Hᴏʀᴏ

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • lamp
     • wlo

     @roboneko@bae.st @lamp@mastodong.lol @natalie@nya.social @wizard@xyzzy.link well even just a simple MASQUERADE in the Linux netfilter module is technically NOT endpoint-independent. When you have a conflict, it will try to resolve it by randomly re-assigning the ports. It's just that it defaults to endpoint-independent behavior when possible.