# PF submission stuck waiting for nearly 4 years



## chrcol (Feb 25, 2021)

See this here.






						⚙ D11137 PF: implement RFC 4787 REQ 1 and 3 (full cone NAT)
					






					reviews.freebsd.org
				




Any idea how things get stuck like this, and how to get it moving?

This one in particular has potential implications for something very common today, gaming.

more details here https://tools.ietf.org/html/rfc4787


----------



## SirDice (Feb 25, 2021)

chrcol said:


> Any idea how things get stuck like this,


The last post seems to explain it. 



chrcol said:


> and how to get it moving?


You could ask on the freebsd-pf@ mailing list.


----------



## Snurg (Feb 25, 2021)

Hi SirDice  , if I understand correctly, one can use poudriere to automatically integrate ones' own patches into packages, so one could apply patches like this for personal needs.

But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?
This is a very serious issue to me, as in particular cases (right now mostly nvidia related stuff, for example the unfixed resume-breaking bug in vesa.ko I already PRed in 2017, or the modifications necessary for Optimus combos already waiting 4 or 5 years for integration) there is no way around to build a modified base system, just to make things work.

Can a local poudriere repo cover these cases also?


----------



## SirDice (Feb 25, 2021)

Snurg said:


> But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?


It's called git. Branch the source and you can add your own patches.


----------



## chrcol (Feb 25, 2021)

I will post on the mailing list, been a while since I posted there.   I get the person is busy I was hoping there was more than one person who had the ability to commit the code.


----------



## SirDice (Feb 25, 2021)

It may just have fallen through the cracks. "I thought you were going to look at it." "No, I thought you were looking at it". I see these things happening at work too. When you ask 10 persons to do something, nobody does anything as they all think someone else is going to do it.


----------



## Mjölnir (Feb 25, 2021)

Snurg said:


> But, regarding base/kernel stuff, is there a mechanism in place that allows similar, so that patches survive updates?


Of course using git(1) is the most correct solution to this.  But if you don't contribute to base/world, there's a simple alternative: use a _unionfs_ (mount_unionfs(8)) to mount the genuine sources below your working tree.  Excerpt from my fstab(5):

```
/src/12.2-REL   /usr/src                unionfs         rw,late,noatime,below,copymode=transparent  0       0
/src/12.2-REL   /home/paul/Projects/FreeBSD/src/12.2-REL unionfs rw,noauto,noatime,below,copymode=transparent       0       0
/src/12-STABLE  /home/paul/Projects/FreeBSD/src/12-STABLE unionfs rw,noauto,noatime,below,copymode=transparent      0       0
/src/13-STABLE  /home/paul/Projects/FreeBSD/src/13-STABLE unionfs rw,noauto,noatime,below,copymode=transparent 0       0
/src/14-CUR     /home/paul/Projects/FreeBSD/src/14-CUR unionfs rw,noauto,noatime,below,copymode=transparent 0       0
```
I have a directory patches in the root of my working tree, which holds the *.diff patches.  Everything you do in the working tree will survive updates on the underlying source tree.  Before each freebsd-update(8), I remount /usr/src as nullfs(5), so that my local changes & additions are completely shadowed.  Then the sources get their updates on the underlying tree.
EDIT for the sake of completeness: alternatively, you can remove the _src_ component from freebsd-update.conf(5) and use gitup(1) or git(1) to download & update the sources tree(s). /EDIT


SirDice said:


> It may just have fallen through the cracks. "I thought you were going to look at it." "No, I thought you were looking at it". I see these things happening at work too. When you ask 10 persons to do something, nobody does anything as they all think someone else is going to do it.


 Oh yes. Of the few things I found out about human behaviour, one is this: when you ask in a crowd: _"Can someone help me with this, please?"_, noone will help, all looking at each other & wait for the 1st to jump in.  When instead you ask somebody _specifically_, if you don't know his/her name, fixate with your eyes or touch on the arm or shoulder, your chances to get help are _much_ better.


----------



## SirDice (Feb 25, 2021)

Mjölnir said:


> Of the few things I found out about human behaviour, one is this: when you ask in a crowd: _"Can someone help me with this, please?"_, noone will help, all looking at each other & wait for the 1st to jump in. When instead you ask somebody _specifically_, if you don't know his/her name, fixate with your eyes or touch on the arm or shoulder, your chances to get help are _much_ better.








						Bystander effect - Wikipedia
					






					en.wikipedia.org


----------



## Jose (Feb 25, 2021)

> With this patch, a standard pf nat (without any option) allow to create NAT hole: I don't think it's a "security downgrade" problem, because NAT was never desing for security.


Also, from the RFC


> REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.
> ...
> Endpoint-Independent Mapping:
> 
> ...


This means machines behind NAT can expose arbitrary UDP and TCP ports to the Internet permanently. What could go wrong?

I don't want this. I hope it's put behind a feature flag if it's ever adopted.


----------



## SirDice (Feb 25, 2021)

For gaming it usually suffices to run something like net/miniupnpd in combination with PF. Works for other applications like P2P or Skype and others. Most modern applications support UPnP (most home modem/routers have this functionality too).


----------



## Jose (Feb 25, 2021)

I don't mean to be harsh, but I'm not a fan of Upnpd either. It does the same thing. Allows random machines on the inside network to punch arbitrary holes through your firewall.

The only way to do something semi-secure in this setup is to set up a default deny for outgoing and only allow some combinations of host and port for outgoing connections. Even then you'd be subject to browser hijacking attacks, or malware that used well-known ports to do its work. It seems like far more work than just doing the static port mappings for the few games that need them (I'm looking at you Nintendo Switch).

That reminds me, I gotta go turn a bunch of those off now that my kids have moved on to other games.


----------



## zirias@ (Feb 25, 2021)

Jose said:


> This means machines behind NAT can expose arbitrary UDP and TCP ports to the Internet permanently. What could go wrong?


Nothing at all. That is, if you didn't misuse NAT for "security", of course.

OTOH: let's talk IPv6. You wouldn't want to use NAT there, right? And you would (of course) add filtering rules on your firewall box? Why is IPv4 still an issue (e.g. for gaming?) Maybe this patch just got obsolete anyways…


----------



## Jose (Feb 25, 2021)

Zirias said:


> Nothing at all. That is, if you didn't misuse NAT for "security", of course.
> 
> OTOH: let's talk IPv6. You wouldn't want to use NAT there, right? And you would (of course) add filtering rules on your firewall box? Why is IPv4 still an issue (e.g. for gaming?) Maybe this patch just got obsolete anyways…


The absence of NAT is one of the reasons for poor adoption of IPv6. We learned in the '90s that putting every machine on the Internet with a public IP is a really bad idea.

Edit: We relearned this lesson with AWS "classic" networking. Hence why everyone uses VPCs now.


----------



## zirias@ (Feb 25, 2021)

You're getting it the wrong way around. The single worst misconception about NAT was always the idea, that it would help security, cause "hey, you're not reachable", which was NEVER true. It was always just a workaround for a shortage of addresses. There's never an alternative to writing sane packet filtering rules for your specific needs.


----------



## Jose (Feb 25, 2021)

Well this bad misconception has been working pretty well for me and most people for several decades now. I'm going to stick with what works if you don't mind.


----------



## zirias@ (Feb 25, 2021)

The thing is: it doesn't. Well, do your own research.


----------



## Snurg (Feb 25, 2021)

Mjölnir said:


> there's a simple alternative: use a _unionfs_ (mount_unionfs(8)) to mount the genuine sources below your working tree.


Damn good idea! Thank you 
I will research how to do it this way, as I do not believe regular users are willing to set up a github account, just to customize the system.

This would make easy to offer various patches in the postinstaller, so these the user wants can just be sort of "overloaded" over the source tree.

For example in cases the maintainer says "I don't like this bugfix/patch/modification so I ignore it", or says "I don't understand the bug due to lack of technical knowledge" and thus refuses the fix, the user then could easily decide himself.

And when good fixes/patches/modifications are widely used and prove reliable, this kind of voluntary testing could benefit the whole community, too.
It might help weed out bugs/regressions in advance, and also provide positive feedback that can help judge whether a patch is actually mature.
I am now thinking about what could be the best way to report user experience with patches/fixes that have been suggested but are not being integrated for whatever reason.


----------



## Jose (Feb 25, 2021)

Yeah, well I guess I'm dreaming about the past 20 years of no intrusions both in my professional life and in my personal setups. But I'll run out and implement your suggestions right away.


----------



## zirias@ (Feb 25, 2021)

Simple as that: You're wrong. A common by-product of just being lucky.


----------



## Jose (Feb 25, 2021)

No, you're wrong. Stalemate.

Come back when you have some actual vulnerabilities you want to talk about.


----------



## msplsh (Feb 25, 2021)

NAT can be deployed easily.  IPv6 deployments did not account for the security and privacy "features" of NAT and IMO, that's what hobbled its rollout.  Putting the ethernet MAC in the interface identifier?  I mean, thanks a lot for THAT idea.

"write a firewall ruleset" is not what you tell consumers.


----------



## zirias@ (Feb 25, 2021)

So, you tell them "use snakeoil" instead? Sure.


----------



## msplsh (Feb 25, 2021)

