Ark,
Inspired by your answer I started some tests on my local LAN with the goal to check if GIT is able to pick up and forward the ethernet frames of FarCry client and server.
(The final goal is to play FarCry over VPN with some friends)
My conclusion:
The ethernet frame with the "yell" of the FarCry
client isn't picked up by GIT. Sorry, but I'm absolutely sure.
The sniffer on the same machine running GIT picks up the "yell", but GIT doesn't. Really!
The clientrequest doesn't even appear in the unforwarded packets log of GIT.
At the other hand, GIT picks up and forward the
respond of the FarCry
server. So this part of the job works fine. (tested in another testsetup)
Please, will you give a possible explanation for this problem?
Elwin
Some tech notes of client testsetup.
PC1 (10.1.1.10):
- FarCry
client is running
- GIT running in TCP listen mode (10.1.1.11:tcp listen)
PC2 (10.1.1.11):
- FarCry dedicated
server
- Running GIT in TCP connection mode (10.1.1.10:tcp connect).
Forward ports 1030-3600 and port 5678
Only UDP ports, "Only if broadcast" is off
- Sniffer Ethereal
Result:
Content of sniffed ethernetframe on PC2 when PC1 does a refresh server list in FarCry:
Src IP - 10.1.1.10, Dst IP - 234.5.6.7
Src port - UDP 1124 (dynamic), Dst port - UDP 5678 (fixed)
Ark wrote:No, GIT does not care about multicast or what port is what. GIT forwards ALL traffic by just sniffing ethernet frames and reproducing them on the other side. As long as you forward ALL the ports you need using GIT, and forawrd the GIT port through your NAT if you need to, any game should work.