iptables redirect port to another port

iptables: redirect трафика на другой порт

Добрый день. Суть вопроса: нужно перенаправить трафик от одного конкретного хоста с одного порта на другой (форвардить трафик куда-то дальше не нужно, нужно только принять его именно от этого хоста на нестандартном порту). Я прописал правило:

Причем видно, что через правило редиректа какие-то пакеты проходят.

Список правил таблицы filter:

В /proc/net/nf_conntrack я вообще не вижу пакетов с udp:162 (то бишь snmp-trap’ов).

В tcpdump пакеты попадают до netfilter’а, поэтому там ты увидишь только трафик на порт 162.

Попробуй поднять простой udp-сервер:

У редиректа ( в отличии от DNAT) адрес назначения обычно переписывется на адрес интерфейса с которого принят пакет. Если слушается определенный адрес с этим портом, то редиректить нужно через DNAT

вместо простого udp-сервера есть небольшое приложение на Java, которое слушает указанный адрес:порт. И после редиректа до приложения ничего не доходит. Если руками сгенерить трап на нужный порт, то приложение его обработает

То есть если пакет пришел на интерфейс 1.2.3.4, то после редиректа адрес назначения остается так же 1.2.3.4, только порт другой? я это учитывал, пробовал слушать и 1.2.3.4:10150, и 0.0.0.0:10150

Попробовал переписать правило через DNAT:

По прежнему пакеты до приложения не доходят, счетчик увеличивается, приложение слушает 195.122.226.31:10150 udp

Для DNAT надо и SNAT в обратную сторону, иначе не работает

Для DNAT надо и SNAT в обратную сторону, иначе не работает

Нет, не надо. connection tracking для этого есть.

Может, само приложение не может обработать приходящий трафик? В /proc/net/nf_conntrack точно ничего нет? Записи про udp хранятся 30 секунд по дефолту.

ну если все так плохо, то используй TRACE

а зачем в обратную сторону? пакеты представляют собой SNMP-трапы и идут только в одну сторону

iptables видит все, а мимо «-j TRACE» вообще никакой ipv4/ipv6 пакет не проскочит, жаль только, что в логи пишется дофига и на нагруженных системах пользоваться им нужно очень аккуратно.

-i eth2.2 указал, потому что трапы изначально на него слали. слать трапы на другой интерфейс додумался после того, как взглянул на таблицу маршрутизации 🙂

Источник

Iptables: немного о действии REDIRECT, его ограничениях и области применения

Данная заметка повествует о действии REDIRECT в iptables, его ограничениях и области применения.

Iptables и REDIRECT

Действие REDIRECT предназначено для перенаправления пакетов с одного набора портов на другой внутри одной системы, не выходя за пределы хоста.

Работает REDIRECT только в цепочках PREROUTING и OUTPUT таблицы nat. Таким образом, область применения сводится только к перенаправлению с одного порта на другой. Чаще всего это используется для прозрачного прокси, когда клиент из локальной сети коннектится на 80 порт, а шлюз редиректит пакеты на локальный порт прокси:

Допустим, надо сменить порт приложения только перенаправлением при помощи iptables, не трогая настроек демона. Пусть новый порт будет 5555, а порт приложения 22. Таким образом, надо сделать редирект с порта 5555 на 22.

REDIRECT и удаленный клиент

Первый шаг очевиден и будет таким же, что и в примере выше:

Однако, правило будет работать только для внешних клиентов и только при открытом порте приложения.

REDIRECT и локальный клиент

Предыдущее правило для самого хоста с iptables не сработает, т.к. пакеты с localhost не попадают в таблицу nat. Чтобы кейс сработал на локальной машине — надо добавить редирект в цепочку OUTPUT таблицы nat:

Теперь локальный клиент тоже может подключиться по 5555 порту.

REDIRECT и закрытый порт

