@tobrop
Then I have to ask what kind of a router do you have?
I get that message also: NAT Type measurement: restricted → restricted
I do absolutely nothing special. Have you tried this.
but then it kicks in automatically with connections
Here is a sample from the logs after a startup.
2024/10/06 22:58:13 Probetest: Created Offer
2024/10/06 22:58:13 Probetest: Set local description
2024/10/06 22:58:13 Probetest offer:
stuff here
2024/10/06 22:58:38 NAT Type measurement: restricted → restricted
2024/10/06 23:05:10 Received Offer From Broker:
2024/10/06 23:05:10 Generating answer…
2024/10/06 23:05:31 Timed out waiting for client to open data channel.
2024/10/06 23:07:02 Received Offer From Broker:
2024/10/06 23:07:02 Generating answer…
2024/10/06 23:07:22 Timed out waiting for client to open data channel.
2024/10/06 23:24:42 Received Offer From Broker:
2024/10/06 23:24:42 Generating answer…
2024/10/06 23:24:44 New Data Channel snowflake-510f685401de1573-824633800310
2024/10/06 23:24:44 Connection successful
2024/10/06 23:24:44 Data Channel snowflake-510f685401de1573-824633800310 open
and it then keeps on going with connections
@excurso
I do none of that and it works completely automatic.
I have a normal home router. As I mentioned above the WebRTC/ICE does all that rule stuff by itself. With all its negotiations it convinces the router that the traffic from the client is related/established. It’s the first rule in the iptables INPUT filter and FORWARD filter.
With the state related,established the incoming packet must go to the process which initiated it.
I do not use the machine. It is on 24/7 doing community computing for four health and medical science non-profit NGOs. I have not taken into account anything rogue. The machine is in my basement and no one touches it.
Correction: it is the second rule in ufw-before-input and ufw-before-input is the first rule in the INPUT filter. Ignore the FORWARD filter comment.