NAT configuration many to one?

[UniOvi]

Hello,

Could anyone post an example to configure a Fortigate with two interfaces, inside and outside, the rules and objects to intercept all sessions from inside to any public server port (let's say UDP:53) and send them instead to only one owned server, same port (UDP:53)? Something like getting all the public DNS queries and diverting them to our own DNS through the outside interface...

I remember that the Cisco ASA "fix" this with a NAT rule that could get rid of several destinations and DNAT them to only one, with SNAT also for inner hosts.

Sure it's a lot easier that seems to me now....:(

Thanks in advance,

Jah

[srajeswaran]

Do you have a list of public DNS servers that need to be mapped to one IP? Or you have only the port number and IP can be anything?

[UniOvi]

Hello,

yes, we have a set of well-known servers configured by hand in a bunch of PC, but it would be great if we could just specify the port and avoid the list.

Thank you,

Jah   

[gfleming]

Can you not just have a policy to block external DNS? This would be more effective and force users to use your server. You won't have to manage a list of servers, either.

[UniOvi]

Hello,

well, it will work for sure but I don't want to take down service at all...just avoid the use of those public servers...

what about a transparent proxy? I think that the deployment should be the same, the only difference would be the destination port...is it possible with Fortigate to behave this way?

Thank you,

Jah

[gfleming]

FortiGate can act as a transparent proxy but I'm not sure how this fixes your issue? Your DNS requests will still head out the same way as before.

I understand you don't want to block external DNS servers but the alternative is you maintaining an ever-growing list of public DNS servers that you need to redirect internally.

I don't believe there is a way to catch only port-based traffic and NAT it. If you remember how the Cisco ASA does it exactly perhaps we can see if the FGT has a way of mimicking it.

One way I think you could do this is with policy-based routing but you'd have to redirect it to an internal host that is also listening on all of those IP addresses. So again not a pretty solution.

[pminarik]

Do you actually have devices that insist on using their hard-coded DNS server IPs and refuse to use the DHCP-provided one(s)?

From limited personal experience, I've had a couple devices that always tried to use "their own" DNS server, but when blocked, always fell back to using the DNS server from DHCP. (and frankly, I wouldn't want a device in my network that refuses to use my DNS servers)

I imagine you could make this transition/research fairly painless by logging the outgoing DNS traffic and then gradually moving these devices to a blocking rule, and finding out how they react.

[UniOvi]

Hello,

I agree with you, there are several ways to manage this situation, forcing or migrating users to use the servers that are intended to serve these clients. But, when I decided to go the "soft" way, just intercepting these queries and passing them to our own server,

is when I discovered I couldn't find a way of trapping the queries to *any* DNS  and forwarding them to my own DNS. And that's the origin of this question...

Thank you,

Jah