This question already has answers here:
How do I get the remote address of a client in servlet?
(11 answers)
Closed 3 years ago.
I am sending request from my machine to server. Ip address of my machine is 192.168.1.217.
At server side I am printing the client Ip address, but when I am printing Ip address with request.getRemoteAddr() I am getting it as 192.168.0.5.
When I am printing Ip address with request.getHeader("X-FORWARDED-FOR") I am getting it as null.
I am using apache tomcat server.
If that IP address (192.168.0.5) is the (or a) firewall, then it is the right IP address. Your server-side code is reporting the "client" IP address that it sees, and it can't do any better.
In general, there are a couple of possible explanations as to what is going on:
The firewall could be running an HTTP proxy, and your client machine could be configured send all HTTP requests through the proxy. If the client is capable of talking directly to the server, then you may be able to modify the client's proxy settings to treat the server as an exception.
The firewall could be providing a NAT service that is isolating one part of you networks from another part (for example). If this is the issue, then you will need your network administrators' help.
It is common (and often "good practice") to run a Tomcat server on (say) port 8080, and put it behind a reverse proxy on port 80.
In your case, the first explanation is most likely.
#andrucz suggests using the Tomcat Remote IP Filter. That will work in some circumstances, but not all, and it is using information that can easily be "spoofed"
The bottom line is that it is common for a webserver to not be able to see the real IP addresses of clients. So it is inadvisable to implement your services to depend on this.
You can use Tomcat Remote IP Filter: http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Remote_IP_Filter
Maybe you will need network administrators' help to configure firewall to include "X-Forwarded-For" header.
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 client-server setup. Where client connects to the server and asks which program to execute next. Server after getting a request checks for the hostname of the other end of the socket using below chunk of code which returns "127.0.0.1"
socket.getInetAddress().getCanonicalHostName();
After getting the program name the client creates a process which also tries to connect to the server but this time the above call returns different address. "mypc.foo.com" masking the domain name here
This behavior is bugging me as I am unable to lookup the hashmap where I store all the process details grouped by the machine ip.
Is it a bug in java lookup implementation or am I missing something. Please suggest some other way to do this lookup
I beleive socket.getInetAddress() returns your own address so basically always 127.0.0.1. Try using socket.getRemoteSocketAddress() - to get the other party's ip address.
Using IP address to match distinct users is generally a bad idea though. First of all they can be in some network or behind firewall and you can get requests from multiple clients coming from the same IP address. Also you are not guaranteed that it is static or dynamic IP. And also if your application is running in some strange network setup with strange routing you might end up getting all requests from the router IP address.
The better design would be to share some token between the server and the client and use that for identification. Does it sound familiar? For example http sessions are done like that ;)
I am developing a web application in Java by using RESTful web services and Tomcat. So far I was using the localhost in the URI: http://localhost:8080/3.ServerAPI/rest/Variable. But what if I want to use the real IP?
I have tried that on a local network by replacing the localhost with the LAN IP and it works fine: http://192.168.1.2:8080/3.ServerAPI/rest/Variable
The application at this address received the Variable.
If I want to send this through the internet as long as I know I have to use the WAN IP: http://188.39.25.247:8080/3.ServerAPI/rest/Variable
My question is, if I use the last URI with the WAN IP do I need also to port forward to the LAN IP by configuring the router or it is going to work like when I used the LAN IP ??
Thanks in advance
It depends on your network setup really.
You may have to enable port forwarding on your router to direct the request to the machine that your server is on, also make sure that the router allows connections to port 8080.
I had to do this recently when working with callbacks on external APIs. Seem to remember that I had to enable port forwarding on my router to get it to work. Wasn't too difficult though, just check router instructions on how to do it - like I say, depends on network setup though.
Hope this helps.
I've seen something similar to this and the problem was due to the port being used by another application.
This question already has answers here:
Connecting to a VPN without installation of client software
(3 answers)
Closed 8 years ago.
I am trying to write a client-server program in Java. There are a lot of working examples with using localhost as IP of the server. I am using VPN and running client and server codes on different computers in same network. But client can not connect to this server when I provide ip given after running VPN (such as 12.123.45.32). I generally get timeout error even if I set it to a large number. But if I use local IP such as 192.168.1.10, it works and connects.
I also wonder if there is a way for client and server to communicate with using server's public IP (without any VPN).
Any suggestions?
Thanks..
There is no problem in accessing a server through public ip or domain name. Only problem can be address renewal. Other than that you need to make sure the correct ports are forwarded in your router / firewall.
Are you using sockets or RMI?
Sockets shouldn't be a problem, but RMI require you to setup a SecurityManager or something like that. Honestly I have never gotten RMI to work over internet; I have stuck with sockets.
I wouldn't bother with VPN at all. Way too unstable imho. I only use VPN if I'm unable to setup company router for access.
I created a small chat program, that works flawlessly when client & server are run on the same computer (and probably network, too).
However, as soon as I try to connect to another computer over the internet, the socket connection simply times out.
Is this because of firewalls / routers, etc?
And how can I connect a ServerSocket & Socket over the internet?
However, as soon as I try to connect to another computer over the internet, the socket connection simply times out. Is this because of firewalls / routers, etc?
Yes, most likely. You're running into the NAT problem: essentially, the same externally visible IP address maps to many internally visible endpoints, and external endpoint doesn't know which internal endpoint to give your socket request to.
The easiest way around this is to have both your clients connect to a third party which both of them can see, and then have the third party mediate the communication. This is how most instant-messaging protocols work, for example.
If you have no way to control a third-party entity like that, an alternative to directly connect two clients is to have both clients open up an agreed-upon port, and then map communications on that port to their own internal endpoint. This provides the missing link that the externally visible endpoint (e.g. your home router) needs to deliver the communication to its intended destination.
If your server is behind a NAT router box (and most home computers are, especially if you use WiFi), then it won't be reachable from the outside unless you set up your router to port forward to that server.
What's the IP of your server computer? If it's 192.168.x.x or 10.x.x.x, then it's a non-routable address and can't be reached from outside.
Assuming with running on the same computer you mean that you tell the client the server is at 127.0.0.1 / localhost, it shouldn't be a problem in your code but because of firewalls or routers. If your server is behind a router performing masquerading (i.e., the server doesn't have a public but private IP address like 192.168.x.y for instance), you have to configure the router to pass a connection from the internet to the computer running the server.
Another reason why it doesn't work might be the way you bind your server to the interface. If you specify 127.0.0.1 there, the server will only listen for requests coming from the same system. If you don't specify an address, it will listen on all interfaces.
Edit Your comment indicates that you indeed have the NAT problem like others said. Configuring your router accordingly is probably the easiest solution.
First, test to see if it really works on a LAN; it sounds like you're just assuming it does.
If it works on your local network, perhaps it's failing because the server lacks a public IP, and is running behind a NAT'ing router.