Hey there! Thank you for linking me to the new documentation. I was looking at the old documentation that just has a bunch of diagrams and I didn’t understand the packet flow from that. The new documentation explains it well.
Your reasoning behind the packet flow log I shared feels right and it also appears to be working just fine.
And thank you to everyone else for suggesting alternate solutions but I don’t really want to implement those. Even though I now announce router’s IP as a NTP server to all the connected clients, The clients still use time.windows.com, time.cloudflare.com, time.google.com, the pool.ntp.org service and apple probably uses their own thing. All this means, There are quite a few different IPs that are being contacted for NTP queries and tracking it down and adding routing entries for all those IPs will take a lot of time and that is if I am able to figure out all the addresses. All my network equipment(APs, Switches etc) are obeying/using the NTP server announced via DHCP but most client devices just seem to ignore it.
At the end, These are the rules I have added to make this work.
The rule in output chain redirects/forces udp/123 traffic that originated on the router via lte interface. The logs look a bit weird, (logged via log rule in filter table)
output: in:(unknown 0) out:pppoe-bsnl, proto UDP, <ip-on-wan-to-avoid-interface>:123->216.239.35.8:123, NAT (<ip-on-wan-to-avoid-interface>:123-> <ip-on-lte-interface>:123)->216.239.35.8:123, len 76
but it works fine.
The second rule takes care of traffic that originated from client devices.
@ishanjain clearly stated that he doesn’t control which NTP servers are used by clients. The only clear way of determining that a packet should be routed via alternative path is thus matching against certain properties (protocol=udp and dst-port=123) for packets about to leave router through either of WAN ports. The known bits of information are not enough for straight use of specific route, hence use of mangle (which is more flexible).
AFAIK neither src-port nor dst-port have to be exactly 123.
There are two kinds of NTP applications:
applications running as service/daemon and usually work as clients (to lower stratum servers) as well as servers (to higher stratum clients).
These customary use port 123 for both src and dst.
applications running as client only and mostly implement SNTP. These can run as non-privileged process and thus use ports with numbers higher than 1023. In this case src-port for packets originating from clients will be different than 123.
It is really unusual to see NTP server running on port other than 123, so dst-port will normally be 123 indeed.
One drawback of using IP address list instead of mangling NTP traffic is that all traffic towards those targets will use alternative WAN, non-NTP traffic as well. Some NTP servers share their IP addresses with other services (the most famous NTP servers don’t).
Plus, if I understand the latest concept, there will be some delay between clients first trying to access NTP server and first success (IIRC OP mentioned that the preferred ISP blocks NTP traffic) because of delayed running the script which populates the routing table.
Hi rextended, mkx, anav and everyone else who responded.
The approach to add all the routes to a ntp table will also work but it does have the downside that I am likely sending non-ntp traffic over LTE as well(which is slow and expensive) and it doesn’t have an instantaneous effect as mkx said. This’ll probably subside over time as a good chunk of NTP servers are added to the list but I don’t really want to do this.
For now, I will continue to use the firewall mangle rules. The script may help others(and maybe even myself if I notice problems in future with these mangle rules I have added) if they want to try something similar.
And Performance is not the biggest concern right now since the router I have(rb450gx4) is quite overpowered to begin with for my use case. For the longest time I was just running two bridges on it and didn’t knew that wasn’t the right way to do it. I recently switched it a proper bridge vlan filtering setup but for some reason, The bridge interface still aren’t hardware accelerated like they should be. Anyway, I’ll try to create another thread if this bugs me too much. For now, Even with all these issues, It works fine.
Thank you so much for your responses, I really appreciate it.
None of RB devices (your IPQ4019-based RB450Gx4 is not excluded) can HW offload bridge vlan-filtering in ROS v6. In ROSv7 things might change (RB4011 was mentioned, but uses completely different SoC). If you want VLAN operations done by switch chip, you have to configure things under /interface ethernet switch.
HW offloaded routing (inter LAN or inter-VLAN, doesn’t matter) is being in development (ROS v7.1) and only for CRS3xx models.
HW offloaded switching/bridging is to certain extent possible on all devices with switch chip, the way it should be configured varies between device models.
