Using an NTP-server behind NAT, it works! After testing a lot. No not many routers/OS can handle it. Really not many

Yes, but you have PPPoE running over the VLAN on eth5. The PPPoE interface is what your external IP address is assigned to, and where your IP packets go in and out. Which is the layer we are interested in.

If you have multiple ports, then it is bridged. Might be HW-offloaded, i.e., a switch, but logically in OpenWrt, it is a bridge. The one that your LAN IP address is assigned to. The “lan” in “br-lan” is actually the logical “lan” zone that you have in your GUI.

I use 1 port WAN and 1 port LAN, all the rest isn’t used.
I use a Netgear 8 port hardware switch after it.

No HW-off-loading in the router.

→ eth5

But all the ports, whether used or not, are in your LAN. And that is commonly represented as bridge in a Linux system.

HW-offloading or no HW-offloading, on the logical level, which is what we are working with when working at the IP layer, it is a Linux bridge. All the Ethernet ports other than eth5 are “enslaved” to the bridge. E.g., that is why the IP address is on the bridge, not the interface that represents the physical port.

Wan is not eth5, that is just the cable, then eth5 does pppoe, but that is not the port either, as it’s routed via vlan10, so it must be this port: pppoe-wan

But the LAN port should be br-lan, as it shows the local-lan, but the cabling is connected to eth0

I hate this crap networking, it makes no sense.

People who invented this crap must have been on coke.

Even you can’t work it out. Since when has this all become so complicated?

That’s what I said.

Yes, but just as with your switch, all the ports are in the same subnet. The individual physical ports are represented as ethX interfaces. The fact that they are all in the same subnet, or broadcast domain, or LAN, is represented by the concept of a bridge. I mean, you mentioned the other day how you were doing networking stuff since the Internet was invented. Then you should know all those terms and concepts, e.g., what a bridge is (or nowadays mostly switches), and how it works/what it does.

Sorry, how is me explaining this stuff me not being able to work it out?

And it is not more or less complicated than it has ever been. The other day, you mentioned how familiar you are with this stuff, as you started working with Internet technologies since the beginning. This is just this basic Internet stuff: interfaces, broadcast domains (used to be on coax cable where even every unicast packet was broadcast to everyone on the cable, until switches came along), networking layers (physical/MAC, VLAN on top, PPPoE on top, IP on top of either of those), how forwarding at physical/MAC layer works and interacts with the IP layer, how forwarding at the IP layer works and is different from the physical/MAC layer, and how they are all represented in common devices, especially in Linux.

That is where I’m lost.

That new invented stuff simply sucks, it makes no sense.

Sorry I don’t get it. It was never this complicated.

Why don’t you just do the substitutions that I suggested, and then add the snipped to your router as @mlichvar suggested and described, and then we take it from there. Take it as a black box for now, then we can dissect it later, once it works.

Here we go, max speed is set as 3Gbit…

I have no problems..

You seem to forget I have just 100/35Mbit VDSL connection.

And I do run other services.

My home network doesn’t crash like other (shit) routers did.

Look at the connections, it’s near 100K…

800 Pks/sec More then enough. This is just a VDSL connection :rofl:

Not fiber, not datacenter etc…simple VDSL :+1:

This does not match most of the NTP traffic. So you have the impression that it works. Apparently it is mostly a no operation, this configuration does not disturb the stateful tracking of the NTP packet flow. When you change the source port with the destination port, the NTP traffic seems to be broken. But that is a good sign. You need similar rule for the reverse direction, and probably explicit allow rules, specifically including the reverse, outgoing direction. But, I do not know what handles the stateless DNAT rules, is it possible to configure with the GUI, or is it implicit, or you need to specify it in low level config as @mlichvar was already kind enough to provide earlier?

As Robert Palmer sang,

You like to think that you’re immune to the stuff
It’s closer to the truth to say you can’t get enough
You know you’re going to have to face it, you’re addicted to NAT

Thank you so much for the explanation, I’m testing the parts right now.

I have set in the /etc/nftables/90-stateless-ntp.nft

chain ntp_prerouting {
         type filter hook prerouting priority raw;
         iif pppoe-wan udp dport { 123 } ip daddr 185.142.225.68 ip daddr set 192.168.1.50 notrack
         iif br-lan udp sport { 123 } ip saddr 192.168.1.50 notrack
 }

 chain ntp_postrouting {
         type filter hook postrouting priority raw;
         oif pppoe-wan udp sport { 123 } ip saddr 192.168.1.50 ip saddr set 185.142.225.68
 }

and added the extra rule:

