[cod] And with the patch the problem with NAT is back

[Bryan Kuhn]

That because firewalls are dropping fragmented packets.

I think we have a solution to the auth problems behind firewalls so it
should be fixed next patch.

Monday, February 9, 2004, 4:40:37 AM, you wrote:
> I think this is also related to the problem of not being able to do a
> status.  It seems everyone behind a firewall and NAT cannot do a /rcon
> status.

> John Kennington
> Assistant Director - Operations
> BuzzCard Center
> Georgia Institute of Technology
> 350 Ferst Dr. NW
> Houston Bookstore Mall
> Atlanta, GA  30332
> 404-385-2961
> 678-283-3385 Cell
> 404-894-2049 FAX
> http://www.buzzcard.gatech.edu/
> BuzzCard FAQs:  http://www.buzzcard.gatech.edu/faqs/index.htm

> -----Original Message-----
> From: Boy_One (COD System Admin) [mailto:cod at kaleplek.net] 
> Sent: Monday, February 09, 2004 6:22 AM
> To: cod at icculus.org
> Subject: Re: [cod] And with the patch the problem with NAT is back

> Hi Troy,

> Thanks for this this is the first one who understands my problem. And
> you
> are almost right. What i did was i tcpdump to see what was send and what
> was
> recieved.

> Here the mechanisme in a nutshelf....

> client connects to server > server asked codauth and client to auth
> client
ip >> auth server then gets connection from different ip(client) and says
> ok.
>> server is still waiting for auth server to say ok for the client who
> is
> trying to connect (internal ip adress).

> This is my problem beacuse the server is waiting until the 10.5.1.123 ip
> adress is AUTH by activision and never gets an ack to it so no
> connection to
> server.
> And in the 1.1 version it timed out after 25 seconds waiting. But in
> this
> new version no luck. So it looks like the fixed this problem(like they
> sayd
> in an earlyer mail) but know i want to know what they did and how to
> solve
> this.

> Regards
> Quint


> ----- Original Message -----
> From: "Troy Chinnery" <t_chinnery at iprimus.com.au>
> To: <cod at icculus.org>
> Sent: Sunday, February 08, 2004 12:37
> Subject: Re: [cod] And with the patch the problem with NAT is back


>> Those other two replies are obviously clueless. I don't know if I can
> offer a
>> solution, but perhaps just an underthought-out idea.
>> Is it the server that sends the authentication packet? I thought, the
> client
>> sends their key to an auth server, and the game server then asks the
> auth
>> server if the client at the connecting IP has a valid key. The auth
> server
>> obviously, not aware of this internal IP, replies "CD key in use"
> (because
> it
>> recently got an auth request for that key). If this is the case, then
> maybe an
>> iptables rule on your gateway, that prevents any internal IP except
> the
> game
>> server from communicating.
>>
>> Or if that's all wrong, maybe you can run a packet inspection program,
>> inspecting packets from the game server to codauthorise for internal
> IP's,
> and
>> blocking them.
>>
>> Just some things to ponder.
>>
>> cod at kaleplek.net wrote:
>> > Yes this works if you want to use a private server. But i'm using a
> public
>> > server and then when i do this i won't show up in any list on the
>> > internet(ASE/gamespy).
>> >
>> > Lets give some background to everyone to put it in the light again :
>> >
>> > Internal workstation      Nat Server internal/external
>> >                            (with cod running on it)
>> > 10.5.1.123 -------------> 10.5.1.1 / 62.216.16.89 -------> Internet
>> >
>> > Connecting from my machine results that the server is seeing that
> adress
>> > is local and not remote and connects me not through nat but
> internal.
> Then
>> > the server is asking to authenticate me with my internal address by
>> > Activision. This is dropped by activision because private spaces are
> not
>> > allowed on the internet.
>> >
>> > What i'm looking for is a workaround/fix that is saying when it is a
>> > private range don't Authenticate on the internet everything else do
>> > Authenticate. Or even better when i can say don't Authenticate ETH1.
>> >
>> > Please is there somebody who know how to do this, or can push me in
> the
>> > right direction.
>> >
>> > Thanks
>> > Greetz
>> > Quint
>> >
>> >
>> >
>> >>You can add a line in your hosts file that points
>> >>codauthorize.activision.com at 127.0.0.1
>> >>
>> >>  _____
>> >>
>> >>From: orr [mailto:orr at cadetmail.uscga.edu]
>> >>Sent: 06 February 2004 02:30
>> >>To: cod at icculus.org
>> >>Subject: RE: [cod] And with the patch the problem with NAT is back
>> >>
>> >>I have the exact same problem there, shipmate.  Except i never even
> got
>> >>it to work for 1.1 and gave up... i figured patching to 1.2 would
> fix
>> >>it. That's not the case, eh?  How do I get my LAN server to stop
>> >>checking for a cd key (yes, i AM flagging +set dedicated 1)
>> >>
>> >>Thx
>> >>
>> >>-Tim
>> >>-----Original Message-----
>> >>From: Boy_One (COD System Admin) [mailto:cod at kaleplek.net]
>> >>Sent: Saturday, January 31, 2004 7:08 PM
>> >>To: cod at icculus.org
>> >>Subject: [cod] And with the patch the problem with NAT is back
>> >>Hi all,
>> >>
>> >>I posted this before and with your help i got it working to log on
> to my
>> >>own server. But now with the patch installed the problem is back.
> For
>> >>you who doesn't know my problem a little info.
>> >>
>> >>I have a server running on my linux machine at home. This machine
> also
>> >>gives me NAT to the internet. Now when i try to connect to it from
>> >>inside my LAN he tries to AUTH me by activision with my internal
> network
>> >>address.
>> >>
>> >>Before the patch he timed out and let me in. But now with the new
> patch
>> >>it is starting allover again. I know somebody said this was put on a
>> >>list to look at and maybe solve it. Is this done so and if the
> answer is
>> >>yes,  is there a cvar i have to set to let me connect to my server
>> >>again. Or is my nightmare back... :-( I hope not. Who can help me...
>> >>
>> >>Regards
>> >>Quint
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>>