I think for the preventing of RFC traffic from leaving your network, you could do this in ipf.conf:
le0 - opennet le1 - internal block out on le0 from 10.0.0.0/32 to any block out on le0 from 192.168.0.0/16 to any etc... This ought to work since NAT occurs before filtering, I believe. I don't have access to my firewall to look right now, but I think that's how you'd approach it. The other approach is to block everything by default and only route the traffic you want to cross the firewall/filter. I think the idea is basically the reverse of the anti-spoofing rules they talk about in the FAQ. As far as the actual NTP problem, I am much more unclear about this. It seems that if you were allowing that traffic across the firewall/filter with a rule that kept state, ipf would handle it, but I'd have to build a model to test it .. :) [ new to the list, so sorry if any of this is in error... please correct as necessary :) ] --Morgan On Tue, 25 Feb 2003, Lupe Christoph wrote: > Hi! > > Yesterday, I found out that my dual NTP server config did not work as > intended. Dunno how long it hasn't. Fortunately, the problem does not > prevent the remaining server from working if the other one goes down. > > Here is what I got at a client site: > > One NATting IPFilter firewall named cabernet. Two NTP servers on the > internal net. Let's name them nelly and kelly (SCNR). Both nelly and > kelly want to sync to NTP servers on the internet. Doing so they send > UDP packets from port 123 to the NTP servers on the internet, port 123. > > Cabernet NATs them. It enters a state entry for the first server to send > a packet and NATs that. This first server works OK. > > The second server will not get a state entry because IPFilter tries to > preserve the source port and that is taken. (Both servers have the same > set of NTP servers on the internet, I guess the dilemma will not occur > if the have different servers.) > > The UDP packet is passed out to the internet unNATted. Boo, an RFC > address! And of course it gets dropped somewhere. And even if it isn't, > the server has no return route. > > If I use ntpdate -d, the packet will be sent from an ancillary port and > it will be NATted. > > I use a NAT entry like this: > map fxp0 from 192.168.0.0/18 to 0.0.0.0/0 -> 1.2.3.4/32 > where 1.2.3.4 is the official address of cabernet. This is FreeBSD 4.7, > IPFilter v3.4.29. > > Here are my questions: > > 1) Will only "low" ports be preserved, or will different machines > sending UDP packets on the same "high" port experience the same > problem, for some values of "low" and "high"? > 2) If they don't, what is "low" and "high"? > 3) If anybody on this list who has read this far ;-) had the same > dilemma, how did you solve it? I see the following options: > - get xntpd to use a high port (assuming collisions are resolved). I > could not find out if this can be done. > - use a machine in the DMZ as an NTP server > - craft a special NAT rule for one of nelly and kelly > - use different NTP servers for nelly and kelly. > 4) tcpdump shows me unNATted packets leaving the firewall. This is > undesirable. What can I do to prevent packets sourced from an RFC > address to leave my firewall? Filter rules can't do it, they are > processsed before that NAT occurs. Should IPFilter drop packets it > can't/won't NAT? > > I can implement one of the solutions in 3), except for the xntpd > tweaking, because I don't know how to tweak it. So this is not a plea > for help. I'm just curious, and I would like to prevent the RFC source > addresses from leaving the network. > > Thanks for ideas, help, advice, etc! > Lupe Christoph > -- > | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | > | Big Misunderstandings #6398: The Titanic was not supposed to be | > | unsinkable. The designer had a speech impediment. He said: "I have | > | thith great unthinkable conthept ..." | >
