Two things:

1) Firebase claims: "Data is stored as JSON and synchronized in realtime to every connected client."

This may sound convenient, but it means that every client will be able to see every state of every game. If that doesn't matter to you, then that's fine. If secrecy matters (say, a poker game,) you may need to take additional steps to make sure people can't cheat.

2) A public IP address alone only identifies a network interface. As you suggest, for a typical device, this will be the network interface of your firewall/NAT gateway. To identify a particular "service" or "application instance," you need an IP address plus a port. Thus, you need to store IP address and port in the database. Then you need to make sure that that port stays the same. You do this by keeping the connection alive; for TCP by not closing it, and for UDP by keeping a stream of messages going.

But a public IP + port just identifies a connection, not a player. If player 3 wants to challenge some other player, you really need a unique player ID. Then perhaps you can have a look-up from player ID to current connection. However, connections, in turn, only work client-to-server, unless you also establish peer-to-peer connections, and to establish peer-to-peer connections, you need an introducer to do NAT punch-through. You can either roll this on your own using UDP sockets and some central server as the coordinator/matchmaker (this doesn't seem to be built into Firebase,) or you can use existing STUN/TURN servers and infrastructure to set this up.

In general, "serverless" platforms like Firebase often end up being a poor match for interactive multiplayer games on the internet, because games often have unique requirements. Sometimes, you can use them, but you will pay a higher overhead than you'd pay for a custom game-specific solution. Sometimes, that overhead is OK, and othertimes, you really do need to develop your own infrastructure from lower-level primitives.