| Both sides previous revision Previous revision Next revision | Previous revision |
| linux_router:nftables [2023-07-09 Sun wk27 11:14] – [Sample NFTables configuration] baumkp | linux_router:nftables [2023-11-05 Sun wk44 14:06] (current) – [NFTables Configuration] baumkp |
|---|
| |
| Dont forget to ensure the router is allowed to forward packets: | 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 | * ''sudo sysctl net.ipv6.conf.all.forwarding=1'' similar for ipv6 |
| ====Sample NFTables configuration==== | ====Sample NFTables configuration==== |
| <tab9> ip saddr @controllist counter drop\\ | <tab9> ip saddr @controllist counter drop\\ |
| <tab9>\\ | <tab9>\\ |
| <tab9><color blue> #limit the IP address range bandwidth using WAN</color> ++ | \\ +<color #202000/#F0F0E0> This is a simple form of traffic control. My DHCP / DNS place critical IP address in the 192.168.1.1 to 99 range, other equipment is automatically assigned in the 100-254 range. The chains below then limit traffic speed into / out of these IP addresses. This has been separately described in detail at the following link: [[linux_router:nftables_control#Limit Rate on IP Address Range]] </color> ++ \\ | <tab9><color blue> #limit the IP address range bandwidth using WAN</color> ++ | \\ +<color #202000/#F0F0E0> This is a simple form of traffic control. My DHCP / DNS place critical IP address in the 192.168.1.1 to 99 range, other equipment is automatically assigned in the 100-200 range. The chains below then limit traffic speed into / out of these IP addresses. This has been separately described in detail at the following link: [[linux_router:nftables_control#Limit Rate on IP Address Range]] </color> ++ \\ |
| <tab9> iifname <color red>$wan</color> ip daddr { 192.168.1.100-192.168.1.254 } limit rate over 1300kbytes/second burst 3000kbytes counter drop\\ | <tab9> iifname <color red>$wan</color> ip daddr { 192.168.1.100-192.168.1.200 } limit rate over 1300kbytes/second burst 3000kbytes counter drop\\ |
| <tab9> oifname <color red>$wan</color> ip saddr { 192.168.1.100-192.168.1.254 } limit rate over 750kbytes/second burst 1200kbytes counter drop\\ | <tab9> oifname <color red>$wan</color> ip saddr { 192.168.1.100-192.168.1.200 } limit rate over 750kbytes/second burst 1200kbytes counter drop\\ |
| <tab9>\\ | <tab9>\\ |
| <tab9> oifname <color red>$wan</color> tcp flags syn tcp option maxseg size set rt mtu <color blue> # This automatically set the tcp mtu</color>\\ | <tab9> oifname <color red>$wan</color> tcp flags syn tcp option maxseg size set rt mtu <color blue> # This automatically set the tcp mtu</color>\\ |
| <tab9><color blue> # dnat - direct allowed by port number wan incoming services to correct lan server ip.</color>\\ | <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 {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>++\\ | <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> }\\ | <tab6> }\\ |
| <tab9> \\ | <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><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>\\ |
| <tab9><color blue> #Standard postrouting nat</color> ++ | \\ + <color #202000/#F0F0E0> The examples below show different levels of granularity in control.</color>++\\ | <tab9><color blue> #Standard postrouting nat</color> ++ | \\ + <color #202000/#F0F0E0> The examples below show different levels of granularity in control.</color>++\\ |
| <tab9><color #000060/#F0F0FF> #oifname </color><color #060000/#FFF0F0>$modem</color><color #000060/#F0F0FF> counter masquerade #needed with dynamic wan ip address</color>\\ | <tab9><color #000060/#F0F0FF> #oifname </color><color #060000/#FFF0F0>$modem</color><color #000060/#F0F0FF> counter masquerade #needed with dynamic wan ip address</color>\\ |
| <tab9> ip saddr <color red>$lan_ip4</color> oifname <color red>$modem</color> counter snat <color red>$modem_ip</color>\\ | <tab9> ip saddr <color red>$lan_ip4</color> ip daddr <color red>$modem_ip4</color> counter snat <color red>$modem_ip</color>\\ |
| <tab9> ip saddr <color red>$vpn_ip</color> oifname <color red>$modem</color> counter snat <color red>$modem_ip</color>\\ | <tab9> ip saddr <color red>$vpn_ip</color> ip daddr <color red>$modem_ip4</color> counter snat <color red>$modem_ip</color>\\ |
| <tab9><color #000060/#F0F0FF> #oifname </color><color #060000/#FFF0F0>$wan</color><color #000060/#F0F0FF> counter masquerade #needed with dynamic wan ip address</color>\\ | <tab9><color #000060/#F0F0FF> #oifname </color><color #060000/#FFF0F0>$wan</color><color #000060/#F0F0FF> counter masquerade #needed with dynamic wan ip address</color>\\ |
| <tab9> ip saddr <color red>$lan_ip4</color> oifname <color red>$wan</color> counter snat <color red>$wan_ip4</color>\\ | <tab9> ip saddr <color red>$lan_ip4</color> oifname <color red>$wan</color> counter snat <color red>$wan_ip4</color>\\ |
| ++++ | ++++ |
| |
| | ++++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=== | ===Some configuration notes=== |
| |
| 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. | 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. |
| \\ | \\ |
| \\ | \\ |