Смысл кейса в том, чтобы использовать левый порт, а порт приложения держать закрытым, но если выполнить DROP правило в INPUT цепочке по 22 порту, то 5555 тоже перестанет отвечать. Собственно, хитрость в том, чтобы открыть порт приложения в INPUT цепочке, а дропать его в mangle:

Полный набор правил

Редирект с сетевым и локальным доступом при закрытом порте приложения:

Источник

Linux iptables: Port Redirection Example

H ow do I redirect 80 port to 8123 using iptables?

You can easily redirect incoming traffic by inserting rules into PREROUTING chain of the nat table. You can set destination port using the REDIRECT target.

Syntax

Replace eth0 with your actual interface name. The following syntax match for source and destination ips:

Examples:

The following example redirects TCP port 25 to port 2525:

In this example all incoming traffic on port 80 redirect to port 8123

Quoting from the iptables man page:

The OUTPUT chain example:

How Do I View NAT Rules?

Type the following command:

How Do I Save NAT Redirect Rules?

Type the following command:

References:

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Comments on this entry are closed.

Just came across this one.Never tried but good idea.

gotta love this site.

thanks for the 1000th time 😉

Please check my query and update me if it is possible by iptables or any other software…

I have 2 application servers (i.e. A and B)

A ip is :- 192.168.11.22 and port :- 7013 (single lan card)

B ip is :- 10.10.10.22 and port :- 8014 (single lan card)

and can we pass one machine traffic to other which are on internet via port redirection….?

Thank you! I always forget how to redirect

Well heck. I thought this was my answer but adding the iptables rule to redirect outbound port 25 traffic to port 2525 has no effect. (Ubuntu 10.04)

Mixmaster is giving me cat fits because ISPs have decided that we are not allowed to send RFC compliant e-mail any more. Ever. No matter what. Any suggestions?

How about redirecting an internal request to go out over a different interface.

I got bond0 and wlan0.

The request for a specific server let’s call it foobar on port 443. I always want to go out over wlan0 and never over bond0.

God bless you. I’ve been looking for these!

all connections are being redirected to the proxy … Why, if it is set different from the 172.16.0.0/12 and those connections I’m also going through the proxy

Thanks, this was very helpful 🙂

Hi, I’ve got a quite funny setup. I connect with ssh to server1 and establish a tunnel. Packets are generated I mark the packets on the OUTPUT chain and redirect them with ip route through a vpn gateway. This works fine.

But I want to redirect the port from 80 to 3028 and this does not work on the output chain. The rule is ignored. How can I redirect the port on the Postrouting chain?

Can you do it without iptables?

every packet arriving to port 25 will be forward to 2525, but what happens to packets arriving to port 2525? I would like to redirect them to 25, should I also add this rule?

I am trying to redirect request on port 80 to 8080 (as tomcat is listening on this);

Following are the rules I added;

But, I am unable to see the tomcat page when I hit http://xxx.xx.xx.xx/ from outside.

But, my question is why do I also need to expose port 8080. Because, that way http://xxx.xx.xx.xx:8080/ and http://xxx.xx.xx.xx/ would both work.

could someone help me with a better solution in this regard.

As last thing, don’t worry about how scary and difficult iptables can seem as everything I’ve told you I’ve learned this afternoon just by googling around and the good old trial and error 😉
Good luck

I need to access from any to the addresses 192.168.200.2 Port 3390 and redirect to Port 3389 to (RDP)
My firewall is disabled

Is there a way to redirect only the allowed traffic to a specific port?
Either I am able to redirect or drop but not both of them together.

doesn’t make the config persistent, that just dumps out the running config. You’ll need to backup

/etc/sysconfig/iptables then run

to make the running config persistent accross reboots

Источник

Проброс и перенаправление портов в iptables

Проброс трафика за NAT или проброс трафика на другой сервер

Чаще всего проброс трафика используется, если мы находимся в локальной сети и от внешнего мира отделены шлюзом. Для того, чтобы открыть доступ для локальных служб (ssh, web, ftp), нам необходимо пробросить порты. Поскольку в качестве шлюза мы будем использовать сервер на Linux, то осуществлять данные действия будем с помощью iptables.

