I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out.
ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
