> On 2017-02-20, kasak<ka...@kasakoff.net> wrote: > > hello everybody! > > > > Recently i saw this trick on > >http://www.tedunangst.com/flak/post/turn-your-network-inside-out-with-one-pfconf-trick > > > > I decided it was a great idea, and tried to add this rule to my > > firewall, but it doesn't work. > > > > Look, I placed this line immediately after nat-to rule > > > > #Enable NAT > > pass out on $ext_if inet from $lan_net to any nat-to $ext_if keep state > > (pflow) > > > > #ntp and domain redirection > > pass in on $int_if proto {tcp,udp} from !192.168.2.65 to any port > > {domain,ntp} rdr-to lo > > > > So it expand to this rules: > > > > pass in on em1 inet proto tcp from ! 192.168.2.65 to any port = 53 flags > > S/SA rdr-to 127.0.0.1 > > pass in on em1 inet proto tcp from ! 192.168.2.65 to any port = 123 > > flags S/SA rdr-to 127.0.0.1 > > pass in on em1 inet proto udp from ! 192.168.2.65 to any port = 53 > > rdr-to 127.0.0.1 > > pass in on em1 inet proto udp from ! 192.168.2.65 to any port = 123 > > rdr-to 127.0.0.1 > > > > 192.168.2.65 is my local domain and ntp server, it must be able to > > access world to work properly. > > > > em1 is my LAN interface > > > > Anyway this rule doesn't work and i don't know why :( > > > > $ doas tcpdump -i em1 port ntp > > tcpdump: listening on em1, link-type EN10MB > > 11:07:35.594706 192.168.3.119.4662 > clock.via.net.ntp: v1 client strat > > 0 poll 0 prec 0 > > 11:07:35.594804 clock.via.net.ntp > 192.168.3.119.4662: v1 server strat > > 2 poll 0 prec -6 [tos 0x10] > > 11:07:40.131132 192.168.2.75.45003 > mail.sonur.ru.ntp: v4 client strat > > 0 poll 0 prec 0 (DF) > > 11:07:40.136985 mail.sonur.ru.ntp > 192.168.2.75.45003: v4 server strat > > 2 poll 0 prec -6 [tos 0x10] > > This tcpdump trace doesn't directly show whether or not it works - the > packet source address of return packets is rewritten due to the PF rdr-to > rule. > > However if I query mail.sonur.ru myself it reports that it is stratum 1, > and since you see stratum 2, and identical return values from the 2 servers, > I suspect the redirect probably *is* working. For extra confirmation use > tcpdump -v and look at the ttl and extra fields. Compare these with and > without this rule in place. > > Regarding the DNS side of this - careful with this if you want to do > authoritative DNS lookups from machines on your network - it isn't > always appropriate to forward to a recursive resolver in this way. > Really, you only want to redirect queries with the RR flag (which you > can't do from PF), and even then this will mess you up if you're trying > to debug certain problems. Oh, thank you! Now I see, that all answers from all ntp servers have stratum of my server. And about dns, i have to do this because of some hard infected windows clients. I don't really think that i need to do recursive lookups from clients, but it can help to solve problems with windows clients, where viruses replace "dhcp offered" dns servers with bad "hacker offered".
I have tried to lookup my own server from 192.168.2.65 and from client and that's what I have: From 2.65: $ nslookup kasakoff.net 91.210.228.4 Server: 91.210.228.4 Address: 91.210.228.4#53 Name: kasakoff.net Address: 91.210.228.4 From client: kasak@mint ~ $ nslookup kasakoff.net 91.210.228.4 Server: 91.210.228.4 Address: 91.210.228.4#53 Non-authoritative answer: Name: kasakoff.net Address: 91.210.228.4 So it proves that redirect works! Thank you very much for explanations!