config rule
        option src 'wan'
        option dest 'lan'
        option dest_port '123'
        option proto 'udp'
        option target 'ACCEPT'
        option name 'NTP-notrack-with-extra-config'
        list dest_ip '192.168.1.50'
        option enabled '1'

It seems to stay low at <2500 conntrack’s, but the netspeed is set low, going to up it to 3Gbit to see if it works.

Again, thanks for pointing me in the right direction.

Wow, at last. Hope this wasn’t too difficult in the end.

As @mlichvar points out, don’t forget to drop the other rules that you added, the redirect one, and the various that you may have regarding notrack. Doesn’t impact the inbound stateless DNAT, but you might find other surprising side effects, such as your internal servers no longer being able to sync with external ones.

Made a mistake, but is corrected now.
It runs around 1150 connections.

I restarted chrony and checked incomming clients, works.
I checked the NTP-check-tool, works.
I checked the pages of my peers, works 377.

Traffic is building:

I will let it run for 1 hour or so, see what happened.

Oh man, if this solves it, then I’m over the moon of joy!
So much testing…

Fingers crossed. :crossed_fingers:

Ok it works. To summerize for others I use my system as example:

  1. Check ‘ip a’ :
root@OpenWrt:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
    link/ether 00:e2:69:9e:33:5e brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:e2:69:9e:33:5f brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:e2:69:9e:33:60 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:e2:69:9e:33:61 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:e2:69:9e:33:62 brd ff:ff:ff:ff:ff:ff
7: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:e2:69:9e:33:63 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e2:69ff:fe9e:3363/64 scope link 
       valid_lft forever preferred_lft forever
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:e2:69:9e:33:5e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fda9:9e:825d::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::2e2:69ff:fe9e:335e/64 scope link 
       valid_lft forever preferred_lft forever
9: eth5.10@eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:e2:69:9e:33:63 brd ff:ff:ff:ff:ff:ff
10: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc noqueue state UNKNOWN qlen 1024
    link/ppp 
    inet 185.142.225.68 peer 109.233.104.27/32 scope global pppoe-wan
       valid_lft forever preferred_lft forever
    inet6 fe80::888a:cb2d:40f0:c33f/128 scope link flags 02 
       valid_lft forever preferred_lft forever

My WAN-IP (public IP) is 185.142.225.68
My WAN-Adapter is pppoe-wan

My LAN-IP (of the NTP-server) is 192.168.1.50
My LAN-adapter is br-lan

Check your own config makes it so much easier to do.

  1. nano /etc/nftables.d/90-stateless-ntp.nft and copy the code in it:
chain ntp_prerouting {
         type filter hook prerouting priority raw;
         iif pppoe-wan udp dport { 123 } ip daddr 185.142.225.68 ip daddr set 192.168.1.50 notrack
         iif br-lan udp sport { 123 } ip saddr 192.168.1.50 notrack
 }

 chain ntp_postrouting {
         type filter hook postrouting priority raw;
         oif pppoe-wan udp sport { 123 } ip saddr 192.168.1.50 ip saddr set 185.142.225.68
 }

alter it to your settings and reboot the router.

  1. check Status → Firewall it should show this at the top:

  1. Make a rule Network → Firewall → Traffic → Add:

  1. check the rule in ‘cat /etc/config/firewall’ it should read:
config rule
	option src 'wan'
	option dest 'lan'
	option dest_port '123'
	option proto 'udp'
	option target 'ACCEPT'
	option name 'NTP-notrack-with-extra-config'
	list dest_ip '192.168.1.50'
	option enabled '1'
  1. change the firewall connection parameters, the default is too low, ‘nano /etc/sysctl.conf’ mine looks like this:
net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_udp_timeout=15
net.netfilter.nf_conntrack_udp_timeout_stream=180
net.netfilter.nf_flowtable_udp_timeout=15
net.netfilter.nf_conntrack_max=300000

activate with ‘sysctl -p’

  1. check the connections in the status window of OpenWRT, mine running with 3Gbit setting:

See traffic at >800 packages per second:

  1. Check if your incoming and outgoing still works. The Pool’s NTP-check is a good tool and should pass.

That’s it! Very major big thanks to @mlichvar who worked this out and explained it to me.

And sorry guy’s if I annoyed you, but I’m not a good firewall rule-writer.
I get there, in the end with some help. :+1:

I hope this helps others that may have the same problem when traffic goes high.

After more then 24 hours of testing I can only say, this works.
My network is still fast and NAT isn’t failing.

Thank you all for the help. I’m over the moon :grinning_face: