Just one server with two IP addresses.

The full command I run on stunprotcol.org is this:

./stunserver --ddp --mode full --family 4 --protocol udp --primaryinterface 172.31.10.101 --altinterface 172.31.10.102 --primaryadvertised 3.135.212.85 --altadvertised 3.132.228.249

Where --primaryinterface 172.31.10.101 and --altinterface 172.31.10.102 specify the loca IP addresses on that box. And --primaryadvertised 3.135.212.85 and --altadvertised 3.132.228.249 are the corresponding public IP addresses.

About once a year, on AWS, I have to clumsily revisit how to make an AWS instance with two IP addresses for both IPv4 and IPv6. And Amazon seemingly changes how this is done through their EC2 console each time.

Then I have to get an elastic IP address as well.

Thank you for responding Jselbie, But considering I am not using cloud services, I am still curious if it is feasible to run on two seperate hosts while they have their own public IP respectively. If yes then how? Otherwise, any requirements in terms of the way for obtaining dual-IPs?

The code does not have have support for chaining two basic-mode servers to logically act as a full mode server. It was something I considered a long time ago adding, but once I learned some rudimentary system administration stuff such that a single NIC machine can have multiple IP addresses, it didn't seem relevant anymore. A handful of security issues to work through as well.

The first thing you need to successfully host a full server mode STUN server is two public IP addresses. They don't have to be on the same sub-net.

You can do any of the following:

• A single server box with two NICs. Each NIC has an independent connection to the Internet (not going through the same NAT).
• A single server box with a single NIC, but you're on your own on how to get two public IP addresses. That's some advanced system admin stuff I have to re-learn each time.

What if your environment and network topology? And what are you really trying to do?

For what it's worth, most applications, including WebRTC, really don't need "full mode". Full-mode only exists to complete the specification for enabling clients to determine what their own NAT classification is. But if your client applications follow the ICE methodology of similar, only the basic model of STUN is required.

My purpose is to detect the NAT types of users/clients so that to know in advance about if they can connect each other. Now everything is clear. Thank you sooo much. Have a great day! _

If you use the ICE methodology for P2P connectivity, the clients will not need to detect their own NAT type. The WebRTC stack is a great starting point for ICE connectivity.

Ya, I agree with you for setting up connections. But at our scenario we use this data to help clients to make decisions as you know Turn Server shall bring in additional latencies.