Unlock the Power of Nftables: Mastering Destination Network Address Translation (DNAT)

Поділитися
Вставка
  • Опубліковано 30 січ 2025

КОМЕНТАРІ • 8

  • @rickpoeling6831
    @rickpoeling6831 Рік тому +3

    Another great video on nftables!

  • @familytamelo8140
    @familytamelo8140 4 місяці тому

    Thanks!

  • @hornickt
    @hornickt 21 день тому

    Thank you for all the great content.
    It would be really nice, to have a list of all your commands (nft, conntrack etc) or config files in the nftables playlist. For me this could be very helpful.

    • @LinuxCloudHacks
      @LinuxCloudHacks  17 днів тому +1

      Thanks! That was my bad. I should have create a github repo and have a text version for those who prefer reading. Will keep that in mind next time.

  • @dpi3
    @dpi3 7 місяців тому

    your diagrams do help a lot!
    i think your .conf for firewall at 13:15 was pretty misleading for a beginner like me, in order for the firewall to act as a router, we need to first to the DNAT and then do SNAT as well. you didn't show us the SNAT part but still somehow your conf worked.
    for me (and hopefully everyone else) only this is working for obvious reasons:
    flush ruleset
    table ip nat {
    chain prerouting {
    type nat hook prerouting priority -100; policy accept;
    iifname "eth0" tcp dport 80 dnat to 192.168.1.80:8080
    }
    chain postrouting {
    type nat hook postrouting priority 100; policy accept;
    oifname "eth0" masquerade
    }
    }

    • @LinuxCloudHacks
      @LinuxCloudHacks  7 місяців тому +2

      I'm glad you liked the video!
      To your comment - for DNAT to work you don't need SNAT.
      Of course usually you see SNAT for the hosts on the inside to be able to reach Internet but for pure DNAT you don't need SNAT.
      Let's try to analyse it.
      1) On the public side, the external customer can reach our public IP. In our case both firewall and client are on the same 192.168.10.0/24 subnet so they have direct reachability. In real world scenario the traffic would go via multiple routers but still using public IPs.
      2) One the traffic reaches the firewall (192.168.10.230:80), the destination IP gets updated to the IP of the server on inside (192.168.12.231:8080). The source IP remains the same (it's still the public IP). In our case it's 192.168.10.231. In real case scenario it would be a true public IP like 1.2.3.4 etc. and not RFC1918 IP.
      3) Firewall forwards the packet to the internal server (192.168.12.231:8080) as it has this network directly connected.
      4) The internal server will try to reply. It knows nothing about the public IP the traffic originated from so it will send the reply back to the default gateway (that's the firewall).
      5) Firewall will swap the source IP 192.168.12.231 with it's public IP (192.168.10.230) and send the reply back to the client. This step is handled by DNAT. It does not require SNAT rule.
      Important thing is the servers on the inside need to have firewall set as the default gateway.
      To your point. If you would try to ping the client (public IP) from the server (private IP) it won't work without SNAT. You are absolutely right. However client (public IP) can reach the server (private IP) due to DNAT.
      Please let me know if that makes sense and thank you for the comment!