I am trying to my own coturn (TURN) server. I want it to run on port 443. I have Apache already running on that port. Can i use Apache proxy pass to run TURN on port 3479, 53499 but still listening to port 443?
I am not sure how to go about this problem. Is my approach wrong?. If yes, whats the better approach
listening-port=3478
alt-listening-port=3479
tls-listening-port=5349
alt-tls-listening-port=5350
#stening-port=80
#tls-listening-port=443
listening-ip=127.0.0.1
relay-ip=127.0.0.1
external-ip=*****
realm=explain.bookmane.in
server-name=explain.bookmane.in
lt-cred-mech
userdb=/etc/turnuserdb.conf
Apparently, the latest version of COTURN, COTURN 4.5.2r3, recently released this year, and still marked as unstable, has just incorporated support for reverse proxy. I infer this from description I found in its config file: /etc/turnserver.conf
https://github.com/coturn/coturn/blob/master/examples/etc/turnserver.conf
This is what it says:
# Some network setups will require using a TCP reverse proxy in front
# of the STUN server. If the proxy port option is set a single listener
# is started on the given port that accepts connections using the
# haproxy proxy protocol v2.
# (https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
#
#tcp-proxy-port=5555"
I am running a FreeSWITCH server on a public domain. I am able to make call from my browser(WebRTC with sipjs) to the FreeSWITCH server from a direct Internet connection.
I am testing it on a Firewall that allows only TCP on port 443. I am running a separate TURN server. I am trying to connect from my browser by specifying TURN server with credentials. I am unable to make it work. PeerConnection is getting closed.
FreeSWTICH server is NOT behind Firewall
Client(browser) is behind Firewall
TURN server is available
Is there any configuration I have to do either in FreeSWITCH server or in the client end(javascript) to make it work?
You need to open UDP ports, cause signalling will go via WSS and media via UDP ports:
mod_sofia to serve SIP signaling via WSS and media via SRTP/DTLS.
https://www.packtpub.com/books/content/configuring-freeswitch-webrtc
Yes, you can use a TURN server. You will have to configure it to listen on port 443 with TCP, because by default a TURN server listens on port 3478.
However, if the Firewall checks for a TLS connection (i.e. for HTTPS), you will have to configure the TURN server as a TURNS (TURN over TLS).
I am looking for a program to reroute windows domain resolution lookup through a socks proxy capable with many internet browsers and internet proxies.
So far in Control Panel, Local Area Connection 1, TCP/IP Properties, I use the following DNS server addresses, preferred DNS Server, I put 127.0.0.1 and use the default in-built port request 53.
I am reading that it is possible to forward this. I can not find a program to forward it through socks 4/5. I think this is possible because Socks supports UDP.
Has anyone come up with the answer to a solution about a UDP-to-socks forwarding program capable and adapted for socks and windows DNS.
It's really quite easy to configure.
You could write your own server and set the server to listen to incoming calls to port 53 or use this program
http://dns2socks.sourceforge.net
here my sample configuration for a socks server running on 1050 and TCP / IP settings on 127.0.0.1
DNS2SOCKS.exe /la:socks.log 127.0.0.1:1050 8.8.8.8:53 127.0.0.1:53
For such a program you can have a look at dnsadblock. Their free daemon/cli app opens up a proxy server that can be configured to use a proxy/socks to communicate with the upstream server. It works since the remote endpoint listens on https which makes DOH (dns over https) possible. Config options/install instructions: https://knowledgebase.dnsadblock.com/how-to-install-and-configure-our-software/
We recently installed a sonic firewall on our network. We have a SQL 2005 express server that's configured to listen on dynamic ports. In its configuration manager the dynamic port number is set as 1067 with its default port still 1433.
From my understanding we need to have the following ports open for it to work:
Tcp 1433
Tcp 1067
Udp 1434
Problem is we still cannot connect to the server from outside. When we switch off/disconnect the firewall we can can access the server.
This tells me that the SQL server's setup is fine and the that the problem must be some port we are missing on the firewall.
Any ideas?
Issue netstat -an from an MS-DOS command and try to find what are all ports opend as given in the artilce at
http://support.microsoft.com/kb/287932
and configuring SQL 2005 to allow connections at
http://support.microsoft.com/kb/914277
these may help according those articles:
Client-Server Communication Over a Firewall
Setting up a client to communicate to a SQL Server over a firewall is a simple three-step process:
Make SQL Server listen on a specific port on TCP (the default is 1433) or RPC (the default is a random port greater than 1023). You have to cycle the server after this change.
Configure your firewall server to allow traffic on the specific .
Make the client (on the other side of firewall) use the appropriate connection string to talk to the on the server. You can also use the Client Configuration Utility to add an "Advanced" entry with the appropriate Net-Library and connection string.
At my workplace, the traffic blocker/firewall has been getting progressively worse. I can't connect to my home machine on port 22, and lack of ssh access makes me sad. I was previously able to use SSH by moving it to port 5050, but I think some recent filters now treat this traffic as IM and redirect it through another proxy, maybe. That's my best guess; in any case, my ssh connections now terminate before I get to log in.
These days I've been using Ajaxterm over HTTPS, as port 443 is still unmolested, but this is far from ideal. (Sucky terminal emulation, lack of port forwarding, my browser leaks memory at an amazing rate...) I tried setting up mod_proxy_connect on top of mod_ssl, with the idea that I could send a CONNECT localhost:22 HTTP/1.1 request through HTTPS, and then I'd be all set. Sadly, this seems to not work; the HTTPS connection works, up until I finish sending my request; then SSL craps out. It appears as though mod_proxy_connect takes over the whole connection instead of continuing to pipe through mod_ssl, confusing the heck out of the HTTPS client.
Is there a way to get this to work? I don't want to do this over plain HTTP, for several reasons:
Leaving a big fat open proxy like that just stinks
A big fat open proxy is not good over HTTPS either, but with authentication required it feels fine to me
HTTP goes through a proxy -- I'm not too concerned about my traffic being sniffed, as it's ssh that'll be going "plaintext" through the tunnel -- but it's a lot more likely to be mangled than HTTPS, which fundamentally cannot be proxied
Requirements:
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
I have or can write a simple port forwarder client that runs under Windows (or Cygwin)
Edit
DAG: Tunnelling SSH over HTTP(S) has been pointed out to me, but it doesn't help: at the end of the article, they mention Bug 29744 - CONNECT does not work over existing SSL connection preventing tunnelling over HTTPS, exactly the problem I was running into. At this point, I am probably looking at some CGI script, but I don't want to list that as a requirement if there's better solutions available.
Find out why the company has such a restrictive policy. It might be for a good reason.
If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.
To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.
If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECT to port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but then you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.
You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.
Try a rule like this:
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 443 -j REDIRECT --to-port 22
Where 111.111.111.111 is your office computer's ip address.
That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.
Documentation for iptables is at http://www.netfilter.org.
Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)
Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.
I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.
Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.
How about using 2 IP adresses on your machine?
Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?
Could you set up a middle man?
Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.
It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.
I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?
Proxy tunnel may be your answer
http://proxytunnel.sourceforge.net/
lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37
I would add this to my local ssh config
Host host.domain.tld
ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p
ProtocolKeepAlives 30
See:
SSH Through or Over Proxy
http://daniel.haxx.se/docs/sshproxy.html
http://www.agroman.net/corkscrew/
Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.
See http://chm.duquesne.free.fr/blog/?p=281 for details.
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
Is it possible to bind your HTTPS server to a different port? Depending on what it's used for, you may even be able to get around the problem of not being able to directly access it from work by just SSHing home and then using lynx from there.
So, then, give proxifier a try (- it supports HTTP Proxy Server)!
http://www.proxifier.com/documentation/intro.htm
I managed to bypass my company's firewall using the following design via AjaxTerm, it works for me.
PC on company network --> company's proxy via https --> INTERNET --> My home Apache reverse proxy server on SSL + .htpasswd protection --> AjaxTerm Server(From here on ward, I can SSH to any other servers ).
Still not the perfect world... would be good if I can can tunneling to my home network via HTTPS.