I am trying to setup NFTables to forward traffic coming in on a specific UDP port to another server with a different IP address. However, it appears my masquerade rule isn't working. When I send packets to this specific UDP port, it attempts to forward the traffic, but it doesn't change the source IP to the forwarding server's IP address. To my understanding, this should happen with a masquerade rule. Though, even an SNAT rule didn't work.
Here's TCPDump output showing what the issue is:
01:04:12.437619 fe:00:02:b8:34:ff > 56:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <ForwardIP>.27015: UDP, length 9
01:04:12.437657 56:00:02:b8:34:ff > fe:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <DestIP>.27015: UDP, length 9
01:04:14.145003 fe:00:02:b8:34:ff > 56:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <ForwardIP>.27015: UDP, length 9
01:04:14.145051 56:00:02:b8:34:ff > fe:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <DestIP>.27015: UDP, length 9
I want it to look like this:
01:04:12.437619 fe:00:02:b8:34:ff > 56:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <ForwardIP>.27015: UDP, length 9
01:04:12.437657 56:00:02:b8:34:ff > fe:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <ForwardIP>.7130 > <DestIP>.27015: UDP, length 9
01:04:14.145003 fe:00:02:b8:34:ff > 56:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <MyIP>.7130 > <ForwardIP>.27015: UDP, length 9
01:04:14.145051 56:00:02:b8:34:ff > fe:00:02:b8:34:ff, ethertype IPv4 (0x0800), length 51: <ForwardIP>.7130 > <DestIP>.27015: UDP, length 9
Here's how my current NFTables is setup:
root@forwardtest:~# nft list tables
table ip compressor_forward
root@forwardtest:~# nft list table compressor_forward -a
table ip compressor_forward { # handle 1
chain prerouting { # handle 15
type nat hook prerouting priority dstnat; policy accept;
udp dport 27015 dnat to 149.28.45.245 # handle 17
}
chain postrouting { # handle 16
type nat hook postrouting priority srcnat; policy accept;
masquerade random # handle 18
}
}
I've tried removing the random
NAT flag along with adding the persistent
NAT flag. I do need the random
NAT flag for my case. Adding/removing the flags didn't make a difference, though.
IPv4 forwarding is also set:
root@forwardtest:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
IPTables (NAT) should also be removed. Here are some commands I've ran:
root@forwardtest:~# rmmod iptable_nat
rmmod: ERROR: Module iptable_nat is not currently loaded
root@forwardtest:~# lsmod | grep "iptable"
root@forwardtest:~# lsmod | grep "nft"
nft_masq 16384 1
nft_nat 16384 1
nft_chain_nat 16384 2
nf_nat 40960 3 nft_nat,nft_masq,nft_chain_nat
nf_conntrack 139264 3 nf_nat,nft_nat,nft_masq
nf_tables 135168 8 nft_nat,nft_masq,nft_chain_nat
root@forwardtest:~# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
root@forwardtest:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Please keep in mind lsmod | grep "iptable"
returned nothing. I've also tried creating the postrouting
chain with priority 1, but that made no difference.
The forwarding server is running Ubuntu 20.04 LTS
on kernel 5.4.0-26-generic
.
Is there anything I am missing in this case? With that said, I am new to NFTables. Therefore, I apologize if I am missing something obvious.
If you need additional information, please let me know!
Any help is highly appreciated!
Thank you for your time.
I resolved this issue. I upgraded the forwarding server's kernel from
5.4.0-26-generic
to5.6.11-050611-generic
and it started working correctly. With that said, I did try restarting the forwarding server while on the older kernel and the issue continued after the restart. Therefore, I do believe the kernel was actually the issue here.Definitely a strange issue. I will setup another test server soon running on
5.4.0-26-generic
to confirm.Thank you!