Score:0

How do I forward all traffic arriving at a given port to another port?

gb flag

How do I forward all traffic arriving at a given port to another port?

Define the layout and the problem

The layout

Here is the layout of what I am trying to do...

+--------+         +---------------------+         +----------------+
|  WAN   |  <--->  | 6789                |         |                |
| Client |         |       Gateway       |         |      Host      |
|        |         |                4567 |  <--->  |  2345 Service  |
+--------+         +---------------------+         +----------------+

I want to transparently forward all traffic arriving on port 6789 to port 4567. The client on the WAN and the service on the host should know nothing about the gateway.

The gateway is Debian 10 with firewalld.

The problem

I am not able to get traffic arriving at port 6789 on the gateway to forward to port 4567.


The present setup

Step 01 - Expose the port on the firewall and confirm port is open.

Open the port on the gateway

  1. Run the firewall-cmd command: firewall-cmd --add-port=6789

  2. Check the firewall state...

root@gateway:~# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: etho0
  sources: 
  services: dhcpv6-client http https ssh
  ports: 6789/tcp
  protocols: 
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
  1. Confirm the port is open.
  • On the gateway, start a listener: nc -vvlp 6789 &
  • Confirm the listener is up...
root@gateway:~# netstat -tulnp | grep 6789
tcp        0      0 0.0.0.0:6789              0.0.0.0:*               LISTEN      2274/nc
  • From the client, attempt to reach the gateway:
client@client123:~$ nc -vvN gateway.example.org 6789
Connection to gateway.example.org 6789 port [tcp/*] succeeded!

Conclusion: Port 6789 is open on the firewall.

Clean up by killing the nc process on both the client and the gateway.

Step 02 - Confirm the connection between the gateway and the service on the host

root@gateway:~# telnet localhost 4567
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 backendhost.backendhost MyService (Debian/GNU)

Conclusion: The tunnel between the gateway and the service on the host is up.

Step 03 - Add the port forward on gateway and check the firewall state

root@gateway:~# firewall-cmd --add-forward-port=port=6789:proto=tcp:toport=4567`
root@gateway:~# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: etho0
  sources: 
  services: dhcpv6-client ssh
  ports: 6789/tcp
  protocols: 
  masquerade: no
  forward-ports: port=6789:proto=tcp:toport=4567:toaddr=
  source-ports: 
  icmp-blocks: 
  rich rules: 

Conclusion: The port forward is in the firewall.


At this point, if I try to telnet the host from the client, I get...

client@client123:~$ telnet gateway.example.org 6789
Trying <IP_of_gateway>...
telnet: Unable to connect to remote host: Connection refused

At this point, I am wanting to see what I saw in Step 02 above.

The Questions

Here is where I am not sure about...

When I run netstat -tulnp on the gateway, it does NOT show anything listening on port 6789. I do not expect it to since I do not have any service running that listens on port 6789.

Do I need some kind of service to listen on the 6789 port? If so, what? Or do I am missing something in the firewall settings? Do I need some kind of transparent proxy as is mentioned here?

I am not going to clutter this post with links to all the stuff I have read in the last couple of weeks, but if there is a post that has the answer, please feel free to point it out.

Edit

In response to @A.B

The host runs behind a firewall. When the host is started, it automatically creates a tunnel to the gateway using an SSH port forward.

Here is the command that the host runs at boot: ssh -N -R 4567:localhost:2345 [email protected]

That tunnel is up as confirmed in Step 02. And while I did not mention is earlier, the client works when it is on the same LAN as the host.

What I am struggling with is getting traffic arriving at the gateway to successfully be passed through to the host. The gateway is to be "transparent." The security certificate is held by the host and the client should think it is speaking directly to the host.

I am still trying to learn the terminologies, so if there is a more correct way to ask this question, I am certainly open to know what it is.

Michael Hampton avatar
cz flag
You need something listening on the 4567 port.
user371793 avatar
gb flag
@MichaelHampton - Thanks for your reply. On the host, there is an SSH port forward that is configured to automatically connect to the gateway. The port forward is connected and, from what I understand and show in Step 02, it is listening on port 4567. Or am I misunderstanding something about what you mean when you mention I "need something listening on the 4567 port"? Thanks again.
A.B avatar
cl flag
A.B
The vocabulary that should be used (and expected by people reading your question) is "forward to Host on port 2345", not "forward to port 4567". Some ports in your schematic appear as destination, others as source (or I didn't understand how to read the schematic). You'd have to clarify your question.
Michael Hampton avatar
cz flag
Let's get back to basics here. What is the point of changing the port using firewalld? You could just have your ssh port forwarding to listen directly on the port you wanted.
Score:0
gb flag

Thanks for the various comments.

There were two things I was missing...

  1. GatewayPorts in /etc/ssh/sshd_config needed to be changed from the default no to clientspecified
  2. The ssh command needed to be changed from listening on the loopback to listening on all addresses. The updated command is looks like this: ssh -N -R 0.0.0.0:4567:localhost:2345 [email protected] (Notice the 0.0.0.0: that was added in front of the 4567 port.)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.