DNS zone transfer behind NAT

hi all,
i have a DNS server behind NATed router. It is hosting top level domain for organization and it is primary dns server. ISP is hosting secundary zone, zone replication is allowed for that ISPs ip address.
Dstnat rules are configured for requests from outside, UDP 53 from WAN ip to LAN ip and works ok.
When i try to transfer zone to secundary DNS, it is not allowed until under allowed servers in primary DNS server i put local ip of the router.
But then zone transfer is allowed to everyone because source ip of request is 192.168.0.253 and destination is ip of DNS server, 192.168.0.251.

17 ;;; DNS Forward
chain=dstnat action=dst-nat to-addresses=192.168.0.251 to-ports=53 protocol=udp dst-address=85.10.x.y
in-interface=ether1 dst-port=53 limit=1200/1m,1500 log=no log-prefix=“DNS-UDP”

18 ;;; DNS Forward
chain=dstnat action=dst-nat to-addresses=192.168.0.251 to-ports=53 protocol=tcp dst-address=85.10.x.y
in-interface=ether1 dst-port=53 log=no log-prefix=“DNS-TCP”

I have tried to find on forums sollution but without success.
many thx

p.s.
i know that it should be opposite - primary dns at ISP, secundary at own site, but that is inherited situation.

Sounds like it may be hitting a srcnat rule as well. Check them and make sure incoming traffic to the DNS doesn’t match on it.

Do you have a firewall rule to allow established and related connections forward?

thx.

@Kevin
39 ;;; Block all exc. related
chain=forward action=drop connection-state=!established,related connection-nat-stat src-address-list=!OK log=yes log-prefix=“ALL-39”

would tht do ?

@Skuykend

i have 1 src-nat rule and that is masquerade

ps bellow is capture from log, 194.146. ip is secondary dns server trying to contact primary
http://imgur.com/a/nXyuj

What are the condition filters on the masquerade? Out-interface?

0 ;;; Default Masquerade
chain=srcnat action=masquerade log=no log-prefix=“”

1 ;;; Port FW 443 (mail)
chain=dstnat action=dst-nat to-addresses=192.168.0.245 to-ports=443 protocol=tcp dst-address=85.10.x.y in-interface=ether1
dst-port=443

2 ;;; Hairpin (mail)
chain=srcnat action=masquerade to-addresses=192.168.0.245 to-ports=443 protocol=tcp src-address=192.168.0.0/24
dst-address=192.168.0.0/24 dst-port=443

3 ;;; NAT 443 Local (mail)
chain=dstnat action=dst-nat to-addresses=192.168.0.245 to-ports=443 protocol=tcp src-address=192.168.0.0/24 dst-address-type=local
dst-port=443


Maybe here lays catch!
When i put out-int on default masq rule, Outlook clients cannot connect to mail server. So, i was forced to leave it in this condition.

Maybe? For sure. This rule #0 will masquerade every single connection coming through router, no matter what source or destination it has. It’s in most cases not what you want. If your Outlook clients can’t connect without it, you need to fix server config (it most likely allows them to connect only from local subnet and not from internet). Alternatively, if you can’t fix the server, you can add masquerade rule for traffic to server and ports used by Outlooks clients. Then limit default masquerade to WAN and leave other traffic alone.

Btw, if rule #3 is used for connecting to 85.10.x.y from LAN, then you don’t need it. Just remove in-interface=ether1 from rule #1 and it will work for both internet and local connections.

I agree with Sob, definitely need to lock rule #0 down more and figure out the cause for the Outlook failure and fix it separately.

As it is now, any device on your networks is going to see outside initiated traffic as coming from the local router interface IP instead of their real IP, including the outside DNS backup server. This makes fire-walling difficult and confusing at best.

on the 39 rule you posted, do you have a rule to allow the new connections OUT?

Thx all for help.
Pretty soon they have migration to new ISP so then ill fix this up.

@Kevin

on the 39 rule you posted, do you have a rule to allow the new connections OUT?

Yes, i have.
thx