Blocking Log On Page from showing up

Yes that is the idea of trusted hosts.  You shouldn't be able to see a log in page unless you are coming from an IP of a trusted host.  If you are seeing a log in page from an IP that is not listed as a trusted host then we need to troubleshoot further.

Another way to accomplish this would be to zero out the trusted hosts (return them to the defaults: no untrusted hosts) and use local-in policies to create one list of ACLs.

config firewall local-in-policy

edit 0

set intf wan1 //--or the interface you specify for incoming management traffic

set srcaddr <address_obj>

set dstaddr <address_obj>

set schedule <schedule_name>

set service <service>

set action {accept | deny}

set status enable

next

etc.

You can create a much more granular list this way, and avoid unexpected behavior, like pings being denied to users due to restrictions on management access to the GUI.

Hello everyone,

           My apologies for the delayed response, I have been in training the last week or so.  I looked at both of these proposed options and while I liked the idea of being able to control things a bit more I decided to use Trusted Hosts.  My primary goal is to block access to the admin features and stop bots from trying to login to my devices.  I feel like I have my policies dialed in pretty good to achieve the other items the Local In policy offers.

          That being said, I attempted to config the trusted hosts and for some odd reason I can't understand it dropped the IPSec VPN tunnel to my datacenter.  Prior to configuring the trusted hosts I did a port scan on my external IP address.  Port 22 and port 443 were the only two open but after I made the change they were in stealth mode.  I thought the Trusted Hosts was only for admin access?  Any thoughts would be appreciated.  Thanks in advance!

Pat 

The trouble with using Trusted Hosts is that, with web-based access protocols, you need to prove who you are before being allowed or denied based on the rule set. With local-in policies, even the initial packet is subject to the rule.

IPSec traffic uses UDP/500, so unless the tunnel requires Auto-IPSec (one of the administrative access methods), I don't see why it would be affected.

Try a sniff and a flow trace to see where the traffic breaks down:

1. diag sniffer packet wan1 "port 500 or port 4500" 4

-Press Ctl+C to stop

2. diag debug reset

diag debug enable

diag debug flow show console enable

diag debug flow show function-name enable

diag debug flow filter port 500

diag debug flow trace start 5000

<leave running long enough to capture a connection attempt, then...>

diag debug flow trace stop

diag debug flow filter clear

diag debug reset

diag debug disable

Thanks Christopher, i'm gonna work on this today.  Thanks,

Pat