In my network, WireGuard uses fixed ports for a long time, which can be captured and restricted by ISP. I plan to use scripts to regularly change the port number for WireGuard interfaces. How to avoid conflicts with the ports already used by this device has become the problem I need to solve.
I plan to use the/system telnet tool for detection.
[admin@MikroTik]/system> telnet 127.0.0.1 12345
When the port is in use, its return message is:
Connecting to 127.0.0.1
telnet: connect() failed: Connection refused
Welcome back!
When the port is not in use, its return message is:
Connecting to 127.0.0.1
Connected to 127.0.0.1
Remote closed connection: 127.0.0.1
Welcome back!
I also found that the as value parameter cannot be used to intercept the return information at this time. Do you have any suggestions or solutions? Thank you in advance!
If your ISP is blocking WireGuard, they are probably doing it not based on UDP ports, it would be too easy. They are probably using DPI to detect WireGuard distinctive packets. What you are trying to do is not worth the hassle most likely.
There is a project called amnezia-wg that allows customizing some internal protocol structures to avoid DPI. RouterOS doesn’t support it natively, but you could use a container.
They can also suspect that VPN is used even if VPN protocol is not detected by DPI by just detecting connections to same port with heavy traffic and throttle or block connections to that port. Switching ports in some intervals can help in this case, needs research how often - find out how long can last until detected and switch port in some random interval below max time to avoid switch detection by pattern (fix interval).
It seems that the ISP has not yet enabled the protocol recognition mechanism. After a period of observation, whenever there is a problem with WireGuard connection, changing the port number can always solve the problem, so it should be able to handle it for a while.
I have set the keep alive duration to 1 minute. When there is a problem, it cannot keep alive for more than ten minutes. Perhaps I can set a threshold in the script to trigger the change of port number.
Even if connection is not long lasting connection, they can count traffic to same port in some period so IMO that will not help much if detection works like that. Find out period how long it last on same port and then script changing to unused random port in some smaller ranged random interval than that time.
Scripting random port changes could be challenging since the other end needs to be aware of the new port. Maybe try an assigned port like UDP 123 or 21, perhaps they are less prone to blocking (depending on the country).
Another idea is to set up multiple tunnels (assuming this is site-to-site) on different ports and configure failover, so that connectivity is not interrupted for long. The second/third tunnel could also be used in scripting to make the changes to the original port on both ends and fail back.
Thank you for your reply. I will check the content of the post you mentioned later.
As for whether the issue was caused by ISP blocking, I have no way to verify, so it is indeed a personal guess, but at least for now, changing the port number can temporarily solve this problem.
Regarding how to notify the other end of the updated port number, I had the following considerations earlier:
Communicating information through a third party, such as building a Python program on a server to receive and query the latest port numbers;
The two end devices calculate the port number according to the preset rules based on the current date. At a certain time in a certain year, month, day, the port number must be a definite value.
But last night I came up with the best solution:
Construct a port number into a fictional IPv4 network address using certain rules, update it to a DDNS domain name (dynv6, cloudflare, etc.), and the IPv4 network address does not need to be real, valid, and reachable. It only needs to be able to be resolved through DNS. The peer polls the IPv4 network address of the domain name, and once a change is detected, it is resolved into a port number according to the same rules and the WireGuard configuration is updated.
Well, yes, once the mechanism is confirmed, the rest is to fine tune the interval time for port changes. That’s not difficult, as those of us who tinker with technology are never afraid of trouble, lol.
Thank you! anserk， Based on the clues you provided, I have learned that setting the listening port value to 0 will automatically assign a random port, and I believe the system is likely to automatically avoid the ports that have already been used.
In the latest beta version 7.19rc2, all port information currently being used by the device can be viewed, and the relevant entries in the changelogs are as follows:
*) ip-service - show all TCP/UDP ports on system, including ports in containers (additional fixes);