1

I'm working on a setup that requires redirecting request coming on one of the server's port to other server's port in a NATed environment (example: all request coming on 192.168.1.100:843 should be redirected to 192.168.1.200:8443 - both servers are behind a dedicated firewall & communicate each other all ports.)

A service is running on server 192.168.1.200's port 8443. I've configured port-forwarding on server 192.168.1.100 via xinetd as follows.

service serv1
{
        bind            = 192.168.1.100
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 8443
}

Now when I'm doing telnet to 192.168.1.100 843 within LAN I'm able to connect the service on 192.168.1.200:8443

-> telnet 192.168.1.100 843
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.

But when I'm trying to connect via 192.168.1.100's public IP I'm getting "connection closed"

-> telnet 1.2.3.4 843
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
Connection closed by foreign host.

On doing tcpdump I found in later case request is not coming to server 192.168.1.200 itself.

I'm having similar setup working in one of our DC & its working fine. Any idea if anything could go wrong here.

Thanks, Meghanand

1
  • It's the firewall, which isn't expecting replies from 200 when it's NATting to 100.. at least that's my guess.
    – NickW
    Aug 1, 2014 at 10:13

2 Answers 2

1

Well upon further investigation I found it was getting blocked due to TCPWrappers After adding appropriate rules its working fine.

Following added to /etc/hosts.allow

serv1: ALL

Thanks

1

You need to remove the bind line, if you want it to be listening on all IPs assigned to the host.

That however can't be the full explanation to your problem. If that was the only mistake you made, connections to the other IP would get connection refused, and not an established connection followed by a disconnect.

Something else might be listening on the same port number on the other IP address. That might even be a different xinetd service. If you have another xinetd service, which looks similar to this, it could explain the problem:

service serv2
{
        bind            = 192.0.2.42
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 61868
}

Here the differences are that the other is listening on a different IP (but the same port number), and connecting to another port number, which is closed. If that's what you did, then connections to the other IP address would get an established connection, which xinetd has to close once it realizes, that the target port for the redirect is closed.

The last part is just guessing. If you run netstat -ntlpW, you should be able to see, what is really listening on that other IP.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .