Connecting to an RMI server that sits behind a firewall? - java

I know my RMI app works correctly - it works fine when the server is on localhost and inside the LAN but when connecting to an external RMI server it fails when trying to make stub calls
So the server is bound to localhost (an internal IP - 192.168.1.73) but the client is specifying an external IP (45.4.234.56) - which then gets forwarded to the internal server. How do you resolve this problem?
thanks

The "simplest" approach is for your network admin to add IP forwarding from a specific port on the firewall to your server.
Assuming this isn't an option (and it probably isn't), then RMI supports tunnelling over HTTP. The performance is poor, but it's much more firewall-friendly.
http://java.sun.com/javase/6/docs/technotes/guides/rmi/faq.html#firewallOut
This well-worn method is popular since
it requires almost no setup, and works
quite well in firewalled environments
which permit you to handle HTTP
through a proxy, but disallow regular
outbound TCP connections.
If Java RMI fails to make a normal (or
SOCKS) connection to the intended
server, and it notices that a HTTP
proxy server is configured, it will
attempt to tunnel Java RMI requests
through that proxy server, one at a
time.

Related

I can't connect to my dropwizard application remotely

I am able to succesfully use my dropwizard application when accessing with localhosts, but it doesnt work when I access with a different machine. Is there something you need to do make your web application respond to hosts besides localhosts?
I know with flask you must run with the flask run --host=0.0.0.0 is there a setting in the config file which controls this.
If you connect from the same network you´ll probably have an windows firewall issue (if you run on windows) or any other firewall depending on the OS.
You´ll have to allow inbound connections for the specific application on or port 80/443 TCP.
If you´re trying to connect from another network then it probably still is the above but you also have to setup port-forwarding to the machine running your application.
If it´s HTTP, probably port 80. If HTTPS then probably 443, for any other protocol you have to find out the correct port.
Since it´s dropwizard it´s probably HTTP/HTTPS, depending if it has to be secure (definatly recommended for REST APIs)

Java - Is there a way a client and a server can connect via IPv4 without port forwarding?

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.

Best way to tunnel RMI over HTTP

I'm looking for a secure way to tunnel RMI traffic.
In My application(java Webstart) i must assume that the only port that is open is port 80.
I have the looked att socketfactories for rmi but do i really need a proxy then.
I need to do all my tunneling on the client side.
The only firewall i am trying to get past is on the client side.
I'm not able to open 1099 with port ranges above.
Would be nice to see some implementations.
Thanks!
Port 1099 was reserved for RMI at IANA in about 1995. There is no reason for it not to be open for outbound access in the client-side firewall.
RMI can be made to use fixed port numbers by supplying a port number when constructing (super(port)) or exporting (exportObject(object, port)). Better still, if you create the Registry within the server JVM via LocateRegistry.createRegistry(), all subequently exported remote objects will use that port unless they specify a different port or they use a server socket factory.
BUT ... RMI already includes HTTP tunneling 'out of the box'. No external solution required. You have to deploy the RMI-Servlet provided with the JDK, at the server end.
(a)
although not the newest fashion, exposing remote services with Hessian and Burlap seems to be a simple solution to avoid problem working across firewalls: http://hessian.caucho.com/doc/
see sample code for the server and client side:
http://www.javatpoint.com/spring-remoting-by-hessian-example
(b) or consider using Spring HttpInvokder (see some sample code here: http://www.javatpoint.com/spring-remoting-by-http-invoker-example)
HttpInvokder provides more customization options through the RemoteInvocationFactory, RemoteInvocationExecutor and HttpInvokerRequestExecutor strategies (for example, to add custom context information (such as user credentials) to the remote invocation, or using java’s built-in object serialization etc.), see:
http://docs.spring.io/spring-framework/docs/2.0.x/api/org/springframework/remoting/support/RemoteInvocationFactory.html

Connect to http server behind vpn with java

I would like to connect to an REST Web Service through a VPN. Is there a way in Java to establish an pptp, l2tp ipsec connection to the VPN gateway an tunnel the HTTP request, without using the Operation System functions? This is important because I will connected to several rest services from a servlet. This Services could be behind different VPNs and I do not want to connect the network of the server with this VPNs.
Do anyone know about an API for that?
If you want to connect to a server behind a private VPN, from the outside, nothing you can do on you app can/will allow you to do connect. Unless you launch a VPN client and programmatically connect your network, to that VPN server, your java app will just sit there waiting for a socket on http connect.
Your question is technically incorrect (not from the SO point of view).
Look for a VPN client library that will pop up a dialog and take username/pwd.
A VPN has the purpose of connecting networks. If you want to reach another system via a VPN you will have to establish a network connection.
a Java API for all of this protocols will be (nearly) impossible, since VPN is handled by OS drivers and not on the application level (where java has its place) in most cases.
If you don't want to have your physical server being connected with those VPNs, you could perhaps set up a virtual system with virtualbox or vmware (or others) which handles all those connections and use it as a proxy. But this is no java issue than.
Here is a simple Java API that allows you to use Nord. I've made several bash scripts that also allow me to start, end and cycle NordIKE-VPN sessions. I have not used this yet, but I am intending on repurposing it for use with Android.
https://github.com/yaniferhaoui/NordVPN-Public-Java-API

Redirect a TCP connection

I have something like a proxy server (written in java) running between my clients and the actual video server (made in c++). Everything the clients send goes through this proxy and is then redirected to the server.
It is working fine, but I have some issues and think it would be better if I could make this proxy server only to listen to the clients requests and then somehow tell the server that a request has been made from the client side, and that it is supposed to create a connection with the client directly.
Basically in the TCP level what I want to happen is something like this:
1- whenever a client sends a SYN to my proxy, the proxy just sends a message to the real server telling the ip and port of the client.
2- The server would then send the corresponding SYN-ACK to the specified client creating a direct connection between client and server.
The proxy would then be just relaying the initial requests (but not the later data transfer) to the actual server. I just don't know if that is possible.
Thank you very much
Nelson R. Perez
That's very much the way some games (and Fog Creek CoPilot) do it, but it requires support on both the server and the client. Basically the proxy has to say to the client and server "try communicating with the directly on this ip and this port" and if they can't get through (because one or both is behind a NAT or firewall), they fall back to going through the proxy.
I found this good description of "peer to peer tcp hole punching" at http://www.brynosaurus.com/pub/net/p2pnat/
Does the proxy and server lives on the same machine? If so, you can pass the connection to the server using Socket Transfer or File Descriptor Passing. You can find examples in C here,
http://www.wsinnovations.com/softeng/articles/uds.html
If they are on the different machines, there is no way to pass connection to the server. However, it's possible to proxy the IP packets to server using VIP (Virtual IP). This is below socket so you have to use Link layer interface, like DLPI.
You don't have control of TCP handshake in userland like that. This is what firewalls/routers do but it all happens in the kernel. Take a look at the firewalling software for your platform - you might not even have to code anything.

Categories