GIT is using the wrong IP to send Packets

Gamer's Internet Tunnel, formerly Gamer's IPX Tunnel

GIT is using the wrong IP to send Packets

Postby STEX20 » Tue Sep 18, 2007 4:26 pm

Hello everyone.

I have a little problem with my GIT configuration.

I connect to the networks of some friends through an VPN-Tunnel, and we use GIT to transfer the Broadcasts into the other Networks.

Yesterday it worked flawlessly, and today it isn't working anymore, so i tried to find out why by capturing the packets with Wireshark.

Wireshark shows packets which go from my ip xxx.xxx.10.5 to the destination xxx.xxx.1.119 and they arrive on the other side.

also i see Packets are coming to my ip xxx.xxx.10.5, but they aren't from the other's side network interface xxx.xxx.1.119, but from the IP which the virtual nic of the VPN has (xxx.xxx.100.2). So why GIT is sending out packets with this ip, if it's supposed to Capture Packets on the real nic (xxx.xxx.1.119) and also accepts incoming packets on this IP?

Thanks for Help.

STEX20
STEX20
 
Posts: 5
Joined: Tue Sep 18, 2007 4:16 pm

Postby Ark » Tue Sep 18, 2007 6:17 pm

GIT captures packets exactly as they are on the network and sends them as-is.
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby STEX20 » Tue Sep 18, 2007 11:43 pm

If it captures packets and don't modifies them, they won't arrive, because of the (Layer-3) VPN-Tunnel.

Or what do you mean by "sends them as-is"?

I thought it captures the Packets, puts them into UDP or TCP Packets and sends them over the Network to the other Host, which will extract the "real" Packet from the UDP or TCP packet, and then give it to the "real" nic. Is this correct?

Its the problem that the Source IP from the UDP:215 packet is different to that one in my Configuration of GIT. And this causes GIT to reject the Packets, because they aren't from the Host it has in it's configuration. So i see in the Connection Status that packets are sent out, but no packets are recieved.

On the Side of my friend GIT says it's recieving packets from me, and it's sending packets to me, but they never arrive.

GIT is a very nice piece of Software, and with the other 2 guys it's working perfectly, because the VPN-Tunnels to them are "Site-to-Site" and aren't established by the Clients which run GIT..

The Connection with the problem is "Client-to-Site" and GIT is running on the Host which establishes the VPN-Connection.

Thanks for Help.

STEX20
STEX20
 
Posts: 5
Joined: Tue Sep 18, 2007 4:16 pm

Postby Ark » Tue Sep 18, 2007 11:55 pm

This is not a GIT issue, but an issue with you VPN or NAT setup. The tunnel connection works like any normal internet connection for TCP or UDP and you need to put the external, internet-facing IP address in the GIT configuration to connect to on each side.

If a GIT is on a LAN using NAT, and it thinks its local IP is 10.1.1.1, it may send a UDP packet from 10.1.1.1 to 65.1.1.1 (for example), but it is the job of the NAT gatway to translate that packet GIT is sending to be "from" some real IP and not send a packet onto the internet itself with a private IP address for the source.

The packets inside the GIT payload are captured by GIT, send inside a UDP wrapper, and re-transmitted by GIT, without modifying the source or destination addresses of them (unless you use that one particular option which isn't usually useful).
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby STEX20 » Wed Sep 19, 2007 6:07 am

I think my description of the situation wasn't complete, so i tried to draw the setup.

Here is the link to it:

http://dl.theovertakers.de/netzwerksetup.jpg

As you can see, there is no NATing device between the two Hosts, because the Packets are going through the Internet in a Tunnel, and the Hosts can see each other without any swapping of IP's in Packets, only through Routing.

so GIT is configured like this:

Code: Select all
192.168.10.5:

Hosts to connect to:

192.168.1.119:215 (udp)

Ports:

1-212
218-65535

IPX:

all Sockets

GIT is configured to NOT alter Source IP's

Forward all Packet types and Frame Types

Don't send Routable
Don't send Unicast

(So it should only forward Broadcast traffic)

#########################################

192.168.1.119:

Hosts to connect to:

192.168.10.5:215 (udp)

Ports:

1-212
218-65535

IPX:

all Sockets


GIT is configured to NOT alter Source IP's

Forward all Packet types and Frame Types

Don't send Routable
Don't send Unicast

(So it should only forward Broadcast traffic)


But now i think i understand, what you mean, but isn't GIT supposed to send Packets only with the IP from the NIC you selected in the Advanced Configuration?
STEX20
 
Posts: 5
Joined: Tue Sep 18, 2007 4:16 pm

Postby Ark » Wed Sep 19, 2007 8:08 am

Again, this doesn't seem like anything GIT can control or change. If the packet for the UDP port 215 connection arrives with a different source address than you think it should, it would -have- to be your network/VPN/NAT/computer/etc using or changing the address of the packet to that address.
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby STEX20 » Wed Sep 19, 2007 11:07 am

Ok, now i understand what you mean.

You say that there must be some sort of device between the GIT and the VPN (or even the vpn adapter itself), which is changing the source adress of the packet.

So GIT sends out Packets with the Source IP from the Adapter it's capturing it's packets from, and then the IP Adress gets changed in any other Software.

Ok, then i have to take a look at the VPN config.

Thanks for Help.

STEX20
STEX20
 
Posts: 5
Joined: Tue Sep 18, 2007 4:16 pm

Postby Ark » Wed Sep 19, 2007 2:43 pm

Yes, the UDP 215 connection between GIT and GIT does not use any tricks or packet sniffing or packet modification. The UDP port 215 connection you configure for GIT-to-GIT communication uses normal Windows Sockets to send a UDP packet with a destination of the address and port you specify in the GIT configureation. The source address is assigned by Windows and can be modified by VPN or NAT devices before the packet reaches the Internet.

VPN / NAT / etc will never inspect the GIT packet payload (which is another network packet, but VPN/NAT/etc don't know that).
Ark
Site Admin
 
Posts: 2108
Joined: Sat Sep 13, 2003 4:21 pm

Postby STEX20 » Thu Sep 20, 2007 10:22 am

Ok,

the Packets aren't going through any nat device.... but i think windows is assigning the wrong source ip for the git packet.

The wrong ip is not in the payload but in the "outer packet".

You said, Windows assignes the IP for the "outer packet". But how is this adress determined? Does windows take the Interface from the Routing table, or from where?

I know, that you can change the Order in which Programs see the network devices, but it's set to have the real nic on top of the "virtual" vpn nic's, so windows should assign the ip from the real nic as the packet's source ip.

That's one thing i don't understand.

edit: I changed the Peer ip from 192.168.1.119 to 192.168.100.2 and it works, but still it seems, that the broadcast are not arriving. I should check the config of GIT again.
STEX20
 
Posts: 5
Joined: Tue Sep 18, 2007 4:16 pm


Return to GIT

Who is online

Users browsing this forum: No registered users and 0 guests

cron