Определимся с переменными, которые будут использоваться в статье:

Проброс портов

Рассмотрим пример

Если входящий пакет пришёл извне на шлюз (1.2.3.4), но предназначен веб-серверу (порт 80), то адрес назначения подменяется на локальный адрес 192.168.1.50. И впоследствии маршрутизатор передаст пакет в локальную сеть.

Дальше принимается решение о маршрутизации. В результате пакет пойдёт по цепочке FORWARD таблицы filter, поэтому в неё надо добавить разрешающее правило. Оно может выглядеть, например, так:

Рассмотрим пример

Пропустить пакет, который пришёл на внешний интерфейс, уходит с внутреннего интерфейса и предназначен веб-серверу (192.168.1.50:80) локальной сети.

Есть два способа избежать данной ситуации.

Рассмотрим пример

Если пакет предназначен веб-серверу, то обратный адрес клиента заменяется на внутренний адрес шлюза.
Этим мы гарантируем, что ответный пакет пойдёт через шлюз.

Надо дополнительно отметить, что это правило важно только для внутренних клиентов. Ответ внешним клиентам пойдёт через шлюз в любом случае.

Но, пока что, для нормальной работы этого недостаточно. Предположим, что в качестве клиента выступает сам шлюз.
В соответствии с нашими предыдущими правилами он будет гонять трафик от себя к себе и представлять исходящие пакеты транзитными.

Рассмотрим пример

Теперь для удобства запилим скрипт, чтобы не прописывать правила каждый раз вручную.

rules.sh

Теперь, чтобы обеспечить доступ извне к локальному FTP по адресу 192.168.1.52, достаточно набрать в консоли от имени супер-пользователя:

Перенаправление портов

Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту.

Набор правил для iptables будет отличаться несущественно, поэтому приведу сразу пример итогового скрипта для ленивых.

Источник

Jensd’s I/O buffer

random technotes…

Forward a TCP port to another IP or port using NAT with Iptables

Besides using NAT for accessing the internet with multiple machines using a single IP address, there are many other uses of NAT. One of them is to forward all traffic that is sent to a certain TCP port to another host. In practice, this technique can be used to test a service on a new host without adjusting anything on the client. The users or the clients do not need to be pointed to a new machine in order to test it. When the test would be unsuccessful, removing the NAT-rule is all it takes to switch back.

Since most major distributions switched to nftables instead, I decided to rewrite this article completely. Debian has nftables since Debian 10 (Buster) and CentOS and RHEL since version 8. Ubuntu also very recently, since 20.10 (Groovy Gorilla), moved to nftables. You can find the new version here: https://jensd.be/1086/linux/forward-a-tcp-port-to-another-ip-or-port-using-nat-with-nftables

If you are interested, I also created a YouTube video from this blogpost. If you prefer classic text, you can just follow the rest of this article:

Theoretical explanation

To above scenario is better known as port forwarding and it allows you to forward an incoming packet to another destination. That destination can be another port or IP-address. With the scheme under here, I will try to make things a little more visual and explain how port forwarding works:

The left part of the scheme shows the original situation: the client connects to service A, running on server A (ip: 10.1.1.1). Incoming packets come through service A on server A and the outgoing packets go back to the original source IP, client A. The goal of the NAT-setup is to forward the traffic to service A running on server B (ip:10.2.2.2) without any modifications to client A. Our new setup needs to be transparent for the client.

The right part of the scheme shows our goal: the client still connects to TCP port 9999 to the IP of server A (10.1.1.1) so nothing changed on that side. As soon as a TCP packet with destination port 9999 arrives at server A, it should be forwarded to server B (ip: 10.2.2.2). Before redirecting the TCP-packet to the other machine, the packet needs to be modified so that it get’s sent back to server A before sending back to the original host.

To completely understand this process, we need to take a deeper look into how Iptables works. When a packet passes through Iptables, it passes a set of chains. Decisions made by those chains are called rules and that’s basically how you configure Iptables.