I'm not sure what you're talking about with snake oil.  NAT has by default, clear security and privacy benefits that connecting machines directly to the internet via IPv6 with no firewall does not confer.  There is not a phrase or term for an IPv6 firewall ruleset or translation mechanism that will give the same benefits.


----------



## zirias@ (Feb 25, 2021)

msplsh said:


> NAT has by default, clear security and privacy benefits


LOL. Seriously. Do a 2-minutes research, Google is enough.


----------



## msplsh (Feb 25, 2021)

I find it interesting you have no capability to explain your position on "lol NAT security."

For my part, as to what the "benefits" are, I'll simply assert that NAT prevents arbitrary enumeration of the computers behind the NAT and in general, access to open ports on those machines.


----------



## zirias@ (Feb 25, 2021)

So, you didn't do any research. I won't play LMGTFY here, thanks.


----------



## msplsh (Feb 25, 2021)

Oh I looked, just to make sure I wasn't the crazy one.  You're the one asserting without evidence that NAT provides no (or little, not clear) security benefits and won't acknowledge which ones it does.


----------



## PMc (Feb 25, 2021)

Jose said:


> The absence of NAT is one of the reasons for poor adoption of IPv6. We learned in the '90s that putting every machine on the Internet with a public IP is a really bad idea.


From what I understood, NAT would not be needed at all with IPv6. 

I never considered NAT a security feature - if I had had the abundance of static addresses to make my fridge and lawnmower reachable planetscope, I would have done so right from the beginning.
But now, over many years I implicitly trained the perception that my intranet is entirely independent from anything else, and public connectivitiy is just a very limited add-on.
Indeed I do consider moving to IPv6, but I still fail to develop some proper vision on how I could tackle this and how I might make it look in the end: I am currently using three independent NAT and five openvpn to wire my stuff together, and I have nice code to drop NATs and forwards into IPFW at arbitrary places and then auto-create the proper rules. Looks like lots of effort to move all this to IPv6. Security then adds the additional handicap that this has to be done in a precise and thorough fashion.


----------



## zirias@ (Feb 25, 2021)

Yep. You're not the crazy one. Excuse me, I was under the impression of talking with professionals here.


----------



## Jose (Feb 25, 2021)

So you have nothing substantive to say. Just LOLs and Google homework for others.


----------



## zirias@ (Feb 25, 2021)

I'm not your teacher. If you can't find anything with two simple keywords on Google, you might be in the wrong profession.


----------



## Jose (Feb 25, 2021)

And I'm not your student. You don't get to give me homework. I'm also not taking career advice from you, thank you.


----------



## zirias@ (Feb 25, 2021)

Bottom line: I couldn't care less. You're wrong about NAT, that's just a fact, and I really don't care at all if you see it or not.


----------



## Jose (Feb 25, 2021)

PMc said:


> From what I understood, NAT would not be needed at all with IPv6.


That was the perception in the late '90s and indeed how IPv6 was designed. Then more and more Windows machines started to get on the Internet with hilarious results.

The '90s way is making something of a comeback with the defense in depth stuff, but that's not practical yet if you don't have a dedicated team of security professionals working on it.

Edit: In Windows' defense, it wasn't designed to be connected to a worldwide internetwork. Even LAN support was kinda grafted on after the fact. What happened is not at all surprising in retrospect.


----------



## zirias@ (Feb 25, 2021)

Cool, more nonsense. Connection tracking works for IPv6 as well, if you want to rely on THAT. No need for NAT. You can still block anything "incoming", but allow responses. With all the same loopholes. NAT just isn't a factor there.


----------



## msplsh (Feb 25, 2021)

First it's "I won't explain myself" and now it's "of course what you said is true, but you don't need NAT for that" which is what I was saying in the first place?

The things you "don't need NAT for" but that NAT provides are not wrapped up in such a way that it's a bullet point on a box for consumer deployment for IPv6.  That's the whole point.


----------



## PMc (Feb 25, 2021)

Jose said:


> That was the perception in the late '90s and indeed how IPv6 was designed. Then more and more Windows machines started to get on the Internet with hilarious results.
> 
> The '90s way is making something of a comeback with the defense in depth stuff, but that's not practical yet if you don't have a dedicated team of security professionals working on it.
> 
> Edit: In Windows' defense, it wasn't designed to be connected to a worldwide internetwork. Even LAN support was kinda grafted on after the fact. What happened is not at all surprising in retrospect.


I agree. But then, isn't it a systemically bad approach to boggle the lower level designs (interconnectivity) due to security weaknesses of some upper level instances (windows systems)?


----------



## Mjölnir (Feb 25, 2021)

Zirias said:


> LOL. Seriously. Do a 2-minutes research, Google is enough.


With all respect, that's bad style of arguing.  If it's so obvious & easy, you could come up with just a few cues, which would be enough to correct any misconception that an informed reader might have.  I know you're not elitarian, but some of your statements could give other readers the impression that you are.


----------



## msplsh (Feb 25, 2021)

PMc said:


> I agree. But then, isn't it a systemically bad approach to boggle the lower level designs (interconnectivity) due to security weaknesses of some upper level instances (windows systems)?


"No plan survives first contact with the enemy"

By the measure of connectivity, firewalls are a "design flaw."  If we didn't have NAT, had freeflowing IPv6 addressing, and Windows continually made networking decisions assuming it was on a friendly, firewalled network, some kind of firewall standard would have appeared and we'd use those boxes instead of "routers."  Instead, due to more computers than IP assignments, the necessity of NAT papered over most of the problems.


----------



## Jose (Feb 25, 2021)

PMc said:


> I agree. But then, isn't it a systemically bad approach to boggle the lower level designs (interconnectivity) due to security weaknesses of some upper level instances (windows systems)?


I agree in principle, but in practice bugs happen. For example, I run Nextcloud on my internal network, but I don't trust it enough (yet) to expose it to the Internet. It's possible that an attacker could set up a tunnel into my internal network using Upnp or "full cone NAT" and thereby expose my Nextcloud to the Internet.
Another example is net/netatalk3. It was been abandoned upstream for Samba, and I can't adopt Samba for reasons that are off-topic. I'm migrating away from Apple and will eventually not need Netatalk for Timemachine, but that's going to take some time. I don't want to expose Netatalk to the Internet, and you shouldn't want to either.
My network is still too old-school in that it has a hard and crunchy outside and a soft and gooey inside. I need to break up the internal network into three. One for wireless devices were guests' random phones will be allowed, one for devices like Playstations and smart tvs, and one for the wired back-end services networks. I've got all the hardware. I just gotta motivate.


----------



## Snurg (Feb 25, 2021)

Jose said:


> It's possible that an attacker could set up a tunnel into my internal network using Upnp or "full cone NAT" and thereby expose my Nextcloud to the Internet.


And think of all that IoT stuff.
I think most people want things "work" as "normal", and more security-aware people for example, who don't see a benefit in the IoT stuff chatter over public internet, can just block Upnp and all that.


----------



## Jose (Feb 25, 2021)

Snurg said:


> And think of all that IoT stuff.


I try to avoid that stuff as much as possible, but I have a family and they like the shiny. But I do need to isolate all that stuff in its own network.


			CVE - CVE-2018-11315


----------



## zirias@ (Feb 25, 2021)

Mjölnir said:


> I know you're not elitarian, but some of your statements could give other readers the impression that you are.


Elitism would be, for example, to put someone down for asking "stupid questions". Insisting on something while literally ONE quick request on Google will show tons of resources explaining how this is wrong is a whole other story, and I politely refuse to play this silly game.


----------



## msplsh (Feb 25, 2021)

Nobody knows what you're talking about anymore.  You'll type all these words in about how smart you are, but not the "two simple keywords" we're supposed to be searching for to understand your cryptic "ha ha, if you only could use google" taunts.

I'm sorry we can't have a discussion over the sound of how smart you are?


----------



## zirias@ (Feb 25, 2021)

Uh, a classic, if YOU don't understand something, it's magically everyone. Only serves for self-assurance of course. But for that great secret what to search for, maybe try "NAT security". Surprise.


----------



## Mjölnir (Feb 25, 2021)

Zirias said:


> Elitism would be, for example, to put someone down for asking "stupid questions". Insisting on something while literally ONE quick request on Google will show tons of resources explaining how this is wrong is a whole other story, and I politely refuse to play this silly game.


It would take you about the same time to just type in a few keywords/cues than you need to type in this answer about _"this silly game"_.  BTW I'd like to note that I consider to prefer _DuckDuckGo_ instead of _Giggle_ should be natural on a FreeBSD forum; not only IIRC it runs on FreeBSD, it's also driven by FreeBSD freaks?  Back on topic,  I'm currently reading NAT Router Security Solutions, that was among the 1st in the list _ddg_ gave me.


----------



## zirias@ (Feb 25, 2021)

Hm, it's on GRC. This is known for decades as a prime source of internet "security" myths. Famous for its "stealth firewall" nonsense. Random rant about this "expert site": https://www.wilderssecurity.com/thr...-stealth-firewall-test-or-harmful-fud.216892/


----------



## Mjölnir (Feb 25, 2021)

Zirias said:


> Hm, it's on GRC. This is known for decades as a prime source of internet "security" myths. Famous for its "stealth firewall" nonsense. Random rant about this "expert site": https://www.wilderssecurity.com/thr...-stealth-firewall-test-or-harmful-fud.216892/


