Community discussions

MikroTik App
 
DoctorEvil
just joined
Topic Author
Posts: 4
Joined: Sun Jul 11, 2004 7:22 am

problem with 4661 port

Sun Jul 11, 2004 7:33 am

I have complains from my users that p2p programs can't connect to p2p servers on 4661 port. Connecting to aother server with port other than 4661 is no problem. I tried everything (i think so): src-nat, dst-nat, firewall rules (input, output, forward) but nothing helpd, i still cant connect p2p clients to p2p srvers on ports 4661. I us MT 2.8 on my box. Anybody had similar problem?
 
DoctorEvil
just joined
Topic Author
Posts: 4
Joined: Sun Jul 11, 2004 7:22 am

Sun Jul 11, 2004 4:13 pm

No, my ISP does not block this, o any of the ports. This problem came out when i changed from Freesco to MT. 2 weeks ago i was on Freesco and it was OK. And don't say i must change back to freesco :) i like MT but its simply has a problem here.
 
fivenetwork
newbie
Posts: 45
Joined: Thu Jul 08, 2004 4:39 am

Fri Jul 16, 2004 7:56 am

4661?? Sounds like EDonkey. :D

We have noticed that EDonkey performance drops like hell when using private IP's. Are your clients on private IPs or on Public IPs?? If on Public IPs there should be no problem.

This could be a bug in EDonkey wherein it limits the number of clients from a single IP.
 
DoctorEvil
just joined
Topic Author
Posts: 4
Joined: Sun Jul 11, 2004 7:22 am

Fri Jul 16, 2004 9:16 pm

Actually it's eMule Plus v1m. I hav only one external (public) IP. My client are behind the NAT. But ve problem isn't trafic, the problem is port servers witch are listening incoming connections on tcp 4661 port (i tried it my self), i can't connect to those servers. Every other servers, not listening incoming connection on tcp port 4661 is ok.
 
fivenetwork
newbie
Posts: 45
Joined: Thu Jul 08, 2004 4:39 am

Mon Jul 19, 2004 1:12 pm

Hmmm ...

This seems to be a bit similar to the way STEAM server responds.

We beleive that the packets being sent contain the private IP but the listening server sees it as coming from your external IPs and as the two dont match it does not allow the connection to be established.

This is what is happening for the STEAM based authentication system for games like Counter Strike. Ever since the system changed to STEAM servers we have had to give out Public IPs to avid gamers.
 
DoctorEvil
just joined
Topic Author
Posts: 4
Joined: Sun Jul 11, 2004 7:22 am

Found a solution myself :)

Sat Jul 24, 2004 10:04 am

FINALLY :!: :!: :!: after many tries and failures i got it working right. The problem was, that destination nat rule was not bount to a particular interface but to ALL interfaces. I have 3 interfaces LAN, WAN and DSL. DSL interface is connected through WAN interface, so somehow it didn't worked connecting to servers which where listening on incoming client connections on port 4661. So i changed In. Interface from all to DSL and now its working corectly.

Who is online

Users browsing this forum: NanoTik and 35 guests