I made a Java web application running on tomcat, what I'm trying to do now is letting people outside my net acceding my application.
I've read lot of guides and I understood I need to forward incoming traffic on port 80 to the raspberry hosting it (listening on port 8080).
What I did was going to the router panel and make a port forwarding with the following parameters:
Are all the parameters right?
What should i put in the remote IP address?
What I meant to do is redirecting request on port 80 to local port 8080 on which the raspberry is listening (if tomcat is listening to port 8080 if i write something like ip/webappname will I access my application?)
By the way, with the following settings, if I write my "outside" ip as url, I get prompted with a user\password form. I tried to make some tcpdump to try to understand if it's raspberry or router related, but I got tons of packets and couldn't find a way out, what could it be? Thanks.
Related
So I'm trying to connect two clients in a Java application, but in a way that one client acts as a server and other client acts as a ... client. I managed to connect them locally which works perfect, but I've been researching whether I can connect a client to a server that are not on a same network (via IPv4 or IPv6). I have read that I should do port forwarding on my router server-side. I know how to port forward, but shouldn't it be possible to do without port forwarding? If I understand correctly, only server-side should be port forwarded and the server can respond to the client without the need for the client to port forward their router? So if I'm correct, another solution would be a 'global' third party server(that is port forwarded) that would connect two clients by receiving and passing information from one client to another?
I'm just learning here, so I'm sorry if this has already been answered here but I haven't found answers to all of this in one place and I'm trying to come to a conclusion.
Yes, you can access a computer from outside the network and connect to a server
You must download the (ngrok) tool on the device that contains the server and run the tool
The client will contact the server without the need to forward the ports
ngrok
Explain the use of the tool on the site with a download link
shouldn't it be possible to do without port forwarding
Yes, you can make a connection between two machines without port-forwarding.
Example: Web servers
Take for example, web servers. By default a web server sits there listening on port 80, with 80 being the port assigned by convention for HTTP.
The web client (browser or such) sends a request by trying to connect on port 80. If there are no obstacles in the way, then the connection proceeds.
Restricted port access
However, there may be an obstacle.
One common obstacle: Unix-oriented operating systems (BSD, macOS, Solaris, Linux, AIX, etc.) by convention restrict access to ports numbered under 1,024 for security reasons. The operating system blocks any incoming connections on port 80. With that security blockage in place, the web request never reaches the server.
Port-forwarding with a packet-filter tool
One way to get past this restriction is to have the web server listen on an unrestricted port, a port numbered above 1,024, up to the 64K limit, such as 8080. Then configure the packet filter tool on the server machine’s OS to do port-forwarding. The incoming request for port 80 is altered to go to port 8080 instead.
A connection is then established between the web server and the web client.
The client thinks it is talking to the server on port 80.
The server thinks the client asked for port 8080.
With the packet filter tool in the middle altering packets on-the-fly, both server and client is none the wiser about packets being altered.
You may want to configure your firewall to allow HTTP connections from outside the machine only on 80, including blocking any external requests for 8080. In this case, only packets altered from 80 to 8080 will reach your web server. Common practice is to close as many ports as possible on a server.
FYI: For encrypted HTTP (HTTPS), the conventional port is 443 rather than 80.
Not a programming issue
Notice that there is no programming issue here. As the programmer, your client software should attempt to connect on the port number as documented for the server in which you are interested. On the server-side machine, or server-side router, port-forwarding will be configured as needed. Your client programming does not care about, or even know about, any port-forwarding that may or may not be in place. Port-forwarding is a network-admin issue, and should be transparent to the programmer.
See sister sites for networking issues
As a network-admin issue, look to the sister sites such as Server Fault and Network Engineering rather than Stack Overflow.
I have a simple java written client and server chat application(with sockets). When running on the same network/computer it works fine. However when i try to run the client from a different network it doesn't connect. I tried using the public IP address of the server to connect the client to the server but without luck. How would I be able to connect to the server app from a different network? any help would be appreciated.
It sounds like you have more of a firewall issue than a problem with the application. Instead of trying to connect with the Java client, first try connecting with Telnet to the server from the same computer, then from the other computer. The first effort will show you what to expect when it works. For instance, if your server is running on port 999, use telnet server.example.com 999.
If the machines are Linux boxes, use iptables -L to see whether there is a block on the port you are trying to access.
If you're still having problems reaching the server, run tcpdump -i tcp:999 on the server host to see what traffic is making it to your server socket, then run the telnet commands again. You should see the tcp connection established when connecting from the local machine, maybe or maybe not when connecting from other machines. If you don't see it while connecting from other machines, run tcpdump there too to make sure the client is definitely sending the traffic to the server.
After you are sure that the server can receive traffic and that your client is sending the traffic, there are no mysteries about what is actually going on and you should find your problem.
It worked after I did port forwarding on router. Most of the ISP provided modem/routers wont let you manipulate ports so had to buy my own modem/router, forwarded the port and worked like a charm. Information on what port forwarding is can be found here : http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/
I developed an application in my home machine. Now I want to show application that i made to client through WAN. I have TP-Link WiFi router at my home. Is it possible using port forwarding or other solution ?
Yes, you can use port forwarding to make your application accessible from the Internet. Essentially, what you want to do is redirect traffic coming into your public IP on port 80 to the internal machine running tomcat on port 8080.
There are public guides available for configuring port forwarding on different routers.
Edit: Port forwarding however might not be the only problem. There are other things to consider:
1. You should use a static external IP and map it to a DNS name, so users will be able to access the site by typing the name in the address bar.
2. You should make sure that the machine running tomcat allows external connections to port 8080, so these aren't blocked by the firewall.
I created a Battleship game in Java to work with Sockets and ServerSockets. The game works fine on LAN, but I would like to be able to play against someone on a completely different network. I understand port forwarding would be necessary, but would I have to forward the port on every client that is playing the game? Or would it only be necessary to forward the port on the router the server is using? Thanks.
Port forwarding is only required on the server. Any packets bound for the client will be auto-forwarded from the initial request thanks to the action on many NATs.
So, you only need to forward the port on the server. If using Socket and ServerSocket you need to forward TCP if your router gives you the choice. If using DatagramSockets, forward UDP at either of the endpoints.
(if you had to forward on clients, you most likely wouldn't have been reading this page without forwarding port 80)
To elaborate on what #hexafraction is saying, here's what you can do:
Build a server that any client can connect to. Clients can generally connect to anything they want. Firewalls usually place restrictions on information that can flow in, but not flow out. So if the clients know the server to connect to, they can connect to it without modifying their firewall and then the server will coordinate transferring the data between the clients.
I did this and all I had to do was forward the port I was using in my router to my local I.P. address. If you don't know your local ip address run a command prompt (assuming your using windows ) and run ipconfig to figure it out. If your at home using a wireless router access it by browser to 192.168.1.1 Hope this helps!
I am trying to communicate between an applet and a servlet. I first tried Http connection. But I am not getting the desired result. Hence decided to switch to socket communication. Hence I wanted to know which port to use for the same. I remember reading somewhere that port 80 is ideal. Is it port 80 or port 8080? I need a port that is not blocked by firewall(default).
By default, an Applet can only connect to the same host as the applet was served from. You can't set up TCP connections arbitrary hosts. (see e.g. here for info on how to sign an applet, signed applets does not have this restriction)
Using port 80 likely will not work either, as your web server probably works on port 80. Port 80 is really the only port that you usually can count not being blocked, if your servlet container is running on port 8080 , port 80 might be free for you to use though.
imo, try rather to communicate with http so you can talk to a servlet - and work out whatever desired results you had trouble with.