Thx.  Then would you be so kind & generous & point me to a more reliable source of information?


----------



## msplsh (Feb 25, 2021)

Yeah, uh, what?  "NAT Security" gives us what you're claiming is... nonsense?  Wouldn't this be the opposite of what you're trying to get us to understand?


----------



## zirias@ (Feb 25, 2021)

Just for example:

General (boring) stuff: https://weberblog.net/why-nat-has-nothing-to-do-with-security/
Example for a concrete "attack" on a NAT implementation: https://0day.work/an-example-why-nat-is-not-security/

The latter is btw not really related to NAT but to the idea of "connection tracking" filters. The fact that the router also translates addresses has very little impact. Part of the misconception probably is that you *need* connection tracking to make NAT work at all for clients behind it.

edit: and for some more theory, there's also conflicting goals. The purpose of NAT is to provide connectivity close to what would be possible without it, so, the more packets it *CAN* route, the better. For UDP, a sane approach is e.g. the patch mentioned here, or in general a strategy with a FIXED mapping that will ONLY change when the router learns a new one triggered by some other host "inside".

This is more or less the opposite of what a firewall should do.


----------



## zirias@ (Feb 25, 2021)

msplsh said:


> Yeah, uh, what?  "NAT Security" gives us what you're claiming is... nonsense?  Wouldn't this be the opposite of what you're trying to get us to understand?


I now better assume you're making this up ... right?


----------



## Mjölnir (Feb 25, 2021)

Zirias said:


> I now better assume you're making this up ... right?


But it's pure & plain, simple aristhotelian logic applied:  We do what you requested, and it points us to a source that in contrast you call unreliable & misleading...  Well, your last posts were more substantial & hopefully we can continue that way.  This topic is too important & does not deserve a discussion spiked with personal taunts. If you feel there is one against you, please just ignore it & keep on with relevant infos & hints.  Thx in advance, sincerely yours, Mjölnir


----------



## zirias@ (Feb 25, 2021)

Well, yep, maybe I assumed too much, thinking everyone knew about the reputation of Gibson in this field  Still Google (and sorry, it's the only search engine I use cause I'm quite satisfied with the quality of the results) also delivers more than enough better resources...


----------



## SirDice (Feb 25, 2021)

For crying out loud, I look away for two seconds and there's two pages worth of bickering about who's right or wrong. Take that elsewhere please.


----------



## zirias@ (Feb 25, 2021)

SirDice said:


> For crying out loud, I look away for two seconds and there's two pages worth of bickering about who's right or wrong. Take that elsewhere please.


Well, complaints like issued in this thread come from this idea of NAT as something "helping security", which it isn't and never has been and I think it's REALLY important to understand this misconception. The patch here aims to *improve* NAT, and given the declared goal of NAT, which is *enabling* connections, it does exactly that.

Snarky responses don't help. And sure, I had my share, sorry for that.


----------



## PMc (Feb 25, 2021)

Zirias said:


> Uh, a classic, if YOU don't understand something, it's magically everyone. Only serves for self-assurance of course. But for that great secret what to search for, maybe try "NAT security". Surprise.


Honestly, I don't understand the whole quarrel either.



Zirias said:


> thinking everyone knew about the reputation of Gibson in this field


Seriosly, no.


----------



## msplsh (Feb 25, 2021)

Ok, finally, something concrete.

The first link is mostly semantics and basically arguing that an opponent could get this information elsewhere.  They _could_, but just scanning the network is way easier and NAT makes it harder.  A firewall _could_ also make it harder.  So, why not make it harder?

This goes back to my earlier point: IPv6 rollouts did not have a bullet point sort of feature of "Use this to get the obfuscation features you got with NAT."  You're not going to get the same sort of features, though, by putting everything directly on the network and then firewalling them and the tradeoffs were not compelling to people.  You can watch computers blink on and off the network if they're connected directly and correlate them to people and devices.  Sure, you could block ICMP and other ping-ish techniques, but now you're "breaking things" like NAT (I don't know if you care about this distinction or not).  Is there a name for a comprehensive "prevent people from telling if this IP is online" firewall rule?  That's the kind of bullet point sort of thing people need to know to make decisions.  I got this "feature" from NAT, what do I have to do to get it from this new setup?  Arguments like "you don't need this feature" aren't particularly compelling to people if they don't have to do something.

Yes, NAT isn't "a firewall" but it has a lot of properties of one.  People understand those properties and want them.  "Hurr durr you should use a firewall with REAL rules" is not helpful.  What are these "real" rules and do the people even want them?  That's the only reason I chimed in here.

My personal issue with IPv6 vs NAT was the MAC addresses and how by default, you were going to have to know if your network firewall was going to keep your MAC LAN-local or configure a firewall on the computer (before OSes got wise and started randomizing them).  I can't imagine telling people that they should configure a firewall before using a computer so people won't deduce their computer vendor and track them across the internet.  IPv4 NAT provided this "feature" by default and it is/was very fiddily to get the same feature out of a firewalled-direct-connect IPv6 setup.

The second link has the appropriate caveat "certain situations."  You need to know which server the client is connected to, spoof the IP, and luck into the client currently listening.  Unless I'm mistaken, I don't think any firewall configuration is going to prevent this problem any better than NAT.


----------



## zirias@ (Feb 25, 2021)

So, this is mixing up a lot of aspects and also repeating the NAT misconception. Let's just address the main points:

* "Privacy" by hiding your IP address? Doesn't make any sense. Still, plain SLAAC is just ONE method to assign IPv6 addresses. Of course, it's the most simple one that will work in any setup.
* NAT does not prevent something, but enable something. To make NAT work at all, you need connection tracking, which also works without NAT. It isn't bullet-proof (yep, that's the whole point) and I bet any consumer router offering IPv6 will still do exactly that by default (while blocking inbound traffic that wasn't tracked before).


----------



## msplsh (Feb 25, 2021)

I didn't use the word privacy, so I don't know what you are talking about.

"Connection-tracking, incoming block-by-default firewall" is kind of a mouthful to have people look for, but I guess at least it would mean something.


----------



## zirias@ (Feb 25, 2021)

So, we're there again where I should have stopped writing to this thread in the first place. Will do so now. It just doesn't make any sense :/


----------



## mickey (Feb 26, 2021)

The question is not so much whether or not NAT was designed to provide security, although asymmetric NAT surely does improve security. The question is whether games or other applications that employ techniques to punch holes into your firewall can be considered well behaved networking applications at all. I for one surely wont tolerate such behaviour from any network application. Many games in the past used fixed (or even configurable) ports for communications, so you could just set up a port forwarding on your router and be done with it. Nowadays game developers seem to be under the impression that setting up a port forwarding is way beyond the skillset of their target audience, so they resort to using crappy p2p networking implementations like steamworks and the like, with no user configurability whatsoever, that uses ephemeral ports on both sides, thereby creating a firewall admin's nightmare (as in: it just doesn't work if you do not open up ALL ports).


----------



## Mjölnir (Feb 26, 2021)

Just my 2¢: msplash, you've been choosing your words kinda awkward, to say it politely... While IMHO Zirias was arguing sensibly, you didn't.  I do have some basic knowledge in networking, but still I have to & want to learn more; now one who presumably knows more than me is gone.  Thx a lot.


----------



## zirias@ (Feb 26, 2021)

Well, I will reply on that one:


mickey said:


> The question is not so much whether or not NAT was designed to provide security, although asymmetric NAT surely does improve security.


That's the thinking I consider kind of dangerous, cause this "security" is a byproduct of the shortcomings of NAT, and improving NAT will then decrease this kind of "security". The objective of NAT is to allow as many packets as possible to find their target.


mickey said:


> The question is whether games or other applications that employ techniques to punch holes into your firewall can be considered well behaved networking applications at all. I for one surely wont tolerate such behaviour from any network application. Many games in the past used fixed (or even configurable) ports for communications, so you could just set up a port forwarding on your router and be done with it. Nowadays game developers seem to be under the impression that setting up a port forwarding is way beyond the skillset of their target audience, so they resort to using crappy p2p networking implementations like steamworks and the like, with no user configurability whatsoever, that uses ephemeral ports on both sides, thereby creating a firewall admin's nightmare (as in: it just doesn't work if you do not open up ALL ports).


That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.

So, what's really annoying is this idea not to be able to configure the port used by a game, and games (and other software) trying to "punch holes" automatically, by just "tricking" any connection tracking. If you rely on connection tracking for your IPv6 firewall ruleset, you will have the exact same problem with software behaving that way.

I think the complaint should be towards software behaving that way, cause yes, this software will stop working with a restrictive ruleset in place on your firewall box, whether you use NAT or not. It shouldn't be an argument against improving NAT in a way so it can automatically route more packages correctly. Please just decouple filtering from NAT.

*tl;dr:* Yes, NAT *implies* some filtering by nature, but this will differ depending on the NAT implementation, you can never be sure about it, you shouldn't rely on it: it's a bug, not a feature. Use actual filtering for filtering.


----------



## mickey (Feb 26, 2021)

Zirias said:


> That however is a rant I can relate with, but I'd argue it's not really tied to NAT. As a firewall administrator, you maybe want to open up a specific port on a specific machine for UDP to allow a specific game to communicate. Whether you have to "forward" this port or not won't change anything in principle. A better NAT might remember a mapping automatically, so you don't have to explicitly forward something, but you still have to allow this communication. Thinking IPv6: You won't have/need NAT, but you'd probably still block any incoming packets by default and you still want to allow packets to a specific UPD port on a specific machine for exactly THAT game.
> 
> So, what's really annoying is this idea not to be able to configure the port used by a game, and games (and other software) trying to "punch holes" automatically, by just "tricking" any connection tracking. [...].
> 
> I think the complaint should be towards software behaving that way, cause yes, this software will stop working with a restrictive ruleset in place on your firewall box, whether you use NAT or not. It shouldn't be an argument against improving NAT in a way so it can automatically route more packages correctly. Please just decouple filtering from NAT.


Games or other network applications behaving this way are bad by design. Steamworks for example uses libjingle to find a workable connection from a set of candidates, this employs STUN which simply cannot work with a symmetric NAT, it also leaks private IP addresses and there is nothing whatsoever that could be configured by a user. In the end, the only connection that has a chance to succeed if you are behind a symmetric NAT is via a relay server, whch might introduce additional latency and that is exactly the opposite of what you'd want for the purpose of gaming.


----------



## zirias@ (Feb 26, 2021)

Definitely a braindead thing. Although I understand the motivation to offer some "automatic" behavior when operated by someone with no knowledge at all, behind your typical consumer router. If there is no alternative way to just tell this thing "listen on port XX", it's broken crap.

All I'm saying is, this isn't really related to NAT, it will give you headaches configuring your firewall without NAT as well.


----------



## Mjölnir (Feb 26, 2021)

There was this successor to STUN, I forgot it's name?  I had that when configuring XMPP.  I'm dialing in on WWAN (like a stupidphone).  With my current ISP that's IPv4 only & they do NAT me on 10.x.y.z...
Bah   PS: thx 4 join(1)ing again.


----------



## mickey (Feb 26, 2021)

Zirias said:


> Definitely a braindead thing. Although I understand the motivation to offer some "automatic" behavior when operated by someone with no knowledge at all, behind your typical consumer router. If there is no alternative way to just tell this thing "listen on port XX", it's broken crap.
> 
> All I'm saying is, this isn't really related to NAT, it will give you headaches configuring your firewall without NAT as well.


I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use symmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.


----------



## zirias@ (Feb 26, 2021)

mickey said:


> I might be mistaken here as I don't use that kind of crap, but my guess is that even consumer grade routers these days more and more use asymmetric NAT. There is nothing wrong with automatic approaches in general, as long as developers give the user at least the option to make it work, when these mechanisms fail.


They use it for IPv4 as there is just no other option. They nowadays support IPv6, of course without NAT. And ISPs offer more and more "ds-lite" where you get IPv4 only through a tunnel (over v6) with a private address that is *again* NAT'ed at the ISP.

My point was: The problem is not NAT, you'll have the same problems without it, if it means you have to allow all incoming traffic to a host, just so a stupid game there is able to do direct connections (which are necessary for gaming performance). I totally agree: any of these "automagic" strategies should be optional.

*edit:* CGNAT (carrier-grade NAT) might also be a somewhat interesting topic here, because you'd probably never want your ISP to do filtering for you, right? So, for CGNAT, it's even more crucial to route as many packets as possible to limit the impact. I'd bet any ISP offering IPv4 through CGNAT would implement the RFC linked in the OP


----------



## Mjölnir (Feb 26, 2021)

On that privacy topic to hide a machine from ICMP:  even this _me_ with healthy sciolism can write a rule for my "personal FreeBSD firewall" (standard `firewall_type=workstation`) that answers ICMP of my ISP (to debug a problem should they need to), and deny all others.  That's really simple.  Of course, now that they NAT me, that makes no sense, but when they give me IPv6, I could do that easily.


----------



## zirias@ (Feb 26, 2021)

Thanks, I think that "privacy" argument against IPv6 has always been a red herring. The "privacy" NAT "offers" is the same kind of unintended by-product as the implied filtering. Not sure what good blocking ICMP(v6) would do, but sure you can do that. If you want to "hide" your internal hosts, RFC4941 has a canonical solution (using random host-parts that change regularly).


----------



## Mjölnir (Feb 26, 2021)

RFC4941: bookmarked.


----------



## eternal_noob (Feb 26, 2021)

Mjölnir said:


> RFC4941


The only RFC you need to know is RFC 1149 / RFC 2549


----------



## Kristof Provost (Feb 26, 2021)

To take this thread back on-topic: I have no plans to spend time on this patch.
It's a large change in a very complex section of the pf code, and the use case and utility of it are not clear to me.

Realistically that means it's not going to get picked up. There's essentially no one else working on pf right now.

If you really need this change there are a couple of things you can do: improve the argument for the change (i.e. demonstrate a need, a use case not covered without it) and add tests for it. Tests are very helpful in persuading me that the change is safe and won't break anything else. Also, continued engagement from the author of the patch would also be helpful, because it demonstrates that when there's fallout from it I'm not going to be the only one trying to figure that out.


----------



## zirias@ (Feb 26, 2021)

This statement is very understandable. I'm not the author of the patch nor do I need what it provides, but I assume the "need" is just to improve NAT, and I guess beneficiaries would be exactly these applications that expect incoming UDP packages and use a random port for their communication, so of course you could argue they're "broken by design"… The key is that you send out a packet from port a, mapped to port b on the NAT host to remote host X, then a packet sent from remote host Y to port b on your NAT box WILL be forwarded to port a of your internal box. Of course, if you could just configure your application to use a fixed port, you could just configure a fixed mapping on your NAT box instead (which would help sane filtering rules a lot). Still, what it does is to improve functionality of NAT.

Totally understand the request for thorough automated testing though, to avoid breakage. Whoever needs this functionality should probably contact the author of the patch asking for that.


----------



## Mjölnir (Feb 26, 2021)

One can argue that the patches "score" relates to that RFC4787's acceptance & employment.  I.e. if it's not widely employed, forget the patch.  But if it's not a _"niche-product"_, we could try to figure out reliable tests.


----------



## Jose (Feb 26, 2021)

mickey said:


> Steamworks for example uses libjingle to find a workable connection from a set of candidates, this employs STUN which simply cannot work with an asymmetric NAT...


Coincidentally, I was just reading about STUN, and am curious about its flaws. My understanding was that it will try to connect the two peers directly, and will only fall back to a proxied connection if this fails. Are you saying all connections where one end is behind asymmetric NAT will always fall back to proxied?









						Stun-turn
					

With Twilio, unite communications and strengthen customer relationships across your business – from marketing and sales to customer service and operations.




					www.twilio.com
				




Maybe the "symmetric NAT" on that page is a thinko, and they really meant to write "asymmetric NAT?"
(I don't consider that page authoritative because they're trying to sell me something.)


----------



## Jose (Feb 26, 2021)

Mjölnir said:


> RFC4941: bookmarked.


It's no panacea
"The temporary addresses standardized in RFC 4941 were originally meant to mitigate some of the security and privacy issues discussed in this tip. However, we will see that they fail to mitigate a number of potential problems, while at the same time introducing additional complexity."








						Understanding security flaws in IPv6 addressing schemes | TechTarget
					

Learn why underlying characteristics of IPv6 addressing schemes may enable nodes to be identified across networks via IPv6 address-scanning attacks.




					searchsecurity.techtarget.com


----------



## zirias@ (Feb 26, 2021)

IMHO, the idea that somehow "hiding" IP addresses was something desirable was always flawed, but you can sure discuss that in depth. It's not really on-topic here, while the purpose of NAT definitely is in the light of a patch attempting to improve NAT.

Considering NAT "for security" has always been ill-advised, and THAT is a fact: You never knew what exactly a specific NAT implementation was doing, but you knew (or: COULD know) the purpose, which is routing as many packets as possible, therefore allowing operation as close to the scenario without NAT as possible.

Side note, I really had a giggle about that GRC page, basically saying "NAT gives security, but maybe not enough, so use moar NAT for moar security"  sorry, just too hilarious.


----------



## Snurg (Feb 26, 2021)

Mjölnir said:


> But if it's not a _"niche-product"_, we could try to figure out reliable tests.


I have no idea about how much sense it makes to fully implement some RFC's.
But as a layman I generally it is reasonable to assume that non-deprecated IETF specifications are probably somewhat well-thought.

And in this case, if I understand correctly, there would be quite some use cases, if there were a way to easily enable this one RFC _on the users' own risk_, it could turn out to be useful for people who need a router that supports all this hole-punching for lan parties, kids network with all the newest Upnp fads, internet cafes etc, and be it as inofficial community patch of expressedly unknown quality and security.

This would at least create the possibility for interested people to get actively involved, without too much hassle.


----------



## zirias@ (Feb 26, 2021)

Well, thinking about usefulnes, I now tend to consider NAT a "thing from the past" anyways. But as long as there are some die-hard IPv4-only networks, it will still have its use…

As long as NAT is widely used, I think this patch makes sense, as it indeed improves the (intended!) functionality of NAT. Of course, you should still be able to do firewalling based on "connection tracking" (and therefore forbid connections originating from somewhere else to the same socket), but you should also be aware that this is no silver bullet, and it is only tied to NAT because NAT will never work without any kind of connection tracking.


----------



