Not working at all, can't connect, and routing table overflow(

[coolermister]

Hi guys! First of all sorry for my english) Becouse english isn't my native language) (If someone have interested in this, my native language is russian) I have really strange problem. I compiled the proxy sucsessfully. The server which will run proxy is behind my nat router(i have public static ip of course), and have address 10.10.158.233(my local network is 10.10.158.0/24) 8443 port looks outside. ip of router is 10.10.158.254. So, when i run proxy with command mtproto-proxy -u nobody -H 8888 -p 8443 -S <here is the secret> -M 3 --aes-pwd proxy-secret proxy-multi.conf it succesfully starts.

But in secods after it's started, routing table of my router is overflowed. For example: Before After run: Limit on router is net.netfilter.nf_conntrack_max=65536 When it's running, i can't connect to it using local ip, and public ip too, from my android client. And after something about minute, router is going down) System is Ubuntu 16.04 x64. So, what i'm gonna do? Which additional information i can provide, to fix it?

[shadowlmd]

And of course you can telnet to these addresses/ports without problem? I guess, something is totally broken in MTProxy network implementation then.

[d-makarenko]

And of course you can telnet to these addresses/ports without problem?

Yes, telnet connected without any problem. It is definitely something is broken, but it affects only small part of (perhaps) incorrectly configured vps. Also, yesterday my SP started to SIGKILL every process with the name 3proxy so it might be some kind of deliberate decision to block any proxy server on the vps. They didn't respond to the ticket yet though.

[shadowlmd]

@d-makarenko, I've just thought about a workaround. I see that your vps does not have IPv6, so you can create a tunnel with https://tunnelbroker.net for example. Then you can use curl -s https://core.telegram.org/getProxyConfigV6 -o proxy-multi.conf to generate IPv6-only upstream endpoints and see if that works for you. If your SP was filtering IPv4 traffic, most probably it will not try filtering 6in4 tunneled traffic.

[d-makarenko]

Yep, it might work, but sit is not enabled on my VPS, I'll ask my SP if it can be enabled, but this is out of topic. The question is why MTProxy is behaving this way, while other proxy and vpn services are working fine on this vps.

[shadowlmd]

Wow, you have the most weird VPS I ever seen. :)

Anyway it's really hard to understand why MTProxy behaves this way (I don't really understand C, and developers do not seem to be interested). But you mentioned that SP may filter traffic, and this could be the reason of connections being in TIME-WAIT state. And if that's the case, tunneling is the best option you have. Another option is VPN, but that seem completely pointless.

[d-makarenko]

Wow, you have the most weird VPS I ever seen. :)

Good thing is that I got it dirt cheap. Well at least good old 3proxy is doing good.

[Revertron]

@shadowlmd Just read my comments. This behavior is random. I've successfully used it for 19 days, it have rebooted every night to take new configs, and everything was fine. But after server reboot it gave me this very problem. It is definitely a bug.

Now I'm using python version of MTProxy from here: https://github.com/alexbers/mtprotoproxy It renews its configs automatically, no need to make some cron jobs.

[shadowlmd]

@Revertron, well, I'm running it on 3 servers, had problem only on one of them that was behind NAT, and the problem was resolved with --nat-info parameter. So I can only guess that something is not working right on your server. Maybe traffic is being filtered, maybe something else, I don't know.

Alternative solutions are ok, but they are not official and can get broken at some point. MTProxy is implemented in a very weird/buggy way, but it is official, so most people will stick with it.

[Revertron]

@shadowlmd Yep, my problem was on a NAT'ed server too, but the --nat-info parameter worked for 19 days, and didn't work after that. Magic? :)

[javad11sa]

Hello, I suggest you test it

sudo ufw allow 440

Proxy with a 440-foot port

ufw reset -y

Reboot the proxy again

[aistoff]

Try sync the server clock:

ntpdate pool.ntp.org

Mine were a couple of minutes ahead; Errors disappeared after synchronization.