Do library have ability to set NAT 1 to 1 ips?

[Razzwan]

I am running the application inside a docker container, so the network visible inside the container has a local ip address. When I send an offer to the client, the candidate should contain the server's public ip address (not local one). How can I correctly specify the server's ip address in the sent offer using the str0m library?

My assumption is to modify the answer before sending it. I don't understand if I can do this using the Sdp method or if I need to edit the string.

        let candidate =
            Candidate::host(LOCAL_DOCKER_IP_ADDRESS_WITH_PORT_HERE, "udp").expect("a host candidate");
        rtc.add_local_candidate(candidate).unwrap();

        let mut str0m_answer = rtc
            .sdp_api()
            .accept_offer(str0m_offer)
            .expect("str0m_offer to be accepted");
        tracing::warn!("str0m answer - {:#?}", str0m_answer);

        // Can I somehow to exchange ip address here to real public IP address?
        // str0m_answer.set_nat_1to1_ips(PUBLIC_IP_ADDRESS); // I would like to make it works

If library doesn't have this feature, what do you think if I'll implement it?

[k0nserv]

Hey.

As long as the docker's network is set up correctly all you have to do is change the local candidate to the servers public IP address instead of the the local docker IP.

        let candidate =
            Candidate::host(public_addr, "udp").expect("a host candidate");
        rtc.add_local_candidate(candidate).unwrap();

[Razzwan]

Hey! Thank you for the answer!

So, my socket and candidate will has different IP addresses such way?

        let socket =
            UdpSocket::bind(format!("{local_address}:50000")).expect("binding a random UDP port");

        let candidate =
            Candidate::host(public_addr, "udp").expect("a host candidate");

[k0nserv]

It depends on how the networking for Docker is configured. If you just want it to work without restricting to a specific interface bind to 0.0.0.0:50000 or [::]:50000 for IPv6.

[Razzwan]

This is my part of docker config:

    networks:
      - main // this is just default internal Docker network (not binded to public IP address)
    ports:
      - "50000-50200:50000-50200/udp"

Unfortunately, I can't bind docker to public IP address, because of project restrictions.

Previously I'm used webrtc rs, where I was able to configure it like this:

            se.set_nat_1to1_ips(
                vec![public_ip_str.clone().into()],
                RTCIceCandidateType::Host,
            );

If I correctly understand, how it works, it just replace internal ip address only for SDP answer. Everywhere else it use internal IP address

[k0nserv]

As long as traffic is correctly routed from your server's public IP on port 50000 to docker on an interface you bind it should be okay. Binding to 0.0.0.0 is just simpler because it binds on all interfaces

[Razzwan]

Sory, I don't understand, where I have to bind to 0.0.0.0?

I'm trying this way

        let socket =
            UdpSocket::bind(format!("0.0.0.0:50000")).expect("binding a random UDP port");
        let socket_addr = socket.local_addr().expect("a local socket address");

        let candidate =
            Candidate::host(socket_addr, "udp").expect("a host candidate");
        rtc.add_local_candidate(candidate).unwrap();

But it doesn't work even locally. Perhaps I dont understand something very simple but important...

[k0nserv]

You don't want UdpSocket::local_addr for your candidate, that's likely to be a loopback address i.e. 127.0.0.1 which WebRTC forbids from using for ICE.

So if you are working locally like this, not on the server, you should set the host candidate ip to your computer's IP on the local network e.g. 192.168.y.z, 10.x.y.z or 172.x.y.z depending on your network environment

[Razzwan]

@k0nserv

I'm sorry, I don't understand what do you mean and what I can to do... Anyway, thank you very much for answering me...

It should work both locally and on the serever, and obviously I tested both.

Right now I am using such settings:

        let socket =
            UdpSocket::bind(format!("{docker_network_address}:50000")).expect("binding a random UDP port");
        let socket_addr = socket.local_addr().expect("a local socket address");

        let mut candidate_address = socket_addr.clone();
        candidate_address.set_ip(public_ip_address);

        let candidate = Candidate::host(candidate_address, "udp").expect("a host candidate");
        rtc.add_local_candidate(candidate).unwrap();

Locally everything works properly and connection established. But connection on the server doesn't happen. It try to connect, but never connected just connecting status...

SDP answer created correctly, with public server ip, but connection doesn't happen. I don't know why, but I know, that:

1. The same docker settings works properly with webrtc rs, coturn and https://github.com/mycrl/turn-rs, so SDP packages can establish docker container
2. The only difference between server and local is public_ip_address. Locally it is my local machine IP, and remotely it is a PUBLIC_IP

So, I still don't understand, what I'm making wrong, how to debug and where I have to find the bug...

1. Should I change Docker settings somehow? If yes, then how?
2. What should I do to debug an issue on the server? Rigth now no errors on the server, just never ending connection attempts...

[k0nserv]

That looks good to me. It's similar to how we run our production setup.

In terms of debugging:

1. Verify that you are able to read any packets from the socket
2. Verify that str0m wants to accept any packets via Rtc::accepts
3. Check str0m's ice logs by setting str0m::ice=debug or even str0m::ice=trace in RUST_LOG
4. Check if you are getting anything to send from str0m
5. Check if you are receiving anything in the other peer (if it's a Chrome browser look at chrome://webrtc-internals and the ICE candidate grid for STUN responses received).

Also, if you are using TURN with webrtc-rs but not str0m that might be part of your problem

[Razzwan]

First assumption was correct. To make it work we just need to replace ip address only for answer with public IP address:

        let mut str0m_answer_str = str0m_answer.to_sdp_string();

        if let Ok(public_ip_str) = std::env::var("PUBLIC_IP_ADDRESS") {
            let re = Regex::new(
                r"\b172\.(1[6-9]|2[0-9]|3[0-1])(?:\.(?:25[0-5]|2[0-4]\d|1?\d{1,2})){2}\b",
            )
            .unwrap();

            str0m_answer_str = re
                .replace_all(&str0m_answer_str, public_ip_str.as_str())
                .into_owned();
        }

Such way it works. So initial proposal still relevant: to add method for that functionality

[k0nserv]

But you already added a host candidate with the public ip address with this?

        // <snip>
        let mut candidate_address = socket_addr.clone();
        candidate_address.set_ip(public_ip_address);

        let candidate = Candidate::host(candidate_address, "udp").expect("a host candidate");
        rtc.add_local_candidate(candidate).unwrap();

Can you share the relevant parts of str0m's answer before and after your replacement?

[algesten]

Such way it works. So initial proposal still relevant: to add method for that functionality

You will not need any SDP mangling or this function. str0m should have no knowledge of your internal IP, only the public added as a "host" candidate.

SDP that str0m produces will then only give you the public IP.

The Output::Transmit will have source set to your public IP, but you transmit it over the UdpSocket you bound locally.

[Razzwan]

You will not need any SDP mangling or this function. str0m should have no knowledge of your internal IP, only the public added as a "host" candidate.

UdpSocket::bind(format!("{PUBLIC_IP}:50000")) will only work if --network host.

In --network bridge which is default settings for the docker container PUBLIC_IP is not accesible. In bridge mode, Docker creates a separate network namespace for the container with its own eth0 interface and an internal IP (usually 172.17.x.y). The host’s public IP does not exist inside that namespace, so binding UdpSocket::bind(format!("{PUBLIC_IP}:50000")) will lead EADDRNOTAVAIL error.

But client don't know about docker network and able only interract with server PUBLIC_IP, that's why before we will send candidate to the client it is required to replace internal docker bridge network IP addres with server PUBLIC_IP_ADDRESS. When a client sends data to the server, server knows how to handle it thanks to the docker settings

[algesten]

This is what the str0m documentation calls "NIC enumeration" – you need to know, or discover, the IP addresses you are going to use. It's the same as for a browser and with a Sans-IO implementation, we decided, so far, that this is a problem that isn't directly related to WebRTC.

One way of discovering your public IP is to use a STUN (or allocate on a TURN) server, and although str0m talks STUN as part of being an ICE agent, using it to do NIC enumeration, is considered an IO-problem: it's about how your IO situation looks in your deployment. Someone recently asked about having STUN/TURN nic enumeration inside str0m, and I'm on the fence about that. You could weigh in on that issue with this specific case.

Are you trying to use str0m as server or client or both?

[Razzwan]

I am trying to use Str0m as an SFU server. I am trying to create a room for 3 people and connect all of them. I have a TURN server, Coturn, so browser clients can discover their IP addresses and create correct ICE candidates. I already have a fully working SFU based on webrtc-rs. My current task is to compare the performance of webrtc-rs and Str0m.

I hope Str0m will be significantly faster than webrtc-rs. The maximum number of users in my current SFU implementation is 50. However, the minimum reasonable amount for my current task is 120 simultaneous clients (10 rooms with 12 users each). That's why I need this comparison to understand if it makes sense to move to Str0m or not.

This is what the str0m documentation calls "NIC enumeration" – you need to know, or discover, the IP addresses you are going to use. It's the same as for a browser and with a Sans-IO implementation, we decided, so far, that this is a problem that isn't directly related to WebRTC.

My initial suggestion concerned only one thing: providing a correct HOST candidate for the SFU server to send to the client when using Docker with bridge network settings. In that case, the candidate inside the Docker container must be the internal network IP address of the Docker network. However, when this candidate is sent to the client, it must be converted to the server's public IP address.

This issue is specific to the str0m library and is not about how candidates are discovered, because the host candidate is created manually (as in the example). This manual creation process fully meets all the SFU's requirements and doesn't require any external STUN/TURN servers, if I understand it correctly. At least, it created the same way in all other webrtc libraries, which I touched, when we have to create SFU server

[k0nserv]

I had Claude rewrite the str0m example and make a simplified version running in Docker with bridge networking. This now works, the key thing is that you need to tweak the IP address when you hand off to str0m.

You'll receive traffic ingress on 172.18.0.1:{random_port} (Gateway) which. The socket's local address will be 172.18.0.2:10000 and if you use this when inputting packet to str0m it will not work because this does not match a candidate. Instead you should replace Receive::destination with the public ip / port pair.

Str0m will then form a host-prflx candidate pair with the remote candidate being 172.18.0.1:{random_port}. This works because the bridge network will rewrite packets sent to 172.18.0.1:{random_port} on the egress path.

So in total:

1. Bind your UdpSocket with 172.18.0.2:{port} or 0.0.0.0:{port}
2. Add a host candidate with the server's public IP and port
3. Use the SocketAddr for the public ip and port when creating Receive not socket.local_addr().unwrap()

[Razzwan]

@k0nserv are you sure, that it works in your case? One more time reimplemented all things you described, but connection not happened. I don't know, why, but main guess, that when you add local_candidate

let candidate = Candidate::host(candidate_addr, "udp").expect("a host candidate");
rtc.add_local_candidate(candidate).unwrap();

it must be correct resonable candidate_addr withing docker container. So, in my case, only replacement in SDP works properly. Tested many times and I am pretty sure

[k0nserv]

Yes it works fine for me.

If you use the address of the local socket for the candidate you'll get a candidate with 172.18.0.2 as the IP. This is obviously not reachable from outside the Docker container since it belongs to a private subnet.

You are doing something similar to me by munging the SDP because you end up saying to the remote "Send traffic to PUBLIC_IP_PORT" and then when it's received you say to str0m "This is traffic bound for 172.18.0.2". This makes things work within str0m (it can match up the right candidate).

My version announces the PUBLIC_IP_PORT to the world and then remaps the packet destination from 172.18.0.2:1000 to PUBLIC_IP:1000 so str0m can match the right candidate.

It's similar to the NAT 1-to-1 thing in webrtc-rs.

What does chrome://webrtc-internals candidate grid look like?

[algesten]

So in summary for 1-to-1 NAT SFU scenario with str0m, we recommend:

1. Bind local $PORT
2. Use ice-lite to avoid making connectivity checks from the server.
3. Add a host candidate with the public IP ($PUBLIC_IP:$PORT). This ensures the SDP correctly advertises the public IP.
4. For incoming packets, use $PUBLIC_IP:$PORT in the Receive::destination field.

[Razzwan]

Agreed!

In this example, it even doesn't matter if you use ice-lite or not. It will work in any case, which is also an advantage.

My working approach:

• Bind to local $PORT
• Add a host candidate locally with $LOCAL_IP:$PORT
• Send a host candidate to the remote peer using the address $PUBLIC_IP:$PORT. This involves replacing the private IP address ($LOCAL_IP) in the SDP offer or answer with the public IP ($PUBLIC_IP) before sending it to the remote peer.

Advantages:

1. ice-lite not required
2. all parts work as expected and predictably

[algesten]

I don't encourage any solution that requires SDP munging to avoid private IP details from leaking.

If it works for you, great, but I stand by the accepted answer.

[Razzwan]

My goal is to get a working application. Of course, I am also interested in ensuring its security. Inside the code, you have access to the private IP address of the local network, which you can use as a local candidate. I do not understand how this could lead to data leakage. I would greatly appreciate it if you could explain, as I plan to incorporate this solution into my production code.

Actually, this doesn't require SDP munging. If we start using trickle ICE and send candidates separately from the SDP, the only change needed will be to update the candidate's public address. The same logic applies when you need to find a candidate that the remote peer can use to send you UDP traffic using STUN server

[thomaseizinger]

Actually, this doesn't require SDP munging. If we start using trickle ICE and send candidates separately from the SDP, the only change needed will be to update the candidate's public address. The same logic applies when you need to find a candidate that the remote peer can use to send you UDP traffic using STUN server

Yeah, I was only talking about it from an ICE perspective where you trickle candidates individually. If you don't include them in the initial offer/answer, you can just skip sending the one with the local address and thus don't leak any private information.

[algesten]

Search-replace is SDP is known as "SDP munging". It works off course, but in this case, if you're not careful, you might search for the wrong thing and not replace anything. It still works because of the peer_reflexive discovery, so you're not even aware that you're leaking.

The intention of moving this into discussions QA, is that this question will come up again for someone else, and my accepted answer is still the correct one. So I'll stick to my guns: don't add private IP to Rtc unless you're OK with them to be leaked. There are ways around it, but this is the general recommendation.