## mickey (Feb 26, 2021)

Jose said:


> Coincidentally, I was just reading about STUN, and am curious about its flaws. My understanding was that it will try to connect the two peers directly, and will only fall back to a proxied connection if this fails. Are you saying all connections where one end is behind asymmetric NAT will always fall back to proxied?
> 
> 
> 
> ...


That was actually my bad, what I meant is of course 'symmetric NAT'. It has been a while since I last had to pull my hair out over messing with different NAT types and I always found the established terms to be highly misleading, as there is nothing symmetric in symmetric NAT and no cone in any cone type NAT, at least not in my imagination (or lack thereof) of things.

The reason why STUN cannot help if you are behind a symmetric NAT is that this type of NAT will create a separate NAT mapping for each set of local IP:local port/remote IP:remote port. So when host A which is behind a symmetric NAT asks STUN server B on the internet about what IP address/port B sees from A, this information is useless as it cannot be used by host C on the internet to connect to A.

If both ends are behind a symmetric NAT then the only option is the use of a relay/proxy server. In case only one side is behind a symmetric NAT there might still be a chance for direct communications, but that will likely depend upon how intelligently the automated mechanisms handling this stuff have been implemented.


----------



## Jose (Feb 26, 2021)

I agree the terms make no sense. I hate bad metaphors. They make things confusing unnecessarily.


----------



## msplsh (Feb 26, 2021)

Glad we can all finally agree that the problem is the non-specificity of the terms being used...



Mjölnir said:


> Just my 2¢: msplash, you've been choosing your words kinda awkward, to say it politely... While IMHO Zirias was arguing sensibly, you didn't.  I do have some basic knowledge in networking, but still I have to & want to learn more; now one who presumably knows more than me is gone.  Thx a lot.


Honestly don't know how you came to that conclusion.  I have intentionally tried to be precise with the words I use.  Note sure how that comes off as awkward.


----------



## PMc (Feb 26, 2021)

AFAIK the considered functionality (UDP STUN and whatever) is not only used for certain games, but also for VoIP network.
And, while I do not care much about ill-devised games, VoIP routing should be considered an important usecase for a Unix server.


----------



## Jose (Feb 26, 2021)

And for Webrtc too, which powers most of the video and audio chats you can use nowadays.


----------



## Mjölnir (Feb 26, 2021)

I find it extremely hard to extrapolate an expected EOL of IPv4.  10 years? 20? 50?  Maybe it will stay alive in leaf networks for the next two centuries?  Just can't tell.


----------



## Mjölnir (Feb 27, 2021)

Kristof Provost wants tests, there are none.  Do we take that job?  Are we qualified?  I'm not, unless you help me.
Kristof Provost states that he didn't have the time _"to examine the implications in sufficient detail."_  FMLU, this could be things like: the patch accidently disables vital codepaths, variables don't get initialized that were w/o the patch, ... what else?
The author claims to have corrected some of the style(9) issues, but there are still many.  These are minor issues that even a trained _codemonkey_ can fix easily?
There's a `goto` in the patch.  Usually that should trigger extra attention?
The patch is several years old, thus it's not clear if it will run-through on current 14-CURRENT sources.
I consider _"to demonstrate a use case for the patch"_ as lower priority, because simply throwing in the terms VoIP, SIP, WebRTC triggers enough attention?
TWIMC I started trying to understand that RFC4787, and interestingly, it states at the very beginning:

```
The requirements of this specification apply to Traditional NATs as
   described in [RFC2663].

   This document is meant to cover NATs of any size, from small
   residential NATs to large Enterprise NATs.  However, it should be
   understood that Enterprise NATs normally provide much more than just
   NAT capabilities; for example, they typically provide firewall
   functionalities.  A comprehensive description of firewall behaviors
   and associated requirements is specifically out-of-scope for this
   specification.  However, this specification does cover basic firewall
   aspects present in NATs (see Section 5).

   Approaches using directly signaled control of middle boxes are out of
   scope.

   UDP Relays (e.g., Traversal Using Relay NAT [TURN]) are out of scope.
```
TURN was the term I was searching for above.  STUN's companion.
So msplash was not that wrong about firewalling functionalities of NATs.

Back on topic:

Without reading the patch, it should be possible to derive assertions from the relevant sections 1. & 3. of that RFC4787, maybe in some cases from other RFCs it references.  We could write these down using the same notation from the RFC.  These could be just a few in the three groups: on session start, while a session is active, when the session is dropped.  Correct?
After beeing proof-read twice, these can be translated to be woven into the code as KASSERT(9)s, right?
Maybe some more code-specific tests/assertions  can or should also be added then, like "there must/cannot be an entry in that hashtable for this", "this is an unique entry", ...
Maybe we should start with this topic?: IMHO we should also try to formulate assertions about the traditional behaviour of the pf-NAT, because these would greatly help to asure that
our understanding how the traditional NAT works conforms to the actual implementation
our tests for the patch comply to that, indicating they are the right tests & assertions
the patch does not break the non-patched parts of the code.
This would also help to increase Kristof Provost's trust in the patch.

I'm having trouble to accept the term _session_ in conjunction with UDP, but that should hopefully go away soon.   IIRC, when writing tests/assertions, the part that I underlined above is important: not to glimpse into the code (if it is preexistent), but write them down in a more abstract way 1st.


----------



## Jose (Feb 27, 2021)

I use Webrtc just fine even with my insecure, evil "symmetric" NAT. This feature is not necessary. I reiterate my preference that there be a way to turn this off if the patch is accepted. I guess it won't really affect me if it is because I use Openbsd for my firewall. I seriously doubt this patch would gain any traction in that project.


----------



## mickey (Feb 27, 2021)

So why exactly does someone need a patch to do something that should be easily achieved just by adding _static-port_ to the nat rule? And why should such behaviour then be forced upon just about everyone else, by making it the default behaviour? I think this is all backwards, seriously.


----------



## zirias@ (Feb 27, 2021)

mickey said:


> So why exactly does someone need a patch to do something that should be easily achieved just by adding _static-port_ to the nat rule? And why should such behaviour then be forced upon just about everyone else, by making it the default behaviour? I think this is all backwards, seriously.


It *should* only affect NAT, not any rules using connection tracking (aka "keep state"). So, if done right, you can filter in the exact same way as before, if you like. It should only change the behavior if all you have is a NAT rule.

Of course, with a simple configuration like from the handbook

```
block in all
pass out all keep state
```
you *expect* your firewall to block anything incoming except for direct answers to what's outgoing. If the patch would change this, it would be broken, no matter whether you use NAT or not.

But it's reasonable to expect something like

```
nat on tun0 from $internal_net to any -> (tun0)
```
to do a "best effort" approach of routing (by rewriting) as many packets as possible. Just add simple filter rules (like above) to make this more restrictive.


----------



## zirias@ (Feb 27, 2021)

Mjölnir said:


> There's a `goto` in the patch. Usually that should trigger extra attention?


Just had a look at the "goto"s introduced by the patch. They're fine, following your typical "goto cleanup"/"goto failed" idiom. A lot of C code needs this kind of goto for a clean and readable structure, possible alternatives are much worse.


----------



## mickey (Feb 27, 2021)

Zirias said:


> It *should* only affect NAT, not any rules using connection tracking (aka "keep state"). So, if done right, you can filter in the exact same way as before, if you like. It should only change the behavior if all you have is a NAT rule.


I don't think it's that simple. My understanding is that the filtering rules are evaluated only if there is no matching state entry. And from what pf.conf(5) tells, such states are created automatically from translation aka NAT rules:

```
TRANSLATION
     Translation rules modify either the source or destination address of the
     packets associated with a stateful connection.  A stateful connection is
     automatically created to track packets matching such a rule as long as
     they are not blocked by the filtering section of pf.conf.
```
The interesting question is what does that mean with regard to RFC4787 section 5 - Filtering behaviour? In particular the passage that states:


> Having the filtering behavior being an option configurable by the administrator of the NAT ensures that a NAT can be used in the widest variety of deployment scenarios.


So how would one go about - in the context of a pf.conf(5) file - actually configuring the required filtering behaviour of the NAT? As I sure as hell want an _Address and Port-dependent Filtering_ for all intents and purposes.


----------



## Mjölnir (Feb 27, 2021)

Zirias said:


> It *should* only affect NAT, not any rules using connection tracking (aka "keep state"). So, if done right, you can filter in the exact same way as before, if you like. It should only change the behavior if all you have is a NAT rule.


Jose & mickey, does this answer satisfy your objections?  For sure I'm not in the mood to spend any thoughts & work into s/th that's not worth it.

Assuming it's worth going on: so this assertion would result in an external test, i.e. that goes into the CI devel/kyua framework? E.g. create (clone) the necessary network interfaces, and use _netcat_ (nc(1)) or such to test/verify/asure that packets pass (block, resp.) on a reasonable simple pf.conf(5)? (& clean up after the test)  Right?  I don't see this could/should be tested/asserted internally in the code.  Correct?  Are there more appropriate tools to use other than _netcat_?  Preferably in _base_?


Zirias said:


> Of course, with a simple configuration like from the handbook
> 
> ```
> block in all
> ...


Dito.  External tests?


Zirias said:


> Just had a look at the "goto"s introduced by the patch. They're fine, following your typical "goto cleanup"/"goto failed" idiom. A lot of C code needs this kind of goto for a clean and readable structure, possible alternatives are much worse.


Yes, I know.  Nevertheless, I'll try harder to understand & verify that it's ok to leave out the skipped code.


mickey said:


> I don't think it's that simple. My understanding is that the filtering rules are evaluated only if there is no matching state entry. And from what pf.conf(5) tells, such states are created automatically from translation aka NAT rules:
> 
> ```
> TRANSLATION
> ...


IIUC the manpage pf.conf(5) is unambiguous here: _"A stateful connection is automatically created [...] as long as [the packets] are not blocked by the filtering section of pf.conf."_  I.e., the _blocking_ filtering rules overrule NAT's packet translation.  Again, we could/should create an external test (or set of tests) to ensure this? EDIT Yes, and additionally this could go into an code-internal assertion. My understanding is that the filters are applied 1st, then the NAT rules, then maybe additional filter rules? Are there such?  In ipfw(4), the rules are numbered.  How is the ordering handled in pf(4)?  Or does the admin have to use netgraph(4) to apply stacking of rules?/EDIT

Do you agree we should start with tests & assertions on the existing NAT?  For sure we'll run into greenhorn traps; this would help to correct these, and we'll have an initial set of tests that will asure that the patch does not break the existing code.  We can flag the tests that we think should be changed or disabled for the patch.


----------



## Kristof Provost (Feb 27, 2021)

Mjölnir said:


> Kristof Provost wants tests, there are none.  Do we take that job?  Are we qualified?  I'm not, unless you help me.


There are ... I won't say extensive, but there are already a fair number of tests for pf: https://cgit.freebsd.org/src/tree/tests/sys/netpfil/pf



Mjölnir said:


> Kristof Provost states that he didn't have the time _"to examine the implications in sufficient detail."_  FMLU, this could be things like: the patch accidently disables vital codepaths, variables don't get initialized that were w/o the patch, ... what else?


Just about everything. The patch could potentially introduce bugs, out-of-bounds memory accesses, vectors for denial of service (e.g. memory leaks), ...



Mjölnir said:


> The author claims to have corrected some of the style(9) issues, but there are still many.  These are minor issues that even a trained _codemonkey_ can fix easily?


Those are by far the least significant part of the work. Don't bother until and unless everything else is sorted.



Mjölnir said:


> There's a `goto` in the patch.  Usually that should trigger extra attention?


Sometimes, but goto is a very common error handling pattern in kernel C, and likely used that way here. That's usually fine.



Mjölnir said:


> The patch is several years old, thus it's not clear if it will run-through on current 14-CURRENT sources.


That's probably the second easiest bit of the task. I don't think the NAT code evolved a great deal, and this is likely just a mechanical resolving of merge conflicts. It needs to be done, but it's likely trivial.



Mjölnir said:


> I consider _"to demonstrate a use case for the patch"_ as lower priority, because simply throwing in the terms VoIP, SIP, WebRTC triggers enough attention?


Strong disagree here. The first thing to accomplish with any patch is to convince people that what it tries to do makes things better. Once that's established we can argue about how to get there.
Throwing around terms doesn't accomplish that at all, unless you mean to claim that VoIP/SIP/WebRTC currently don't work (they do...).


----------



## Mjölnir (Feb 27, 2021)

Kristof Provost said:


> There are [tests] ... I won't say extensive, but there are already a fair number of tests for pf: https://cgit.freebsd.org/src/tree/tests/sys/netpfil/pf


Thx for the hint.  Didn't have a look into these; I meant code-internal KASSERT(9)s & CTASSERT(9)s.  There are a few, but IIRC no new ones.  IIUC a KASSERT(9) would crash the whole kernel intentionally; isn't it possible to just crash the kmod instead?


Kristof Provost said:


> Just about everything. The patch could potentially introduce bugs, out-of-bounds memory accesses, vectors for denial of service (e.g. memory leaks), ...


Oh, to insert bounds checking & other assertions in C code is one of my most beloved hobbies.


Kristof Provost said:


> Strong disagree here. The first thing to accomplish with any patch is to convince people that what it tries to do makes things better. Once that's established we can argue about how to get there.


And rightly so.  100% agreed.


Kristof Provost said:


> Throwing around terms doesn't accomplish that at all, unless you mean to claim that VoIP/SIP/WebRTC currently don't work (they do...).


Yes, of course, right.  My assertion that the current implementation might be suboptimal, might be wrong.

OK, I'll try harder to understand that the assertion that the RFC4787 fixes a problem, is justified.  If there is no problem -> that RFC4787 is bogus (at least does not apply to FreeBSD's pf-NAT implementation), and the patch "fixes" a non-existent issue.  Maybe it's that with _endpoint-independent mapping_ NAT, some usually complex setups are much easier?  Damn, that RFC4787 claims: _"Network Address Translators (NATs) are well known to cause very significant problems with applications that carry IP addresses in the payload (see [RFC3027]). Applications that suffer from this problem include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and H.323 [ITU.H323]), as well as online gaming."_.


----------



## Kristof Provost (Feb 27, 2021)

Mjölnir said:


> Thx for the hint.  Didn't have a look into these; I meant code-internal KASSERT(9)s & CTASSERT(9)s.  There are a few, but IIRC no new ones.  IIUC a KASSERT(9) would crash the whole kernel intentionally; isn't it possible to just crash the kmod instead?


No. Any assertion will stop the kernel. Also bear in mind that assertions are only executed on kernels with INVARIANTS set. They're not checked on production builds.


----------



## Jose (Feb 27, 2021)

Mjölnir said:


> Jose & mickey, does this answer satisfy your objections?


No. NATed connections means pretty much every connection in a SOHO setup. This change will essentially affect the global behavior of pf(4) for those setups.

I've been trying to think of ways to exploit static source port NAT*, and one thing that occurred to me is that you could create a peer-to-peer botnet using a rogue STUN server. That botnet would be resilient to losing the STUN server which presumably would also be the control server. You could have peers become the control server at random or through some distributed algorithm. You would wind up with a distributed and resilient botnet which is frankly terrifying.

* I coined this term. "Asymmetric" and "full-cone" don't make any sense to me.


----------



## zirias@ (Feb 27, 2021)

Kristof Provost said:


> Strong disagree here. The first thing to accomplish with any patch is to convince people that what it tries to do makes things better. Once that's established we can argue about how to get there.
> Throwing around terms doesn't accomplish that at all, unless you mean to claim that VoIP/SIP/WebRTC currently don't work (they do...).





Mjölnir said:


> […] Damn, that RFC4787 claims: _"Network Address Translators (NATs) are well known to cause very significant problems with applications that carry IP addresses in the payload (see [RFC3027]). Applications that suffer from this problem include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and H.323 [ITU.H323]), as well as online gaming."_.


No generic solution will be able to solve the problem with IP addresses in payload. Specific "protocol helpers" were an idea, but are useless as soon as encryption is used. The only way to solve THIS is to be able to configure the "external address" in the application (which I had to do e.g. for SIP over IPv4-NAT).

Still, NAT can be improved, so you don't need to configure "port forwarding" for everything incoming. That's why I assume ISPs doing CGNAT will definitely want that improvement (but probably use different solutions, not pf on FreeBSD). It helps NAT the way NAT was meant: Best effort to handle multiple machines when you only have one public address for them.

Indeed, if the patch changes pf more globally (so, "keep state" for filtering with tracking of connections is affected), this is a problem. It shouldn't work this way, because it's definitely not what you expect when trying to filter traffic (actual firewalling).


----------



## zirias@ (Feb 27, 2021)

mickey said:


> I don't think it's that simple. My understanding is that the filtering rules are evaluated only if there is no matching state entry. And from what pf.conf(5) tells, such states are created automatically from translation aka NAT rules:
> 
> ```
> TRANSLATION
> ...


This is kind of hard to interpret. It makes sense to not evaluate any rules if a packet matches an existing state entry, otherwise "keep state" couldn't work with blocking everything incoming.

The question is: Look at the scenario that a packet arrives from a so far unknown remote host on a port that HAS a mapping. Does the patch do the sane thing here, rewrite this packet, but still evaluate the rules (cause with the unknown remote host, it doesn't really match a state entry)? If yes, it would still be blocked if you have e.g. a "block all" rule, but would be routed and rewritten correctly if no filter rule blocks it.

Sure, this is one thing you must review when reviewing the patch. It should NOT introduce a hole in the stateful filtering mechanisms, and I'd say if it does, it is broken.


----------



## Mjölnir (Feb 27, 2021)

What is CGNAT?


----------



## Snurg (Feb 27, 2021)

google carrier grade nat


----------



## zirias@ (Feb 27, 2021)

Mjölnir said:


> What is CGNAT?


Carrier-grade NAT (IOW NAT done on a router at the ISP), e.g. used with ds-lite. It's getting more and more common as ISPs don't have enough IPv4 addresses any more to assign one to each and every connecting customer.


----------



## mickey (Feb 28, 2021)

Mjölnir said:


> I consider _"to demonstrate a use case for the patch"_ as lower priority, because simply throwing in the terms VoIP, SIP, WebRTC triggers enough attention?


Actually no. SIP is what is used for VoIP and the fact that it has problems with NAT is because it was never designed to work through NAT in the first place. SIP exchanges IP address information within the protocol and that is obviously a problem if this IP address is from a private IP address block. That does not implicate that there is anything wrong with NAT that needs to be fixed, also solutions to this particular problem (SBCs, B2BUAs, ALGs, SIP/RTP proxies) have been available in a wide variety for quite some time now.

As for WebRTC and other stuff that employs techniques like STUN/TURN/ICE etc, I consider any such techniques that leverage aspects of certain kinds of NAT implementations to make things work that were never intented to work this way in the first place as broken by design. Reading terms like 'UDP hole punching' alone certainly rings my alarm bell. State created by an outbound connection should never be abused to create something like a server/listening socket.



Mjölnir said:


> IIUC the manpage pf.conf(5) is unambiguous here: _"A stateful connection is automatically created [...] as long as [the packets] are not blocked by the filtering section of pf.conf."_ I.e., the _blocking_ filtering rules overrule NAT's packet translation. Again, we could/should create an external test (or set of tests) to ensure this? EDIT Yes, and additionally this could go into an code-internal assertion. My understanding is that the filters are applied 1st, then the NAT rules, then maybe additional filter rules? Are there such? In ipfw(4), the rules are numbered. How is the ordering handled in pf(4)? Or does the admin have to use netgraph(4) to apply stacking of rules?


Actually it's the other way around as stated in pf.conf(5):

```
Since translation occurs before filtering the filter engine will see
     packets as they look after any addresses and ports have been translated.
     Filter rules will therefore have to filter based on the translated
     address and port number.  Packets that match a translation rule are only
     automatically passed if the pass modifier is given, otherwise they are
     still subject to block and pass rules.
