I want to access my raspberrypi from outside my local network, in particular using ssh. When I searched for answers, almost all mentioned port forwarding. My understanding is a little thin, but I think I have forwarded the port. Instead of the standard port 22 I use something like port 2222:
ssh -p 2222 bla#raspberrypi
This works locally, but it didn't work when I tried it outside, and I found that port 2222 is closed. My impression was that port forwarding was synonymous with "making the port available outside LAN". How do I actually open the port for outside access? Thanks in advance.
Go to your routers admin page, usualy at 192.168.1.1 (especaly cisco), sometimes is at 192.168.100.1. Another concern is that you have to have static ip from isp because there is a refresh rate which if you have the ip is resetting. You could open a port to the dynamic ip but it will be eventualy changed. I have tested this and it work until the ip changed.The default port is 22 but you could change it, here is a tutorial and explanation by Eli the Computer Guide. If you couldn`t port forward watch a tutorial on how to port forward on your router. I recommend because you have little knowledge in port forwarding that you should go with the default port.
Keep Hacking. Good Luck :) !
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.
I don't have a ton of experience with routers or port forwarding, but I do have a new Raspberry Pi and I wanted to see if I could set up a simple Hello World page just for educational purposes. I have quite a bit set up with apache2 already installed and the web page works great on my local area network, however I can't connect to it using my LTE from my phone, telling me this thing does not connect to the internet.
I am currently using Rasbian under all the default settings from the pi.
My router is an all in one modem and router, from xfinity. After sifting through countless sites trying to solve this issue, the following 2 were the closest thing to my particular issue. My reputation is not high enough to put more than 2 links, so I will put the most important ones..
So to the best of my knowledge this is the way to do it ...
1) Set the web server up to work locally
2) Then go into the router with the IPv4 or IPv6 (shouldn't matter which) and forward all Port 80 traffic to, say, Port 8080 where my PI 'should' be listening, then send back my web page down through Port 80 to the client calling the web page.
Under 10.0.0.1 I find this...
Then I go to 'Advanced'
I have tried from Start port 80 to End port 8080, which my 2 PI files I edited to listen for that port.
Those files are under
sudo nano /ect/apache2/sites-enabled-000-default.conf
and
sudo nano /ect/apache2/ports.conf
I changed
Listen 80
to
Listen 8080
and all other combinations alongside changing my router Start and End ports... none of which worked so I am lead to believe there is either a knowledge gap or I am doing something terribly wrong.
I just want to put a simply Raspberry pi web server online from my Local connection at home using a Comcast xfinity router. If anyone has any experience doing, I would seriously appreciate it, I've spent far too many hours trying to walk through this alone, so now I am reaching out to the faithful stackoverflow community.
It sounds like you are almost there.
For you to be able to access your raspberry pi server from the internet, you need to find your external ip address. Your router has one external ip address that you can reach from the internet. While on your wifi, search google for "what is my ip" Google may display it as the top result, or you might have to click into a site like ipchicken. Write this IP address down.
Next, setup your router to forward all port 80 (default http port). Try setting Apache to listen on port 80, and have your router set with start port and end port to be port 80 (this makes it so you don't have to put :port-number in the address, i.e. you will do http://your-ip-address rather than http://your-ip-address:8080). The start port is the port on the external network, the end is the port that your Apache server is running on the raspi.
It looks like your raspi has the ip address of 10.0.0.17 on your local network based on your screen shot. If it doesn't, change the IP address in the port forwarding section of the router configuration to be the IP address of your pi. You can figure out what the assigned IP address of your pi is through the router interface, or by typing ifconfig -a and looking for the ip address of the adapter that you're using to connect to the network. Your router may have the ability to assign a static ip address to your raspberry pi while it's connected to your network. It would say something like DHCP reservation. You'd need to find the MAC address of your pi. You can do that with ifconfig -a as well. Then configure your modem to always assign your pi the same ip address that you've configured in the port forwarding.
Now that everything is setup, switch to your cellular connection and then try to go to the ipaddress that Google gave you.
type your-ip in browser address bar -> port 80 request to your modem's IP -> you've set external port 80 requests to be forwarded to port 80 on your internal network for the device 10.0.0.17 -> your raspberry pi will serve the HTML
Note: The external ip address of your modem is most likely not static unless you specifically pay for a static address. This address usually will stay the same for at least a day though, so if you're just testing, it's not a big problem. In the future, if you want to ensure that you'll be able to reach your pi, look into dynamic dns.
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.
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.