Differences

This shows you the differences between two versions of the page.

--- linux_router:nftables [2023-07-09 Sun wk27 11:39] – [Sample NFTables configuration] baumkp
+++ linux_router:nftables [2024-09-21 Sat wk38 20:29] (current) – [iptables] baumkp
@@ Line 1: / Line 1: @@
 {{tag>linux router NFtables firewall}}
 =====NFTables Configuration=====
 The best reference for nftables is at the dedicated wiki [[https://wiki.nftables.org/|wiki nftables]]. Some other references I found [[https://gist.github.com/wolfhechel/db7ed3be31feb104752e|nftables router]]. The reference at stosb is good, but not for a router [[https://stosb.com/blog/explaining-my-configs-nftables/|Explaining My Configs: nftables]].
@@ Line 7: / Line 6: @@
 Dont forget to ensure the router is allowed to forward packets:
-  * ''sudo sysctl net.ipv6.ip_forward'' to check
+  * ''sudo sysctl net.ipv4.ip_forward'' to check
-  * ''sudo sysctl net.ipv6.ip_forward=1'' to set or =0 turn off
+  * ''sudo sysctl net.ipv4.ip_forward=1'' to set or =0 turn off
   * ''sudo sysctl net.ipv6.conf.all.forwarding=1'' similar for ipv6
+====iptables====
+It is not a good idea to have both iptables and nftables rules setup at the same time.
+  *To check existing iptables rules: ''sudo iptables -S'', the output should be as follows, indicating no restrictions:
+<code text>-P INPUT ACCEPT
+-P FORWARD ACCEPT
+-P OUTPUT ACCEPT</code>
+  *The iptables rules can be flushed with ''sudo iptables -F''.
 ====Sample NFTables configuration====
@@ Line 247: / Line 254: @@
 <tab9><color blue>       # dnat - direct allowed by port number wan incoming services to correct lan server ip.</color>\\
 <tab9>       ip daddr <color red>$wan_ip4</color> tcp dport {http, https} counter dnat to <color red>$http_server</color> ++ | \\ + <color #202000/#F0F0E0> Incoming WAN packets to the http or https ports are preroute dnat to the webserver IP address.</color>++\\
-<tab9>       ip daddr <color red>$wan_ip4</color> tcp dport {pop3s, imaps, smtp} counter dnat to <color red>$mail_server</color> ++ | \\ + <color #202000/#F0F0E0> Incoming WAN packets to the mail ports, pop3s, imaps or smtp ports are preroute dnat to the mail server IP address.</color>++\\
+<tab9>       ip daddr <color red>$wan_ip4</color> tcp dport { pop3s, imaps, imap2, smtp, submission, submissions } counter dnat to <color red>$mail_server</color> ++ | \\ + <color #202000/#F0F0E0> Incoming WAN packets to the mail ports, pop3s, imaps or smtp ports are preroute dnat to the mail server IP address.</color>++\\
 <tab9>       ip daddr <color red>$wan_ip4</color> udp dport <color red>$vpn_port</color> counter dnat to <color red>$vpn_ip4</color>  ++ | \\ + <color #202000/#F0F0E0> Incoming WAN packets to the VPN port are preroute dnat to the VPN IP address.</color>++\\
 <tab6>    }\\
@@ Line 255: / Line 262: @@
 <tab9> \\
 <tab9><color blue>      #Allow internal clients to correctly see external address "hairpin dnat"</color>   ++ | \\ + <color #202000/#F0F0E0> Hairpin nat is dicussed in greater death at [[https://wiki.kptree.net/doku.php?id=linux_router:nftables#hairpin_nat|hairpin nat]].</color>++\\
-<tab9>       ip saddr <color red>$lan_ip4</color> ip daddr <color red>$http_server</color> tcp dport {http, https} counter snat <color red>$router_ip4</color>\\
+<tab9>       ip saddr <color red>$lan_ip4</color> ip daddr <color red>$http_server</color> tcp dport { http, https } counter snat <color red>$router_ip4</color>\\
-<tab9>       ip saddr <color red>$lan_ip4</color> ip daddr <color red>$mail_server</color> tcp dport {http, https, pop3s, imaps, smtp} counter snat <color red>$router_ip4</color>\\
+<tab9>       ip saddr <color red>$lan_ip4</color> ip daddr <color red>$mail_server</color> tcp dport { http, https, pop3s, imap2, imaps, smtp, submission, submissions } counter snat <color red>$router_ip4</color>\\
 <tab9>\\
 <tab9><color blue>      #Standard postrouting nat</color>  ++ | \\ + <color #202000/#F0F0E0> The examples below show different levels of granularity in control.</color>++\\
@@ Line 272: / Line 279: @@
 ++++
+++++mail server ports:|
+  * smtp {25} / (smtps) submissions {465} / submission {587} - (My mail server uses smtp / submission on ports 25 / 587 respectivily)
+  * imap {143} / imaps {993} - (My mail server uses starttls on port 143)
+  * pop3 {110} / pop3s {995} - who still uses pop3?
+''nft'' translates ports to service namesas defined in /etc/services
+++++
 ===Some configuration notes===
@@ Line 331: / Line 344: @@
 This only affects local networks that use NAT which is basically mandatory for IPv4 and not required for IPv6, hence unless NAT is used in a IPv6 local network hairpin.
-* Whilst investigating this matter commentary it was often stated that this problem is better solved using DNS. I was some what confused by SSL certificate DNS verification, and local DNS resolution.  Then there was all the talk about dual horizon or split DNS.  Basically the certificate authority uses WAN DNS to verify ownership of web site. I need to program my domain name suppliers DNS with the certificate info and this is used to verify my control ownership of the domain and allow issue of certificate to me.  My LAN DNS is effectively a split horizon in that LAN DNS server resolves my LAN addresses, all external address are ultimately pas to the WAN for resolution, although the results may be temporarily store locally to speed up subsequent DNS queries.  If my LAN servers have valid certificates and the LAN DNS addresses used are valid then it serves the secure service reliably off the LAN. Presumably it still needs to perform CA verification of the WAN, not sure about this.  The local DNS server cannot be directly addressed from the WAN.  If a WAN incoming service passes my WAN router firewall and is correctly directed directed to the LAN server and this server has a valid certificate then this will also function using the WAN address.  __A LAN DNS is definitely a more elegant method to serve local content than hairpin NAT!.__  This also explains why my NFTables hairpin NAT has always been showing no usage since I first experimented.  The LAN DNS makes it unnecessary. I have recently been using Traefik in a Docker container to act as my back-end server proxy and manager of certificates main and sub-domain wildcard.
+* Whilst investigating this matter's commentary it was often stated that this problem is better solved using DNS. I was some what confused by SSL certificate DNS verification, and local DNS resolution.  Then there was all the talk about dual horizon or split DNS.  Basically the certificate authority may use WAN DNS to verify ownership of web site. I need to program my domain name suppliers DNS with the certificate info and this is used to verify my control and ownership of the domain and allow issue of certificate to me.  My LAN DNS is effectively a split horizon in that LAN DNS server resolves my LAN addresses, all external address are ultimately passed to the WAN for resolution, although the results may be temporarily store locally to speed up subsequent DNS queries.  If my LAN servers have valid certificates and the LAN DNS addresses used are valid then it serves the secure service reliably off the LAN. Presumably it still needs to perform CA verification of the WAN, not sure about this.  The local DNS server cannot be directly addressed from the WAN.  If a WAN incoming service passes my WAN router firewall and is correctly directed directed to the LAN server and this server has a valid certificate then this will also function using the WAN address.  __A LAN DNS is definitely a more elegant method to serve local content than hairpin NAT!.__  This also explains why my NFTables hairpin NAT has always been showing no usage since I first experimented.  The LAN DNS makes it unnecessary. I have recently been using Traefik in a Docker container to act as my back-end server proxy and manager of certificates main and sub-domain wildcard.
 \\
 \\