RE: nftables and network traffic redirection
Hello TEAM!
I'd like to forward incoming PLCnext (FW 2020.0) packets on port 2000 to 172.16.5.2:80 (my WLAN5100)
My PC is 172.16.5.70
PLCnext is : 172.16.5.200
A wrote this command as Root but it doesn't work :
nft add table nat
nft add chain nat post { type nat hook postrouting priority 0 \; }
nft add chain nat pre { type nat hook prerouting priority 0 \; }
nft add rule nat post ip saddr 172.16.5.70/32 oif eth0 snat 172.16.5.200
nft add rule nat pre tcp dport 2000 dnat 172.16.5.2:80
Could someone tell me where I 'm wrong ?
Best greetings,
Fabrizio
Comments
Hi Fabrizio,
I have forked this out as a separate question, since the previous one was marked as "resolved". I hope that's OK.
Martin.
Dear All any news about m topic ?
Greetings
Fabrizio
Hello Fabrizio,
actually this is not a PLC issue but purely NFT if I understand correctly.
you can check your rules with "nft list ruleset" maybe the PLCnext Filters are interfering with your setup?
You want to completly forward the traffic through the PLC without Masquerading it?
I dont know why you source NAT the PC traffic?
Shouldnt you something like this do the trick?
--------
https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
% nft add rule nat prerouting iif eth0 tcp dport { 80, 443 } dnat 192.168.1.120
This redirects the incoming traffic for TCP ports 80 and 443 to 192.168.1.120.
----------
maybe I dont understand what you want to accomplish.
Should the PLC AND the FL WLAN get the packages to port 2000 ?
Maybe this helps?
https://wiki.nftables.org/wiki-nftables/index.php/Duplicating_packets
Hi,
no errors present, only little things missing. You masks the packets from your own PLC with the snat, so the connection from the PLC should work. But now you have to mask the connections that request the PLC from outside. The easiest way is to mask all outgoing traffic (for testing and playing). Then you can also leave out the snat.
I think it should work then.
What do you want to build?
Note:
To understand the routing from firewalls always look at the flow.
Hello GUYS and Thanks for your support,
I tested the two solution and finally I remove the snat , but nothing has changed,
here my new ruleset :
root@axcf2152:~# nft list ruleset
table ip nat {
chain pre {
type nat hook prerouting priority 0; policy accept;
tcp dport cisco-sccp dnat to 172.16.5.2:http
tcp dport 2001 dnat to 172.16.5.2:http
}
chain post {
type nat hook postrouting priority 0; policy accept;
masquerade
}
}
I rember before FW 2020 it was working.
Best greetings
Fabrizio
Hi colleagues,
I'm doing some test togheter with Fabrizio and I can confirm you that these rules are correctly working with FW 2019.3:
nft add table nat
nft add chain nat postrouting { type nat hook postrouting priority 100 \; }
nft add chain nat prerouting { type nat hook prerouting priority 0 \; }
nft add rule nat postrouting meta nftrace set 1 ip saddr 172.16.5.70/32 oif eth0 snat 172.16.5.200
nft add rule nat prerouting tcp dport 8081 dnat 172.16.5.2:80
nft add rule nat postrouting oif "eth0" masquerade
echo 1 > /proc/sys/net/ipv4/ip_forward
With these rules 2152 act as a router and apply port forwarding to traffic on port 8081 to the host 172.16.5.200 on port 80.
The same rules applied on FW 2020.0.1LTS are not working anymore.
I even noticed that with FW2019.3 ip_forward is set as standard to 0, meanwhile in 2020.0.1 seems to be always set to 1.
I think we need a better analysis to understand what changed and how can we solve
Davide
Hi,
working with FW 2020.0 (NFT Version 0.9). We should know the nftables version of the FW2019.3 It can make a difference if the version is < 0.7. Prerouting must always (almost always) have the highest priority.
You can try another way with docker. You have the possibility to install other firewall programs like iptables and the configuration help shorewall. Maby there are also configuration tools for nftables. Maybe something like Openwrt is interesting too.
table ip nat {chain prerouting {
type nat hook prerouting priority -100; policy accept;
tcp dport 2222 dnat to 192.168.224.36:http-alt
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname "eth0" masquerade
}
}
Hi Jan,
I tested FW2019.9 and the same rules are still working.
nft-version show that 2019.9 already use: v0.9.0 (Fearless Fosdick)
Docker could be an option, but not for our specific case...we'd like to implement port forwarding togheter with an APP on the Store (Ixon Connector) that seems to be able to remotly connect via VPN only the own host of PLC; using port forwarding we could try to reach other host on the same network, almost for the most important services.
Any other idea?{jcomments on}
Dear Jan,
Unfortunately I understood late your suggestions, and I 've to done many tests.
now it works, I confirm It's realy important the priority "-100" in the prerouting otherwise it doesn't work.
I used this nft rools table below:
#!/usr/sbin/nft -f
define ixon_v4 = 172.16.5.0/24
table ip ixon {
# chain ixon_forward {
# default forward policy is drop
# #type filter hook forward priority 100; policy accept;
# oif eth0 accept
# # accept any established connection traffic
# ct state established,related accept
#}
chain prerouting {
type nat hook prerouting priority -100; policy accept;
tcp dport 1999 dnat to 172.16.5.1:443 #mguard
tcp dport 2000 dnat to 172.16.5.2:80 #Wlan 5100
tcp dport 2001 dnat to 172.16.5.7:80 #FL Switch 2208
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oif eth0 masquerade #this is valid for local connections not for ixon
}
}
Now the AXCF2152 wth IXON client can reach other devices than itself !
We GOT IT ! I attached a gif showing right behaviuor.
Best Greetings
Fabrizio
Hi,
the subject has gone under with me, is it still topical?
G Jan