I am also having this issue. I think that the voxl-mavlink-server may have an incorrect implementation of the "server" side of the UDP connection. My evidence would be that using mavproxy.py from a remote computer in client mode (e.g. mavproxy.py --master=udpout:192.168.83.254:14550) does not receive packets from the server, but the server does detect the connection.

I took a look at wireshark and saw that the voxl-mavlink-server in "server" mode is not replying to the mavproxy.py client on the correct port. It is replying to 14550 at the client (incorrect). See the picture below, but ignore IPs as data capture was on a different network. You can see the mavproxy client sending from port 33935 to voxl at 14550, but the voxl incorrectly replies back to 14550 on the client computer when it should be replying back to 33935.
The side-effect of this is that you cannot have two independent clients (talking to different drones) running on the same computer because both drones will send their data to the same port. Computers only allow one process to be a server on a given port.
