How to solve ISP blocking remote UDP port?

[yon 0]

i want to use vpn connect remote vps udp port, but local ISP seem is blocking connect remote vps udp port, How to solve ISP blocking remote UDP port?

Can i use like iptables setup this or other ways?

[Gertjan]

Hi,

This remote vps udp port is your VPS ? Change that port on the server. Done.

You can't do anything locally. "iptables" or equivalent on FreeBSD/pfSense can't help you here. Your VPN Client has to use the port where the VPN server is listening on. That's why some of them even offer to listen on TCP port 433.
No local firewall rule trick can help you.

Non technical solutions :
Before signing up with an ISP, you have the two major numbers : cost and promised speed.
Up to you to discover the things didn't not wont put on the front page of the contract.
Like : what are they blocking ? Are they forcing a DNS ? These issues, and a unimaginable number of other aspects can you be discovered if you look for them.
The same thing goes for your VPN supplier. Never sign up with them because you liked their flashy web page.

[yon 0]

yes, the vps manange by me. but an country ISP blocking udp port. not only for me, all users cant connect it.

yes, i know change port , I am worried that more ports may be blocked in the future.

[Gertjan]

Port 80 and 433 (TCP !) or excellent candidates.
No one can block these.

[Rico]

433?
443...

-Rico

[yon 0]

ignoring.zip @Rico said in How to solve ISP blocking remote UDP port?:

433?
443...

-Rico

31590 udp

i find the about tcp, but i need udp.

Deliberately Ignoring Resets
The firewall relies entirely upon the endpoints implementing the TCP protocol [11] in a standards-compliant manner and aborting the connection when a
reset packet is received. The firewall could sometimes be slightly caught out, as
we noted above, when the resets beat the GET packet to the destination and so
they were ignored by the careful validation that was applied. Nevertheless, the
connection was successfully torn down as soon as the next packet transited the
firewall, and hence this didn’t make much overall difference.
But now consider what happens if the endpoints do not conform to the
standards and the TCP resets are entirely ignored. We might expect the firewall
to have no impact on HTTP transfers, despite them triggering the IDS system.
We therefore conducted a further experiment with both of the endpoints
ignoring TCP resets. We could have achieved this in a number of different ways,
but we chose to set appropriate rules within packet filtering firewalls. Within
Linux we installed iptables and gave the command:
iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
which specifies that incoming TCP packets with the RST flag set are to be
discarded. If we had been using FreeBSD’s ipfw the command would have been:
ipfw add 1000 drop tcp from any to me tcpflags rst in

[yon 0]

@Gertjan said in How to solve ISP blocking remote UDP port?:

Port 80 and 433 (TCP !) or excellent candidates.
No one can block these.

They will do anything.

[Gertjan]

@yon-0 said in How to solve ISP blocking remote UDP port?:

They will do anything.

That means you have a Internet that would block 'www' possibilities ??
From what I know, such a thing doesn't exists. No-where.
It's like buying a phone that can't make voice calls.

iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
ipfw add 1000 drop tcp from any to me tcpflags rst in

I'm not a firewall expert, but these two say to me :
Packets with RST flags set are discarded. That is : Important : Out of states packets. RST packets can not exist "out of state".
This type of packet are probably used by DDOS attacks.

I do not understand what these firewall rules have to do with the subject : "How to solve ISP blocking remote UDP port?"
These rules are for firewall incoming traffic.
Your issue is that you can't reach remote ports.

Btw : ipfw isn't used by the "firewall" pfSense, which is a called "ip" - only the captive portal is using it.

[JKnott]

@Gertjan said in How to solve ISP blocking remote UDP port?:

From what I know, such a thing doesn't exists.

What about deep packet inspection? Is there no difference between a VPN and normal web site traffic that it could detect? For example, I wouldn't expect to see a lot of HTML code in a VPN connection.

[Gertjan]

I was referring to "blocking ports 80 TCP and 443 TCP by your ISP".

Of course, "ISP's can deep inspect" what ever they want. All they get is a close to perfect pink nois generator - or a perfect random number source. Traffic is all https based - like VPN ....
So go inspect ...

@JKnott said in How to solve ISP blocking remote UDP port?:

I wouldn't expect to see a lot of HTML code in a VPN connection.

Better : https tunnelled in a VPN .....

[JKnott]

@Gertjan said in How to solve ISP blocking remote UDP port?:

Better : https tunnelled in a VPN .....

I wonder if there are any characteristics that would show through the encryption, given that VPN traffic would vary significantly from typical web sites. That's an important factor in breaking encryption, where the crypto-analysts look for certain patterns.

[yon 0]

i find an file say this.

[link removed]

[stephenw10]

You'll need to post the text you are referring to. You can't just post random file links with no explanation. It could contain harmful content.

Steve

[yon 0]

It looks like someone is engaged in research on this matter. I don't know how to use it yet.

https://github.com/bol-van/zapret/

[Gertjan]

@yon-0 said in How to solve ISP blocking remote UDP port?:

https://github.com/bol-van/zapret/

Incredible.
And impressive, the effort that has been taken to circumvent this 'MITM' thing.

Using this tool asks for some serious networking knowledge. It's rather simple to know how much you need : you have to be smarter as those guys that made and put in place this 'DPI' thing.

I don't know where you are, @yon-0 , I advise you to move out/away.

Btw : DPI on https (TLS/SSL) : forget it, those DPI guys are not human, or aren't using terrestrial resources to do so.