```



Zirias said:


> The question is: Look at the scenario that a packet arrives from a so far unknown remote host on a port that HAS a mapping. Does the patch do the sane thing here, rewrite this packet, but still evaluate the rules (cause with the unknown remote host, it doesn't really match a state entry)? If yes, it would still be blocked if you have e.g. a "block all" rule, but would be routed and rewritten correctly if no filter rule blocks it.
> 
> Sure, this is one thing you must review when reviewing the patch. It should NOT introduce a hole in the stateful filtering mechanisms, and I'd say if it does, it is broken.


Talking about the behavioural characteristics of the so called 'full cone NAT' you will probably find the same information in many places on the internet including here, and the key aspect that just doesn't fly with me is:


> Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.


This is what RFC4787 terms as an _enpoint independent filtering_. While this will certainly help applications that rely on broken-by-design techniques such as STUN/TURN/ICE to function, from a security standpoint such behaviour is just not tolerable.

As I see it, there are two parts to this. The actual translation and the filtering which can be further subdivided into state matching and filter rule evalution, but then again these two parts seem to be tightly coupled. I believe the only solution is to make each and every aspect of NAT user configurable, so that everyone who badly needs to make applications work and understands the security implications that come with it may decide to do so, letting everyone else use whatever they deem appropriate for their particular use case. But that's just what I am not seeing here, how this could be sufficiently configured by means of a pf.conf(5), and forcing full cone NAT down everyone's throat surely isn't going to work for me and probably some other people out there.


----------



## zirias@ (Feb 28, 2021)

mickey said:


> This is what RFC4787 terms as an _enpoint independent filtering_. While this will certainly help applications that rely on broken-by-design techniques such as STUN/TURN/ICE to function, from a security standpoint such behaviour is just not tolerable.


The whole problem with this discussion is that filtering is an unwanted necessity for NAT, but intended behavior for firewalling. If these aspects aren't clearly separated then yes, you might open up unwanted security holes.

What I would expect (after a patch improving NAT as suggested here) with a pf.conf only containing

```
nat on $ext_if from $internal_net to any -> ($ext_if)
```
would be a best effort to also route incoming packets that don't match a "tracked" connection yet, while I'd expect the old behavior as soon as I add e.g.

```
block in on $ext_if
pass out on $ext_if
```

But given the amount of discussion and the explanations of work to do to make SURE this patch is safe and secure, it might not be worthwile. As explained earlier, you'd definitely want that functionality for CGNAT, but it's very unlikely ISPs would ever use pf on FreeBSD for that.


----------



## Jose (Feb 28, 2021)

mickey said:


> This is what RFC4787 terms as an _enpoint independent filtering_. While this will certainly help applications that rely on broken-by-design techniques such as STUN/TURN/ICE to function, from a security standpoint such behaviour is just not tolerable.


Stateful filtering is trivially defeated when you have a coordinator like a STUN server in the middle. Since UDP is not really stateful, all the endpoints have to do is start sending packets to each other to establish a "state". Sure there'll be a little packet loss at the beginning, but it's easy to deal with that.

Once you've established a peer-to-peer botnet, any node can act as a STUN server for newly-infected machines. And your firewall will be blissfully unaware because it will be keeping state for connections that look legit because they appear to have initiated locally.

This is no side-effect. This is the way this NAT traversal strategy is designed.

Edit: Nodes can't really be a STUN server for new infections, there has to be some external vector for infecting new machines. Any node can be the coordinator machine that sends marching orders to the botnet, though. One of the main strategies for taking down a botnet is to take down its coordinator, so botnets go to great pains to hide the IP addresses of the control servers. Imagine a botnet where any node can be the coordinator.

Also, having the infection vector move around is no big hurdle. It's something that's commonly done already using banner ads, for example.


----------



## Snurg (Mar 1, 2021)

Thank you all for discussing this in depth.
This seems to be a good example where it is probably the better alternative not to blindly follow the standard.
The risk-gain ratio seems not to be very good, especially when there exists ported software to add this functionality, if it is actually needed.

Also considering the necessary test efforts to make sure that nothing gets unintentionally leakier than the RFC proposes.
I guess this won't be trivial, and requires some sizable test setup.

Maybe it could be a good idea to add a comment to the PR, linking to this thread for detailed reasoning about this patch not being added, so this discussion doesn't unnecessarily repeat.


----------



## zirias@ (Mar 1, 2021)

Snurg said:


> This seems to be a good example where it is probably the better alternative not to blindly follow the standard.


This is IMHO still the wrong conclusion, but it depends on your definition of "better". The standard in question aims to improve NAT (and *only* NAT). This is of course desirable. When there is a risk attached, it's for implementation reasons (when the same code is used for stateful filtering in general).

So, the conclusion would not be that it's "better" to not follow this standard, but it might be that it's not worth the effort, given you have to make sure stateful filtering used for firewalling purposes isn't affected. This could be a conscious decision, also taking into account that usefulness of NAT in general is decreasing with more and more IPv6 used. I'd also say this could always change if there is someone who desperately wants this and is willing to supply all the test cases necessary and so on.

Therefore, a comment on the review might be useful, it should just list what is necessary and what are the possible risks of doing it "wrong". For the simplest test case I could think of, see my post above – of course this wouldn't be enough, but could be a starting point. Yes, I doubt anyone will have a need for this strong enough to go all the way.


----------



## Mjölnir (Mar 1, 2021)

Snurg said:


> Maybe it could be a good idea to add a comment to the PR, linking to this thread for detailed reasoning about this patch not being added, so this discussion doesn't unnecessarily repeat.


Done.  1st activity of my Phabricator account.  Let's see what else I can do.  If only I could manage to waste less time hanging aroung here in the forum... Please stop posting interesting topics that distract my attention!


----------



## Snurg (Mar 1, 2021)

*Apologies again for OT posting. Please skip tl;dr*


Mjölnir said:


> Done.  1st activity of my Phabricator account.


First my impression was: why is that RFC not integrated, even though it would be beneficial for VoIP and much more.
Then the discussion spun. Learning what this unsolicited patch does, what implications it has on the unsuspecting user who doesn't know deep technical detail, which damage potential it has, and the difficulty to test that thoroughly.
Learning the core team's viewpoint from Kristof Provost's insightful comments, I can see that it has good justifcation imho, and personally I believe this patch does not have a real chance to be integrated.

The worst thing that can happen/be done is to push off willing potential contributors by frustrating them.
I have been through that experience, and my personal conclusion is that some grassroots means to integrate patches that fix bugs or add functionality are needed, which are practically usable for people whose daywork is not system programming/building.

Then you described the approach of using unionfs to achieve this.
Having a framework making this easy (a few scripts to set up, build/install and the like) would be essential for this.
With such a thing it would be far easier for "normal mortals" to voluntarily participate in field testing of patches and giving potentially useful feedback in, for example, phabricator.


As you correctly found out, I am a smurf, and I am quite sure I am not the only smurf on this forums. Smurfs are very individualist, usually highly intelligent and quite anarchic, hate being commanded like in a strongly organized and regulated bureaucracy, and usually have high respect for the unique skills and capabilities of every other smurf.

What I am dreaming of is finding successful ways how to make smurf cooperation productive. Because of your Kommunity thread I know you have similar thoughts. A project like ohmyzsh is a good example, 1800+ smurfs contributed to it. They seem to do it in a smurf-compatible way, and this is also the way I want to go with the postinstaller I am working on. Long ago an individual made the first step with ohmyzsh, and it became a successful big cooperation. For this reason I am collecting every contribution (e.g. all that helped, information, advice, suggestions, code) together with link as proof, so everybody can see it is not an one-man-show, but intended as a cooperative effort open for all smurfs who want to contribute. I can only say, without the help of these (currently ~20) contributors, the result won't be nearly as good. For this reason alone I feel I can no longer say "my postinstaller", as it actually grew from the input of every contributor, and the credits list grows longer and longer.

I think the suggestion you made in post #7 is extremely helpful for enabling more smurfs to join in working on FreeBSD. Not only for kernel/core stuff, but in particular useful also for assisting in improving the KDE port. What you described is what many people would love to have, but lack time and motivation to individually figure out how to set up and operate. Such a framework could be a basic foundation for successful Kommunity cooperation, helping improve FreeBSD without putting additional strain on the core team.

Please don't be offended... I believe you are a smurf, too 
I'd be glad if you could write up a how-to, maybe also explaining its use in a concrete use case, like showing how to work on the KDE taskbar code, make changes, build them, and produce patch files to share.
As you correctly stated, it is not appropriate to demand other smurfs implement what one wants and is too lazy or lacks time/know-how to start himself, so I feel unable to request you to write such a howto.  But what I definitely can say is that I guess that quite some people would tremendously appreciate such a guide...


----------



## zirias@ (Mar 1, 2021)

Snurg said:


> Learning what this unsolicited patch does, what implications it has on the unsuspecting user who doesn't know deep technical detail, which damage potential it has, and the difficulty to test that thoroughly.


Just to make this as clear as possible: This patch "done right"*) wouldn't have ANY implications on "unsuspecting users" except for those that ONLY have a "nat" rule and somehow expect that to do "firewalling". You won't find such a configuration anywhere, even the handbook adds the most basic firewalling rules in its examples, so someone having ONLY nat in his config should probably know what he does.

The difficulty here is "only" to make SURE this patch won't affect anything other than plain NAT.

---
*) I didn't read the whole patch and even if I did, I wouldn't be able to judge, knowing nothing about the current pf codebase. It's perfectly *possible* the patch is already "done right", and we just can't know as long as nobody did a deep review. Just mentioned for fairness towards the original author.


----------



## ZorbaTHut (Aug 13, 2021)

Kristof Provost said:


> Strong disagree here. The first thing to accomplish with any patch is to convince people that what it tries to do makes things better. Once that's established we can argue about how to get there.
> Throwing around terms doesn't accomplish that at all, unless you mean to claim that VoIP/SIP/WebRTC currently don't work (they do...).


I'm gonna butt in here real fast to try making a convincing argument for this.

The proposed feature (full cone NAT and its siblings) are used extensively in the game industry for high-performance peer-to-peer links. I can go into more details but I assume you don't need the technical details. One game that makes use of this is Fantasy Strike, which I acknowledge is not a high-profile game, it's just the one I ran into recently so it's the one at the forefront of my mind.

Without _some_ way of punching through the firewall, Fantasy Strike just refuses to connect you to friends. There isn't a fallback, there isn't a low-performance option, you get an error message that's somewhat confusing. Hooked up to my generic cable modem it works just fine; hooked up to my generic cable modem _behind OPNSense_ it doesn't work at all; hooked up to my generic cable modem behind IPFire, it works seamlessly.

I'll acknowledge that a possible fix for this is to manually add a firewall rule, and Fantasy Strike does support a static IP firewall hole to play, and I could have done that. But this is a bad fix for a few reasons.

* It requires that the user have significant technical knowledge when what they maybe really want is to just play the game.
* It requires that the user have the ability to manually change the firewall; what happens if, say, my kids want to play Fantasy Strike? What happens if I'm in a group home and the sysadmin isn't around?
* It has to be manually changed to point at a different computer whenever someone else wants to play.
* It is _absolutely incapable_ of supporting two computers at once behind a single IP, regardless of how much firewall tweaking you do, because manual port assignment can only assign one computer per port, and Fantasy Strike has no option to choose a port manually. (I suspect there's at least a few games that do, but it's vanishingly rare in my experience.)

It is reasonable to say "well, that's just one game, how common is that". It is - in my experience - unfortunately common. Many games use this technique. But that's not even the biggest problem, because game *consoles* often use this technique, sometimes with a single port _per console type_.

So, I admit I haven't tested this due to not having the hardware, but I suspect that without firewall support for some kind of full-cone-NAT, you can't have two Nintendo Switches in the same household, playing p2p games online simultaneously, possibly even if they're different games. Not "without manual intervention"; you just can't do it, full stop. (And heaven help you if they want to play *with each other* - yes, in theory they could just connect directly, but in practice they're likely going to use full-cone-NAT with hairpinning to negotiate a connection through the modem itself, which I acknowledge is silly but is still common and still requires firewall support.)

Whereas it works just fine on my cheap budget cable modem, and it works just fine with a Linux-based firewall, both with zero manual configuration required.

Now, this is, as far as I know, *mostly* an issue with games, and yes, games should be able to just do UPnP requests to set up holes, and many of them don't, and that's kind of the fault of games. I don't know where you fall on the "games are a relevant target audience" spectrum and I don't know where you fall on the "they could fix it on their own, not our responsibility to support weird hacks" spectrum (and this is definitely a weird hack.)

But that's the feature missing, and that's why I spent a few hours trying to figure out the state of this functionality on BSD


----------



## zirias@ (Aug 13, 2021)

ZorbaTHut said:


> Now, this is, as far as I know, *mostly* an issue with games, and yes, games should be able to just do UPnP requests to set up holes, and many of them don't, and that's kind of the fault of games.


IMHO, the actual "fault" is NAT 

These games just mostly behave as if there wasn't any NAT, with the least intrusive little modification in sending out a packet first on a socket before expecting other packets to be received from there. I think that's pretty sane, compared to things like UPnP.

I still don't like this picture of "poking holes". Unfortunately, a lot of "firewalls" mix up NAT with filtering, but that's IMHO the wrong approach. NAT can be modified to work correctly with applications behaving as described above. An administrator could still forbid this communication using filtering rules.


----------



## GeraldH (Oct 21, 2021)

The current NAT behavior of Freebsd (and therefor pfsense and opnsense) is really a pain in the ass for SIP (also for other things). What is commonly recommended for SIP clients behind pfsense/opnsense is the "static port" option, but this can only be used for one client behind nat. Once you've got more than one per public IP you're screwed.

The current "Address and Port Dependent Mapping" vs. "Endpoint Independent Mapping" which most other systems do really does not increase security in any meaningful way, but it creates problems when two systems who are both behind NAT want to communicate without a central relay server in between. I guess "big relay" doesn't want freebsd to have a "normal" NAT implementation that allows machines to talk to each other like it was always intended by the IP protocol?

In the end, this will become obsolete with IPv6 anyway, but why not make v4 work as it's intended to do? The current behavior really serves no purpose and at very least a normal less restrictive NAT behavior should at the very least be an option!  By the way - there is an AMAZING introduction to NAT and its problems regarding port/machine dependent/independent mapping available here: https://tailscale.com/blog/how-nat-traversal-works/ - it's a long article but really worth the time to read and understand.


----------



## Jose (Oct 21, 2021)

Shorter Geraldh "put every machine in the Internet with a public IP like it's 1988, and all our problems will be solved!" Problem is, we tried that in the '90s. It sucked.








						Code Red (computer worm) - Wikipedia
					






					en.wikipedia.org
				








						Nimda - Wikipedia
					






					en.wikipedia.org


----------



## zirias@ (Oct 22, 2021)

Oh, so you're starting that "security argument" again, right? Then again, NAT *never was* a security measure. Public addresses for communication on the internet is how IP was designed from the very beginning.

The first "bad idea" in the 90s was developing networking software without security in mind. Actually, that bad idea is much older. It was a long and painful learning process.

The second "bad idea" back then was assuming privately operated (Windows) boxes wouldn't need any kind of firewall on the internet.

The answers to both bad ideas should be pretty obvious.

NAT is an answer to a _very_ different problem, namely the shortage in the IPv4 address space. NAT tries to do its job imposing as little restrictions as possible on communication, while a Firewall is meant to _impose_ these restrictions. Not improving NAT because people rely on restrictions it introduces as a side-effect is just bollocks. All these restrictions can be imposed explicitly and voluntarily by appropriate firewall rules if they are needed.

NAT in itself is a bad idea, a horrible hack, an unfortunate necessity.

Of course, you're invited to look for services on nexus.home.palmen-it.de (my desktop box). Spoiler: you won't find any, and that's not because `sockstat -l6n` would be empty on that box, it's because my firewall rejects any TCP/UDP connection attempt from the internet to any box in the LAN. There's no reason at all why some consumer plastic router couldn't do the same for IPv6 while delegating a public prefix to your LAN.


----------



## Jose (Oct 22, 2021)

Zirias said:


> Of course, you're invited to look for services on nexus.home.palmen-it.de (my desktop box). Spoiler: you won't find any, and that's not because `sockstat -l6n` would be empty on that box, it's because my firewall rejects any TCP/UDP connection attempt from the internet to any box in the LAN.


One box on the Internet can be secured, therefore all boxes on the Internet can be secured. I can't decide if this is a hasty generalization or a garden-variety non sequitur.


----------



## zirias@ (Oct 22, 2021)

So, seriously? Just because a simple thing any consumer plastic could do (and, probably does) makes less sense to you than relying on the side-effect of something that was never meant to secure anything?


----------

