The reason games and the like don't work when libalias is in use is that the machine on the outside will try to open a connection or send (unsolicited) UDP packets to the machine on the inside. The packet alias software doesn't know that it should send these packets to the interior machine.
To make things work, make sure that the only thing running is the software that you're having problems with, then either run tcpdump on the tun interface of the gateway or enable ppp tcp/ip logging (``set log +tcp/ip'') on the gateway.
When you start the offending software, you should see packets passing through the gateway machine. When something comes back from the outside, it'll be dropped (that's the problem). Note the port number of these packets then shut down the offending software. Do this a few times to see if the port numbers are consistent. If they are, then the following line in the relevant section of /etc/ppp/ppp.conf will make the software functional:
alias port proto internalmachine:port port
where ``proto'' is either ``tcp'' or ``udp'', ``internalmachine'' is the machine that you want the packets to be sent to and ``port'' is the destination port number of the packets.
You won't be able to use the software on other machines without changing the above command, and running the software on two internal machines at the same time is out of the question - after all, the outside world is seeing your entire internal network as being just a single machine.
If the port numbers aren't consistent, there are three more options:
1) Submit support in libalias. Examples of ``special cases'' can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c is a good prototype). This usually involves reading certain recognised outgoing packets, identifying the instruction that tells the outside machine to initiate a connection back to the internal machine on a specific (random) port and setting up a ``route'' in the alias table so that the subsequent packets know where to go.
This is the most difficult solution, but it is the best and will make the software work with multiple machines.
2) Use a proxy. The application may support socks5 for example, or (as in the ``cvsup'' case) may have a ``passive'' option that avoids ever requesting that the peer open connections back to the local machine.
3) Redirect everything to the internal machine using ``alias addr''. This is the sledge-hammer approach.