DNS deny

[rtoko]

Hi, I after upgrade of FGT60D to 5.2.2. policy is behaving very strange, at least one...

For example I have policy ACCEPT from internal (LAN) to WAN for service ALL .. in short to internet. Now after upgrade http/https is not working, but for example Skype is working normally. So I figured it out that there is something wrong with DNS. So I made new policy just for DNS and now http/https is working.

So my question is why is this necessary after upgrade!? Is it not enough to use SERVICE "ALL"!?

Regards

[JohnAgora]

Any news on the topic?

I've had some strange behaviour with DNS on 5.2.4 and 5.2.7

[JaapHoetmer]

Hello all

I am in process of tightening outbound traffic, and I noticed a strange behaviour with regards to DNS.

In the list of allowed outbound services DNS is enabled, and the default definition of DNS is to allow TCP and UDP traffic on port 53. However, I noticed while trying to establish an SSL VPN connection that FortiClient stopped at 10%, which indicates host unreachable. Sure enough, I found that FortiClient uses 53/udp for its DNS queries, and the firewall denies this, even though DNS tcp and udp is permitted (and 53/tcp queries are in fact correctly passed). So does this have anything to do with a UDP deny? Not sure where to look.

The DNS definition:

CTFW01 (DNS) # show full config firewall service custom     edit "DNS"         set explicit-proxy disable         set category "Network Services"         set protocol TCP/UDP/SCTP         set check-reset-range default         set comment ''         set color 0         set visibility enable         set iprange 0.0.0.0         set fqdn ''         set tcp-portrange 53         set udp-portrange 53         set tcp-halfclose-timer 0         set tcp-halfopen-timer 0         set tcp-timewait-timer 0         set udp-idle-timer 0         set session-ttl 0     next end

The FortiWifi 60D was running V5.4.0 when I discovered this, I have just upgraded it to 5.4.1 but the problem persists. The release notes of v5.4.1 made no mention of this particular issue.

Does anyone have any idea why 53/udp could be denied?

[ede_pfau]

hi,

first, DNS lookups only use udp/53. tcp/53 is used in DNS zone transfers, something that should be denied altogether if the source or destination are not trusted/own DNS.

As a consequence, I'd try to use the predefined DNS service just to avoid any issues here.

I could imagine that the FC uses a source address during setup that is unexpected. Therefor, the policy might block the request.

Apart from posting the relevant policy, you should run a 'diag deb flow' as mentioned a zillion times on the forums (e.g. lately here). This will clearly show where and why traffic is blocked.

[JaapHoetmer]

Of course it's all udp, thanks for that correction Ede. I'll check out the FC configuration to see if that clarifies, however, even when the FG policy has no source address specification, it still doesn't work.

Ran a diag debug flow but that wasn't much help yet. Will continue the investigation and post results.

[JaapHoetmer]

Strange. Nothing has changed, and suddenly it works.

Apologies for the disturbance in the force.