this is my first question ever here so sorry if it's not in the right category or not perfectly explained. I'll do my best to be descriptive and precise.
Basically, I've done some port-forwarding for games as well as for server-client testing purposes for development. In the past, it's always worked perfectly fine. However, recently, I realized some things stopped working for no apparent reason.
After quite a while of testing, I noticed it was an issue with UDP. Things that require only TCP ports to be forwarded work just fine, however things that need UDP ports forwarded do not. I confirmed this by testing exactly the same application (a simple server-client app made in Godot just to test this) with both TCP and UDP. It connects fine through TCP, but not UDP.
This has never happened to me in the past. Any ideas on what the issue might be? I've Googled for hours and the only things I could find is that A. UDP troubleshooting is apparently incredibly difficult (especially on Windows) and B. Some people vaguely mention the possibility of it being a problem with my ISP filtering UDP stuff.
I've already made sure to check it's not a firewall issue, either. Not sure what else I could try. Am I just missing something really obvious here? Thanks greatly in advance for any possible ideas or suggestions.
You might not get UDP responses because server might be using that specific ports for TCP.
Different UDP scanners using different techniques may come to different results.
There is a possibility of ISP filtering UDP port only if there is hidden NAT -Meaning you will be assigned a public IP, but still would be reaching internet on a different IP (NAT'CEPTION), check for what is my ip to confirm this.
You can take a wireshark packet capture on an upstream device (Firewall or modem if possible)
Related
Our WebRTC app works in every environment until one user turns on a VPN.
The error we're getting is a failed ICE candidate.
We have tried leveraging TURNs along with STUNs, both public and private, still no success.
Any ideas?
Is your TURN server accessiable over TCP? In your ICE Servers list you should have two entries turn:turn-server.com?protocol=tcp and turns:turn-server.com?protocol=tcp. If you don't specify the protocol it will use UDP.
VPNs cause a few different issues with WebRTC. If it is connectivity there isn't much you can do. I have seen a few VPNs that by default have a very low MTU, it may be configurable.
I have a webcam chat room application (so it's many-to-many video sharing) using WebRTC and a mediasoup server.
I am having problems with SOME of my users not being able to get an incoming video feeds to work. It's a difficult problem because I can't reproduce it at all, and I can't easily "remote-debug" the problem since most of my users are very non-technical. So far the only thing I can tell for certain is that it seems to be network-related, not browser-related, as I have had bug reports from people using Firefox, Chrome, Safari, and Edge. I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible. I just don't know what the exact problem is yet so I'm feeling around in the dark.
So, I'm trying solutions. I don't think(?) I have a TURN server set up but from what I have read, it seems like adding one certainly can't hurt, and could help with my situation.
I don't fully understand the entire WebRTC protocol or RFC 7118 (this stuff is really complicated!) or exactly what/where/how a TURN server fits into the bigger picture. It would help, right? A lot of Googling has led to no clear answers. Would love some help! Thank you!
WebRTC tries everything it can do to make a p2p connection, but there are times that it will fail. The turn server acts as a last resort so that the peers can both connect through the turn server. Obviously this is not a p2p connection, so there will be extra latency, and you will have to make sure that your turn server has enough bandwidth to cover all of the connections you expect.
TL;DR, If you need 100% connection rates, you should have a turn server.
I believe AWS has a ready made instance you can spin up, or if you could use this open source coturn server https://github.com/coturn/coturn
On a debugging note... Check your ice candidates type. You should see host and srflx if you only have a STUN server, but if you have a TURN server you will also see relay. You can replicate this issue by discarding the ice candidates that have host and srflx types.
I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible
That is websocket. The media traffic runs over UDP typically and mediasoup uses random ports. A TURN server which is configured on udp port 443 may help in some cases.
The other problem is UDP being blocked which is easy to reproduce with a local firewall.. Mediasoup supports something called ice-tcp which will allow media to run over a TCP connection. You should check if your mediasoup installation uses ice-tcp. If it does not, a TURN server with TURN/TCP will help.
I'm trying to transmit data in UDP datagrams into a client in external location to a pc in my local lan.
But my network is over a ADSL modem sending to a pc with Slackware, this pc redirect packages into other pcs.
I'm using socat to redirect UDP:
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
In LAN the conection is fine, but external IPs don't work.
Somebody help?
I don't think socat is the culprit, however consider to use stone instead of socat, because using a fork() for each received packet is a bit weird. Stone is called in your case like this (I think):
stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udp
Now why external IPs perhaps do not work. Sadly your text does not tell much about your setup, so I have to guess:
It depends on your firewall/modem/router if it is able to forward UDP packets. Usually, if you initiate the UDP requests from the inside, the router will open a NAT connection, which often means, that not only the source IP of the packets change, but the source port as well. As UDP is connectionless, UDP NAT connections usually time out very quickly, say after 5 minutes, if no data is transferred on them.
If the UDP must be opened in the opposite direction (from Internet to Intranet), the router usually discards all the UDP packets coming in from Internet, because it does not know where to forward them to. A router cannot just choose some arbitrary machine, this would be a security hole. So in the "Internet connecting to a machine behind the router" you must open the UDP port on the router and let it forward to the right machine. In that case packets sent from your internal machine will get their source IP and the source port rewritten, the machine on the Internet always will see the packets as coming from your router. So except for the additional rule in the router this case is the same as the outgoing case.
Note that there are several different ways how to make NAT (symmetric, etc.) and several methods on how to open a port on the router (Config, UPnP, etc.) so the ways to poke some holes into it always depends on your hardware capabilities. This all cannot be answered here.
Some other ideas what might go wrong as well:
Some UDP protocols encode IP addresses within the payload. In that case it is not enough just to forward the packets, you must change the payload as well to correct the IP addresses exchanged to enable all machines to talk together. Such UDP protocols are badly designed, anyway, because you never should assume that two arbitrary machines can directly talk with each other, so all good protocols should support easy proxying.
Some ISPs filter certain UDP ports, for arbitrary reason. If you have problems talking from Internet to your DSL, try with two external machines directly connected to different ISPs. If these can talk via UDP check if you can talk from your Intranet to one of the external machines. If this still works, this means, that you can talk backwards as well, as usually UDP is not a directed protocol, but if there is some NAT involved you somehow must make sure that the communication ports stay open.
Mobile Internet plans often do not support P2P. This probably means, those plans do not support Internet at all, as IP, by definition, is P2P. What the ISPs really want to say with "no P2P" is (my guess), that connections from Internet to the mobile device are not supported. In that case you always must initiate a connection from the mobile device, so you cannot use push methods (Internet to Mobile), the mobile device always must pull (data from Internet). Some broadband/cable providers might do the same. Usually you can see this if your ISP hands out an IP in the 10.x.y.z range to you.
There might be another trick how to get the connection working:
Ask your ISP to get some IPv6. Perhaps use 6to4. With IPv6 you eliminate NAT completely, your local LAN then directly interconnects to the Internet on IPv6. Be sure to activate your firewall/iptables on your Intranet host on the IPv6 interface, else you might see Intruders very quickly.
HTH
Well I decided to try make a proxy checker, like Charion or Elite proxy checker. These programs accept large lists of proxies in the IP:PORT format, ping them tell you the response time
see the screenshot of Elite Proxy Checker, im trying to make a simplified version of this program. http://i52.tinypic.com/a57slh.jpg
I investigated and made my checker using Ping.SendAsync(ip, timeout, ip) method.
It was only afterwards that I discovered that you can only Ping IP's using this method, not the ports as well.
Ive spent a few hours trying to find the correct class/methods in order to be able to ping ports, reading different forum posts from experts they say its impossible to ping ports only IPS, can only use sockets to try open a connection with the port.
However, I have seen programs that people have coded in VB.NET that ping in the IP:PORT format, ie lets you choose timeout, tells timeout, etc.
My question is , what classes methods should I be using to do this ?
Im pretty sure its not sockets... theyve got to be pinging the individual ports as well somehow.
Any help would be appreciated.
Cheers,
(I code for a hobby, im not a pro, so sorry if I make glaring errors)
Have a look at tcpping, here is the Windows version:
http://www.elifulkerson.com/projects/tcping.php
Apologies if this is a dumb question, I've limited network knowledge.
If I sent a string to port 80 on UDP, would the server / receiving IP log it? I'm pretty sure it wouldn't in access logs, but what about firewall logs?
This is far too general question, thus I'll give a general answer.
In general that would be up to the particular server in use. That is your UDP "Listener" might or might not log incoming traffic as per configuration/settings.
Same applies for your firewall.
It really depends on what kind of organization you're trying to portscan for your "art project". If you're targeting a government entity, or Fortune 500 (in which case assume you're going to be prosecuted theft of resources in a court with no understanding of technology) you should assume there will be an intrusion detection system sniffing the network and logging all traffic out of the ordinary.
However if you set up a Windows desktop out of the box, it's not going to log UDP access to closed ports.