Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
kkeane
New Contributor

An extra ACCEPT rule prevents traffic?

I came across something very odd, and would appreciate your help understanding it. I' m trying to set up a wireless network with a captive portal, similar to what you' d find in a Starbucks or the like. I have two policies from the wireless network to the WAN side. The two policies I' m using are listed below.. The strange thing is that the wireless clients get IP addresses, but can' t browse the Web; they don' t even get to the captive portal site. As soon as I delete the first of the rules, everything works flawlessly - even though it seems to me that the first rule is an ACCEPT rule. Can anybody help me understand why this rule prevents access to the captive portal? edit 3 set srcintf " my-guest" set dstintf " WAN" set srcaddr " all" set dstaddr " Allowed DNS Servers" set action accept set schedule " Store Hours" set service " DNS" set nat enable next edit 4 set srcintf " my-guest" set dstintf " WAN" set srcaddr " all" set dstaddr " all" set action accept set schedule " Store Hours" set service " ALL" set utm-status enable set webfilter-profile " default" set ips-sensor " default" set profile-protocol-options " default" set nat enable next
5 REPLIES 5
rwpatterson
Valued Contributor III

What' s the order in the FGT?

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
kkeane
New Contributor

Good point, I forgot to make that clear. The rules are in the same order I posted them. The DNS rule came first, then the ALL rule. The original plan was that, once I get it working, I' d insert a third rule to prohibit DNS queries to the rest of the world (so that clients would only be able to use legit DNS servers), but while configuring the firewall, I haven' t added that rule yet.
rwpatterson
Valued Contributor III

When everything works, what is the DNS server that the FGT provides via DHCP? Why not force all wireless clients use that instead.... It' s already a proven working solution. As far as your original query, I have no insight into why your DNS policy stops the CP from working. (unless your " Allowed DNS Servers" does not include the DNS server the FGT uses, and CP relies on that FGT provided server...)

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
kkeane
New Contributor

Yes, clients should of course use the DNS server handed out by DHCP (I' m actually handing out the DNS servers from our ISP), and most will. But as far as I know, there is no other way to prevent clients from hard-coding the DNS server even when they automatically acquire the IP address. Windows, for instance, has a separate checkbox for " automatically acquire DNS servers" . The idea is to block alternate, and possibly malicious, DNS systems such as opendns, namecoin or the like (not saying those are actually malicious, but are smaller and thus easier to subvert). Even if the allowed DNS servers by mistake didn' t include the ones handed out by DHCP, it shouldn' t really matter because the DNS traffic should just fall through to the second rule. And I have an even harder time seeing why it would prevent even the captive portal page from coming up. In any case, thanks for your comments!
kkeane
New Contributor

Today was the final integration test before this network is going into production. Just for kicks, I re-added the same rule. No problem, everything worked just as expected. I can only suspect that I must have had an error in my original version (maybe I forgot to turn on NAT mode). In any case, thanks for the help!
Labels
Top Kudoed Authors