My issue is a protocol that identifies terminals by it's sending IP. I want to manage the connections of several terminals to this server using some kind of proxy that implements that protocol.
So I have Terminal A which is identified by the server by the IP 1.2.3.4 and Terminal B which is identified by the server using the IP 5.6.7.8. Now the proxy will be in a local network with Terminal A and B.
When Terminal A wants to reach the server, it will query the proxy and the proxy needs to send the request on behalf of Terminal A using IP 1.2.3.4 to the server
When Terminal B wants to reach the server, it will query the proxy and the proxy needs to send the request on behalf of Terminal A using IP 5.6.7.8 to the server
Is it even possible to solve that issue in Java or do I have to do network voodoo on the router to achieve this?
Edit: to make things clear. I know what a network proxy is and what a router does. I also know how to solve my problem on a network level using advanced network voodoo if required. What I want to know is if my guess that the problem can't be solved using Java is correct. So the bottom line question is: can I use Java to send traffic using a specific network interface to which a specific IP has been assigned or do I have to rely on what the operating system does to route my traffic (in which case the advanced network voodoo would be required)?
Edit2: If routing of network traffic can be done in java, I'd just like a quick pointer where to look into. My own googling didn't return any useful results.
1) You already have some implementations for tcp tunelling with java. Below are some examples:
http://jtcpfwd.sourceforge.net/
http://sourceforge.net/projects/jttt/
2) Even with these existing implementations, you can still do you own by forwarding packets arriving in the proxy using java.net.Socket.
3) I still think that a better option would be a specific implementation using java.lang.Runtime.exec() and socat linux command. socat is just like the Netcat but with security and chrooting support and works over various protocols and through a files, pipes, devices, TCP sockets, Unix sockets, a client for SOCKS4, proxy CONNECT, or SSL etc. To redirect all port 80 conenctions to ip 202.54.1.5:
$ socat TCP-LISTEN:80,fork TCP:202.54.1.5:80
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 application which listens for commands over IP.
The program works fine locally but when I try to send the application commands with a remote address it won't connect.
Is there anyway to get around the router blocking the inbound network traffic?
I'm using JAVA
Thanks.
If this is a pair of hosts you control, you can open the incoming port. You might also
succeed using a tunneling program such as Hamachi to effectively set up a VPN linking
the hosts.
If you're talking about a pair of unrelated computers (for example trying to set up
a connection for a game) there's no general solution that doesn't involve installing
and trusting additional software. The usual solution is to use a public server and
relay the traffic between the end points.
I'm trying to get a BACNet scanner up on an Seimens server running the Apogee system with a BACNet interface. I've tried using BACNet4j put i get a port bind error on the LocalDevice object for test/Scan.java.
Does anyone know of any other libraries I could use or a reference to instructions for setting up a BACNet plugin to a building management system?
I have had the same problem before, i.e. the BACnet client needs to both send and receive from UDP port 47808. Since the BACnet server already uses that port to listen (and reply) my solution was to use a virtual IP (a bridge) so that my client runs on the same Ethernet card but with a different IP address. A bit convoluted, I know, but it works.
Whether or not the Apogee system supports virtual (or simply additional) network drivers is another question altogether. On my Linux and Windows machines I can run as many servers and clients as I need (I actually don't know what is the limit, I have run up to 5 servers and 3 clients without any problems).
Concerning the port bind error, you may have to configure your firewall because:
BACnet/IP is using UDP
the default port number is 47808 (0xBAC0)
Your issue might be the use of a (BACnet port #) socket that is already in-use; you have to ensure that it's not in exclusive-use - before binding to the socket, but also (slightly more) important, also ensure it's marked for reuse.
But unless you're listening for Who-Is broadcasts, I'd recommend listening for the (unicast) responses upon a different port #, e.g. 0xBAC1/47809, but still send upon the standard port # 0xBAC0/47808.
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.
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.