Score:0

Server

iptables NAT REDIRECT

Dan Massameno

1/30/23, 3:10 PM

I have a server that is receiving syslog traffic. Many of my devices can only send to the default udp/514 port. My syslog server can't run on ports <1024 and is running on 5000. I have a nat PREROUTING REDIRECT on the system and it's working great.

I do have a few Aruba wireless controllers that I want to direct to a different port. I'm trying to redirect packets with source addreess 10.5.5.0/24 to port 5008. Here is the complete config.

*mangle
:PREROUTING ACCEPT [53851:21198923]
:INPUT ACCEPT [53851:21198923]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1227:8988526]
:POSTROUTING ACCEPT [1227:8988526]
COMMIT
# Completed on Thu Sep 30 14:52:43 2021
# Generated by iptables-save v1.8.4 on Thu Sep 30 14:52:43 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -s 10.5.5.0/24 -p udp -m udp --dport 514 -j REDIRECT --to-ports 5008
-A PREROUTING -p udp -m udp --dport 514 -j REDIRECT --to-ports 5000
COMMIT
# Completed on Thu Sep 30 14:52:43 2021
# Generated by iptables-save v1.8.4 on Thu Sep 30 14:52:43 2021
*filter
:INPUT ACCEPT [53852:21199096]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1234:8990186]
-A INPUT -s 10.0.0.0/8 -p udp -m udp --dport 514 -j ACCEPT
COMMIT

The redirect to udp/5000 is working great, but everything is getting redirected to 5000. The Aruba traffic from 10.5.5.0/24 is failing to get pushed to udp/5008.

If I issue the command: iptables -t nat -L -n -v --line-number . It confirms that zero bytes are hitting Line 1 and everything is hitting Line 2.

I figure the order is important and the more-specific line should be ahead of the generic line (as show above). I tried reversing them and it didn't help.

Syslog on UDP is unidirectional and stateless, so you would think this would be the easiest NAT in the world.

Has anyone done this kind of config? This is all on-box and I'm just trying to separate out my incoming Aruba syslog message from all my other messages.

Thanks!

278

0 + 0

nat

iptables

udp

redirect

parkamark

1/30/23, 4:18 PM

You probably need to flush out the conntrack rules in the kernel so they get re-created from the new iptables you've added. If the syslog traffic is consistent (as in packets are coming in within every 30 seconds or something, which is the default TTL for conntrack entries before they expire (tweakable via a kernel setting)), the older conntrack entries will remain active and so traffic will keep hitting the old port. See https://serverfault.com/questions/367626/delete-specific-conntrack-entries for a quick example of how to use conntrack.

Dan Massameno

1/30/23, 6:09 PM

My system doesn't have conntrack. What I did do is ```service iptables restart```. That clears the counters. Right now I'm assuming that also clears the connection table. It still doesn't work. No hits on the first line item. The syslog server still sees no packets arriving on udp/5008.

Tomek

2/1/23, 7:09 AM

Can you check with packet capture tool (like tcpdump or tshark) that you indeed are receiving traffic from 10.5.5.0/24 network to UDP port 514? Is the DESTINATION address correct? BTW, what is the INPUT rule for? It is superfluous.

Dan Massameno

2/1/23, 11:51 AM

@Tomek I used 'tcpdump udp -nnX port 514 and net 10.5.5.0/24' and yes, I am getting plenty of syslog packets in. The INPUT rule is there because I didn't realize the default condition to pass all traffic was in place and I was just trying anything to get this running. Please be kind and remember, I'm rather new to iptables. Thanks!

parkamark

2/1/23, 12:00 PM

"I'm assuming that also clears the connection table" - do not assume anything. These tools interact with different kernel sub-systems. Please, get the conntrack tool installed and run `conntrack -L` to view the NAT sessions that are currently being tracked. Use `conntrack -F` to flush the table completely. If this isn't possible, send the system for a reboot.

Dan Massameno

2/1/23, 8:24 PM

For the love of pete. That did it. `conntrack -L` confirmed the problem. `conntrack -F` solved the problem. I was making that assumption because of how dumb it would be that it needed a separate step. Does Linux want to destroy people’s lives? :-) Thank you for your help!

Score:0

Server

Hojii

1/30/23, 9:19 PM

Redirect port 514 to 5000 and make it work on local machine

If you are creating the iptables rule on your syslog server use below command:

iptables -t nat -A OUTPUT -o lo -p tcp --dport 514 -j REDIRECT --to-port 5000

iptables -A PREROUTING -t nat -i eth0<Incoming-interface> -p tcp --dport 514 -j REDIRECT --to-port 5000

redirect an incoming connection to a different IP address on a specific port

If you are trying to do port forwarding to another IP and your server(I called it firewall) which receiving UDP/514 is behind client and Syslog server like scenario on my github, you mus do iptables port forwarding with tree setp:

simple example scenario:

 | client:10.5.5.0/24 | -->   | 10.5.5.1:enp0s8 firewall enp0s3:192.168.2.1 | --> | 192.168.2.2:enp0s3 Syslog |

1- Enable IP forwarding

sudo sysctl -w net.ipv4.ip_forward=1

2- PREROUTING for the incoming traffic to the firewall

sudo iptables -t nat -A PREROUTING -d 10.5.5.1 -i enp0s8  -p tcp --dport 514 -j DNAT --to-destination 192.168.2.2:5000

3- POSTROUTING for the leaving traffic to Syslog server

sudo iptables -t nat -A POSTROUTING -o enp0s3 -p tcp --dport 514 -d 192.168.2.2 -j SNAT --to-source 192.168.2.1

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: iptables NAT REDIRECT

TH: iptables เปลี่ยนเส้นทาง NAT

RO: iptables NAT REDIRECT

RU: iptables ПЕРЕНАПРАВЛЕНИЕ NAT

VI: iptables NAT REDIRECT

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.