Overview of the chains used by Iptables

For our setup to work, we need to add a DNAT and SNAT rule (Prerouting and Postrouting). The first one will make sure that the packet gets routed to the other host (ip: 10.2.2.2) and the second one will make sure that the source address of the packet is no longer the original one but the one of the machine who performed the NAT. That way, the packet will be sent back to it’s original source via the host which owns ip 10.1.1.1.

Firewalld

Since CentOS or RHEL 7, iptables has been “replaced” with firewalld. And while you can realize the scenario with firewalld, I will use the classic iptables. To use iptables instead of firewalld on CentOS 7 or RHEL 7, you can find more information in this post.

Preparations

The next steps prepare the system and iptables for NAT. Most commands can be used on CentOS, RHEL and Debian in exactly the same way. If there are some differences, I mention them (so if nothing special is mentioned, the commands are interchangeable).

IP forwarding

NAT uses IP forwarding and by default it’s not enabled in the kernel parameters. First we need to check if IP forwarding is enabled and if it’s not, we need to enable it.

To check if IP forwarding is enabled:

The above outputs shows that IP forwarding is not enabled.

To enable IP forwarding persistently (survives a reboot):

To activate the changes immediately:

Iptables

The next thing to do is to check if Iptables is running on the system. Iptables is running as a kernel module so it can’t be seen as one of the normal processes.

If there is no output, it means that Iptables isn’t loaded.

Now that we are sure that Iptables is active on the system, we can check which rules are active.

For the INPUT, FORWARD and OUTPUT-chains:

For the NAT-related chains:

As you can see, at this moment, no rules are configured and all traffic is allowed to and from the system without doing anything NAT-related.

In case you already have some rules configured, it’s a good idea (in a testing environment) to flush the current rules:

Enable port forwarding

After going trough the above steps, we’re ready to active the port forwarding. As an example, I will forward the TCP port 9999 of host 192.168.202.103 to TCP port 80 on host 192.168.202.105.

First I will check that nothing is actually listening on port 9999 of host 192.168.202.103 by doing a telnet to port 9999 on that machine:

$ telnet 192.168.202.103 9999
Trying 192.168.202.103…
telnet: Unable to connect to remote host: Connection refused

To be sure that something is listening at port 80 of host 192.168.202.105, where I want to get forwarded, I can do the same check:

As you can see, there is a webserver running on port 80 on host 192.168.202.105.

Now, to forward port 9999 on host 192.168.202.103 to port 80 on host 192.168.202.105, we need to add the following rules to the iptables configuration of host 192.168.202.103:

To test if my NAT-rule is working, I will repeat the test with telnet:

To permanently save the rules, execute iptables-save

18 thoughts on “ Forward a TCP port to another IP or port using NAT with Iptables ”

Great article, I followed this article and was able to get all my mysql traffic forwarded to a second server from the 10.1.x.x subnet. However my forwarding server has 2 nics. How to achieve this on a centOS 5.11 server with 2 NICs one with 192.168.1.10 as IP and the other with 10.1.1.10 as IP. and the mysql server at 10.2.1.10? I need to do this because people from out side use putty to establish a connection via 192.168.1.10

Because by the following rule,

You overwrite source IP of client. And server won’t be able to detect client IP.

How we can receive client IP as source on SERVER 2?

You started with great examples using IPs above and then went off and used completely different IPs in your examples. The post makes sense as you have it but would have been even clearer using your initial IPs form the diagrams.

Kudos for the clear and well made article! Exactly what I was looking for and well explained by providing the right examples.

Thanks – This was useful
You may need to add a FORWARD rule if your default is to drop forwarded packets, with the source as the originating network, and the destination as Server B with the port as Server B’s listening port. (I needed to do this, anyway.)

In the example above the originating network shows a completely different source network. This locks forwarding down to packets that originate *only* from that network, which is fine.

It would be helpful if you add topic on “How to delete iptable rules”

Источник