|
|
1
« Last post by MC on October 15, 2024, 08:15:19 PM »
I can't see how using 10G interfaces on an ISE appliance would affect a use of certificate so you should be fine.
2
We're migrating ISE 2.4 to ISE 3.3 by running in parallel by adding new 3715's. Then, we'll just cut over. Certificates deployed as you specified - access.ise.domain.com and *.ise.domain.com. We've got CIMC and G0 primary | G1 backup interface for GUI mgmt on the PAN/MnT on 3615s. The 3715s will be PSN dedicated in a Medium deployment. We're leveraging the 10Gbps capability of fiber on the boxes. Will the certificate delivery work fine for RADIUS, AAA, portal services over the 10Gbps interfaces on fiber?
3
« Last post by Administrator on September 30, 2024, 08:00:18 AM »
In the Firepower lab, there is actually a lab router in front of it that connects to the internet. You can deploy Firepower in several modes but routed mode is the most common. You may or may not put a router in front of it depending on requirements and size of your deployment. In a Data center, you will most likely have a dedicated internet router. Hope this helps.
4
« Last post by Administrator on September 30, 2024, 07:59:56 AM »
Hello I would like to know if you have any videos deploying Firepower with a router. At the moment I am watching the Firepower 6.7 FDM and it looks like the firepower is replacing the router. Is this best practice? I am all new to firewalls and I find your material very useful and I thank you. Could you please let me know. Thank You
5
« Last post by MC on April 21, 2024, 09:13:05 PM »
Pre-filter is like an interface ACL. It can only match IP/Port/Protocol and is stateless so it should only be used to match simple traffic and has rules that are fairly static.
For ACP, traffic is matched by zone pair first so their orders do not really matter. Within the same zone pair, more specific rules should go to the top. ACP is always stateful.
6
« Last post by LoboPR on April 19, 2024, 11:27:19 AM »
Ok,
So what would be like the best practice:
First Pre-filters - Like you mention on the video training. Then
ACP:
1- Allow inbound traffic to static NAT (inside Servers)
2- Monitor - all Traffic (for discovery)
3- Allow outgoing traffic from users (Url, application, malware and IPS)
4- Deny Any Any
Does the stateful feature still apply?
If I allow a packet to go out, would the return traffic make it in?)
7
« Last post by MC on April 18, 2024, 07:45:28 PM »
1. Access Policy in FTD has a configurable default rule at the bottom. You can set it to deny or allow.
2. There is no concept of Security Level in FTD. All interfaces would show as 0 on CLI. You need to create a zone, assign to each interface, and come up with an Access Policy that will control traffic between zone. By default, traffic is not allowed between interfaces.
8
« Last post by LoboPR on April 16, 2024, 08:38:01 AM »
Hi,
I come from the ASA side of firewalls. Have a few questions.
1- In the ASA ACL you would have an implicit Deny any any at the end of the ACL. That would block all traffic not explicitly permitted in the ACL. Best practice would be to enter it as an ACE at the last position with the log option.
Is this the same with the ACP on the FTD?
2-With just configuring NAT on the ASA. The traffic from the higher security level can pass to the lever security lever (ex inside (100) outside (0))
On the FTD I notice that the security levels are all level 0 and no place to change this.
Do we have to explicitly permit outgoing traffic before the deny?
Thanks,
9
« Last post by MC on March 21, 2024, 07:30:58 PM »
You are correct. Because MPBGP was used between BC and Transit Control node, LISP routes at each VRF/Site need to be redistributed into MPBGP and this includes any external routes learned by a site Border node. These are all taken care of by DNAC and there is nothing you need to do manually in terms of redistribution.
10
as per my understanding, transit control node only learns LISP prefixes which then redistributes them in MPBGP towards BC nodes at sites.
At HQ, there is some route leaking between VRFs for some shared services in DC.Does this mean that it is mandatory to redistribute BGP prefixes ožat HQ site into LISP so they get advertised to transit control node?
If not, how BC nodes at other sites would learn about those prefixes if transit control node is not learning BGP prefixes?
What am I missing?
Thank you in advance.
|
Recent Posts