I am trying to set up a STUN/TURN server on my local computer for a webrtc application of me. I decided to use coturn. Note that my server is running behind a NAT.
So i fired up my Ubuntu VM and installed it. After reading through the wiki I got it working, atleast on my local network. For testing purposes, i use this site. Therefore, when i try it there with 192.168.178.25:3478, it works. When i try it with "public-ip":3478, it doesnt.
This told me, it is working locally and it should be a port/NAT issue. What i did:
1) I set the VM to Bridging
2) I opened the port 3478 on my router. To test if this is really working, i used telnet on a remote machine and it worked. Another test was that i set up a quick apache server on my local machine on port 3478 and it could be accessed from the outside. This told me that there is, or should be, not port/NAT issue and my turn server should be working.
Any ideas?
I am running my server with the following command:
"sudo turnserver -X "public-ip" -listening-port=3478 -v
The turnserver.conf looks something like this:
fingerprint
realm="myRealm"
lt-cred-mech
user=test:test
As telnet and apache server are both working, i am pretty sure i have a configuration issue. I basically spent the weekend trying and im really lost on what could be wrong.
Thanks for any help!
From the documentation of turnserver
-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X ", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used.
So, it is not enough that you expose only the listening port from the inside LAN to the public network but all ports that you are going to use to relay. Please, note what is said in the same documentation:
--min-port <port> Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port <port> Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
You should choose a range of ports in the server, configure with them the options --min-port and --max-port and create a NAT rule to expose those ports to the public side of the router without change.
Related
I need to access company's internal network without using their OPENVPN server directly (My ISP blocks it). So I used an instance with a public IP, where my company is located, and have configured a OPENVPN client then used it to connect to the company's OPENVPN server.
(public IP instance) ===OPENVPN===> (Company)
Now, I need to achieve a further thing, which is working from my local machine by using VPN over SSH tunnel using sshuttle, such that the topology becomes:
(local) ===SSHUTTLE===> (public IP instance) ===OPENVPN===> (Company)
Note that public IP instance has two network adapters; eth0 (it has public IP) and tun0 (which belongs to OPENVPN)
I installed sshuttle, and tested the next command:
sshuttle --dns -r <user>#<public IP instance address> 0.0.0.0/0
It says connected after then but I still cant access anything. I tested dig and it returned results showing addresses of company's internal services. However, I still can't ping them. I tested using traceroute and it stops at some point after displaying some hops.
One important point is that I can't ping the tun0 address (on public ip instance) from my local machine.
I suspect that I need to add some routes on the intermediate public IP instance, but I am not sure.
I would appreciate any help
Thanks in advance
your setup is right but your assumptions are wrong.
Initially, check that your vpn is working fine on the jump box , if linux just check
route -n
Wrong assumptions:
sshuttle will route your dig commands , sshutle only route TCP and DNS queries are UDP
using --dns in your sshuttle meanless as you wont gain dns of vpn but of the jump box and that wont work
you should add the DNS of local vpn in your /etc/resolv.conf with target domain for local discovery
like : < call tech support to provide you with right DNS , you can find it in vpn log on jump box
search companydomain.internal
nameserver 10.x.y.z
its better to split the traffic and only target your company CIDR over sshuttle , most of them use parts of 10.0.0.0/8 instead of all traffic 0.0.0.0/0
important note: that may be your company block egress traffic to the internet over VPN access
Just a bit of background first.
I have installed coturn server in my local machine (Behind a firewall and with local IP).
I have created a port forwarding for cotrun server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478.
When I use some online utility to check my public IP has this port open it? that utility shows that it is open.
I am trying to test this server using this fiddle: Code to test TURN server
I removed the stun configuration from it, and added my live ip and port. And when I try to test it, it says your TURN server is broken in console on web browser. And I see failed as output.
I have also used following commands to create a user from this link.
Wiki to Coturn Configuration
// created test user
sudo turnadmin -a -u test -r test -p test
// enabling admin support in web (not sure how to access it in browser)
sudo turnadmin -A -u test -p test
I start the turn server using following command:
turnserver -L 192.168.0.11 -a -f -v -X -r test
I have enabled the "TURNSERVER_ENABLED"
/etc/default/coturn
TURNSERVER_ENABLED=1
Screenshot of my about:webrtc:
Please find the below attached Screen shot for my about:webrtc. I am not sure what is missing.
EDIT-1
I can also see the incoming packet message processed, error 401: Unauthorized in the console of TURN server
EDIT-2
I resolved the TURN server related issue, added the turn server in client code as well, still facing issue, call is not going through,
Update
Here is what I found, the reason why it wasn't working earlier was due to a defective router in the network. This thing has harassed me for almost a month (however the internet used to work fine). But I found that there is a loss of packets and I switch to LAN cable I even avoided the firewall of the organization and there it was working just fine. Then I configured the rules in firewall and it started working as well.
A few issues that might be causing this:
The -X option requires an argument - the external IP if the TURN server is behind a NAT.
If you are setting all your parameters on the command line, you should include -n to ensure that it does not load an unrelated configuration file.
TURNSERVER_ENABLED=1 is to start turnserver with default configuration at system boot. You do not want this if you are starting turnserver manually from the command line.
https://github.com/coturn/coturn/blob/master/README.turnserver
" I have created a port forwarding for CoTurn server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478."
Now surely you are aware that the private address-spaces in IPV4 are (private IP ranges):
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
So, your first IP is in the last private IP range, and your so-called "public IP" is in the first private IP-range. Now you need to find your TRUE REAL public-IP address to try to connect to it from outside. I would say that it looks like your ISP has you behind a NAT. So your TURN server might be behind two NATs. Which is kind of ironic situation for a server designed to help penetrate NATs of webRTC-clients. You might want to try to put CoTurn somewhere where it is possible for it to work like AWS (special case of CoTurn friendly NAT).
Just recently got (well with lots of help -- that even did the most of the work) CoTurn to work in cloud and on local Ubuntu ;-) (never stopped me from bragging though). Though there is troubling few srflx-call-successes yet (mostly local network or relay(TURN) calls). :-D
I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.
It's not that much of a question, rather a confirmation that what I did is right or not and if it is safe or not.
Until now what I have found googling around is that you cannot run rtorrent through a proxy. You can either put the http request through a proxy, or tsocks, in both cases either the actual transfers are done directly or not done at all. Therefore until now the only proposed viable solution is a VPN which I wanted to avoid.
What I did was use an http proxy for the http part and a port forwarding for the actual download part. For example, lets assume the following:
192.168.1.10 --> Local machine with the actual rtorrent
remote.machine.com --> The remote machine used as a proxy
Procedure:
I created 2 ssh tunnels
ssh -N -D 9090 user#remote.machine.com
ssh -R 9091:localhost:9091 user#remote.machine.com
From the local machine I installed polipo as the html proxy and configured it to use a socks proxy in the remote.machine.com.
I edited the following lines in /etc/polipo/config so that I can get the socks proxy.
socksParentProxy = "localhost:9090"
socksProxyType = socks5
I also changed the html proxy port for extra security, again in /etc/polipo/config
proxyPort = 9080
On the local machine I changed the ~/.rtorrent.rc as following:
#Proxy of the http requests through polipo
http_proxy=localhost:9080
# The ip address reported to the tracker.
#Really important, in order to get connections for downloads
ip = remote.machine.com
# The ip address the listening socket and outgoing connections is
# bound to.
bind = 192.168.1.10
# Port range to use for listening.
port_range = 9091-9091
# Start opening ports at a random position within the port range.
port_random = no
The system seems to work. I connect to the trackers and I have up and down traffic. So the questions are:
Am I safe that all the traffic concerning rtorrent is done through the remote.machine.com?
Did I miss something?
Are there any problems or concerns regarding this method?
As far as I see, you have covered inbound connections, as well as outgoing HTTP traffic, but any outbound peer-to-peer connections will be created directly, not through any tunnel. Currently, rtorrent does not appear to support passing outbound P2P connections through a tunnel or proxy of any kind, so in order to handle these, you'll need some other mechanism.
You mentioned tsocks and that it does not work – not even in addition to the rtorrent configuration you have set up above? (Although with tsocks you should be able to drop the HTTP proxy part.)
If that fails, there are alternatives to tsocks mentioned on the tsocks project page. A slightly more involved alternative would be to create a new loopback interface (lo:1 with IP 127.0.0.2), bind your rtorrent to that one and use something like sshuttle to direct all traffic originating on that interface through an SSH tunnel. Unfortunately, sshuttle doesn't let you restrict its operation to a specific interface at the moment, though, so you'd have to fiddle with the iptables rules it creates to make them match your needs. I assume a patch adding this feature to sshuttle would be welcome.
As a side note, you can create multiple port forwards and SOCKS proxies in a single SSH connection, like this:
ssh -N -D 9090 -R 0.0.0.0:9091:localhost:9091 myself#my.example.com
My question may be a little confusing, but anyway. My school is going to open up WiFi DMZ on separate IP for students, but they said port 80 will be the only port open.
What do I want? Well I want to tunnel my traffic thru my home server, which is running Apache2 on 80 and SSH on 21. It's just a regular setup. As it is a production machine and I want clients to be able to connect on port 80, but I want to connect to port 80 to make a tunnel. The question is: How to do that?
The possible sollution: Abandon possibility of connecting to websites running on the server from the school IP and use IPTABLES. If source ip == $school_ip && port == 80: Redirect to port 21. Done. But I think there must another, elegant sollution... Isn't it possible to actually use the HTTP transfer for SSH transit? I mean create a host named for example ssh.mydomain.tld and use some apache module to do a server-side redirection to port 21 but only on that particular hostname? What can I do?
Box is running Debian GNU/Linux
Thanks for any help...
Off topic: They think they will block any sort of illegal operation. In fact HTTP is probably the second most-vulnerable protocol after BitTorrent. Why don't lock it down too? It'll be absolutely safe if there's no open ports, wouldn't it? I don't personally think blocking ports for POP, IMAP, Jabber, etc is any good. I think they'll probably seriously piss someone off if they even can't open mail teacher sent them. Oh, there's a webmail? No no no! SSL/TLS goes on port 443, remember? I don't think blocking all the traffic will be any good. IMO they should block unencrypted BitTorrent and apply low-priority QoS for unclassified transfers.
You could try the instructions found here:
http://dag.wieers.com/howto/ssh-http-tunneling/
proxytunnel is available in the stable repo:
http://packages.debian.org/search?keywords=proxytunnel&searchon=names&suite=stable§ion=all
A simple and working solution is sslh.
It is exactly the tool to solve that problem.
BTW ssh is usually set on port 22.