About Alexandre Hautequest

Alexandre Hautequest · ‎11-13-2018

Symptoms Hardware based devices have, from time to time, BIOS, UEFI or firmware updates, which Cisco calls - for historical purposes - "ROMMON". While there is always an accompanying upgrade guide, there is no reference whatsoever for the ASA-x while running as FTD/sensor mode. This article will add this missing link, in the event anyone ever has to follow this process - as I just did. The below was tested successfully on a 5506-X lab device running FTD 6.2.3.6, managed by a FMC. Diagnosis As per "Cisco ASA Series General Operations CLI Configuration Guide, 9.5" document, section "Chapter: Software and Configurations", subsection "Upgrade the ROMMON Image (5506-x, 5508-x, and 5516-x)" [1], the instructions points the admin to upload the new ROMMON code to the device and run the upgrade rommon command. While the firmware revision verification and the file transfer commands can be achieved using the FTD CLI (with a minor command line adjustment for file transfer), there is no such upgrade command. As such, you now may feel stuck. [1] https://www.cisco.com/c/en/us/td/docs/security/asa/asa95/configuration/general/asa-95-general-config/admin-swconfig.html#task_90917D0EBAC2427487F6F51D21ABC235 Solution In order to perform the upgrade, the CLI needs to be changed from the default FTD mode to the Diagnostic mode. This is done with the use of command system support diagnostic-cli. This will bring back our old familiar Cisco CLI, where you can move up to the privileged mode with enable command. At this point, you are back in the process, able to perform the last required upgrade command, upgrade rommon. It will verify the file integrity, signature, confirm the configuration, and ask to reload it. The device will then reload twice, one to read the new code, then another to apply the new code, and finally reload to bring back the FTD alive. On the 5506-X, this process took about 10 minutes. See below how it looks like. Rom image verified correctly Cisco Systems ROMMON, Version 1.1.12, RELEASE SOFTWARE Copyright (c) 1994-2017 by Cisco Systems, Inc. Compiled Wed 06/28/2017 14:36:11.63 by wchen64 Current image running: Boot ROM1 Last reset cause: PowerCycleRequest DIMM Slot 0 : Present INFO: Rommon upgrade state: ROMMON_UPG_START (1) INFO: Reset code: 0x00002000 Firmware upgrade step 1... Looking for file 'disk0:asa5500-firmware-1114.SPA' Located 'asa5500-firmware-1114.SPA' @ cluster 99075. ########################################################################################### Image base 0x7700a018, size 9241408 LFBFF signature verified. Objtype: lfbff_object_rommon (0x800000 bytes @ 0x7700a238) Objtype: lfbff_object_fpga (0xd0100 bytes @ 0x7780a258) INFO: FPGA version in upgrade image: 0x0204 INFO: FPGA version currently active: 0x0204 INFO: The FPGA image is up-to-date. INFO: Rommon version currently active: 1.1.12. INFO: Rommon version in upgrade image: 1.1.14. Active ROMMON: Preferred 1, selected 1, booted 1 Switching SPI access to standby rommon 0. Please DO NOT reboot the unit, updating ROMMON................... INFO: Duplicating machine state...... Reloading now as step 1 of the rommon upgrade process... Toggling power on system board... Rom image verified correctly Cisco Systems ROMMON, Version 1.1.12, RELEASE SOFTWARE Copyright (c) 1994-2017 by Cisco Systems, Inc. Compiled Wed 06/28/2017 14:36:11.63 by wchen64 Current image running: Boot ROM1 Last reset cause: RP-Reset DIMM Slot 0 : Present INFO: Rommon upgrade state: ROMMON_UPG_START (1) INFO: Reset code: 0x00000008 Active ROMMON: Preferred 1, selected 1, booted 1 Firmware upgrade step 2... Detected current rommon upgrade is available, continue rommon upgrade process Rommon upgrade reset 0 in progress Reloading now as step 2 of the rommon upgrade process... Rom image verified correctly Cisco Systems ROMMON, Version 1.1.14, RELEASE SOFTWARE Copyright (c) 1994-2018 by Cisco Systems, Inc. Compiled Tue 06/05/2018 22:45:19.61 by builder Current image running: *Upgrade in progress* Boot ROM0 Last reset cause: BootRomUpgrade DIMM Slot 0 : Present INFO: Rommon upgrade state: ROMMON_UPG_START (1) INFO: Reset code: 0x00000010 PROM B: stopping boot timer Active ROMMON: Preferred 1, selected 1, booted 0 INFO: Rommon upgrade state: ROMMON_UPG_TEST !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! Please manually or auto boot ASAOS now to complete firmware upgrade !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Alexandre Hautequest · ‎12-21-2017

I know this is sort of late, but let me share some $.02. I had a few issues with internal systems being accessed from the outside world. Turns out TAC told me”because you have absolutely everything configured and active, well over 10k active IDS rules, and you are also doing SSL inspection, your max throughout will be limited to less than 3Mbps”. So watch out for the Fort Knox type of config. Looks great on paper but it can definitively hog your device to death. I have balanced my rules to the point I have as much active and I can peak my 150Mbps up/down traffic with some spare change. Enjoy your new toy ;)

Alexandre Hautequest · ‎09-29-2017

I learned a few new things with this issue. 1. I was trying to achieve what is called "NAT divert". Seems this is pretty wide used and known - now that I know its correct name. 2. The any keyword cannot be really used all the time, so the need for a World object was spot on. 3. My ACL was close but got no cigar. For the NAT divert to work, I had to use keyword interface, and it had to be of type dynamic, not static, which by the end of the day, makes proper sense: nat (Inside-VLANx,Outside) source dynamic any interface destination static World NTP-Server service udp-123-ntp udp-123-ntp 4. With the rule added, the ASA began redirecting traffic as expected, with a side effect: it began to proxy-arp every empty IP address for this segment. To circumvent that (and fix Cisco ISE's IP address check during initialization time - hint, hint!), a system option command to the rescue: sysopt noproxyarp Inside-VLANx So there we have it. Hope this saves others some time in the future.

Alexandre Hautequest · ‎09-14-2017

Apart of me finding out that using the internal object "any" makes the rule not even be accepted as valid by the ASA, but creating an object named "World" as network 0/0 allows the rule to be added, it still does not work. asa(config)# nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static any NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp ERROR: any doesn't match an existing object or object-group asa(config)# object network World asa(config-network-object)# subnet 0.0.0.0 0.0.0.0 asa(config-network-object)# exit asa(config)# nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static World NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp asa(config)# _ Packet tracer says traffic was allowed, but I cannot get a response back from the NTP server - doesn't matter if NTP server is on the same or on a different subnet. It does not show up on the regular ASA logs: asa# capture ntp real-time match udp any any eq ntp Warning: using this option with a slow console connection may result in an excessive amount of non-displayed packets due to performance limitations. Use ctrl-c to terminate real-time capture (a few minutes later: Control+c) 0 packets shown. 0 packets not shown due to performance limitations. Removing the net-to-net from the NAT rule makes no difference. Looking at an asp-drop -type capture: asa# sh capture capture ntp type asp-drop all [Stopped - 0 bytes] match udp any any eq ntp asa# capture ntp real-time Warning: using this option with a slow console connection may result in an excessive amount of non-displayed packets due to performance limitations. Use ctrl-c to terminate real-time capture 1: 18:41:44.244668 192.168.X.XX.123 > 80.92.126.65.123 : udp 48 Drop-reason: (acl-drop) Flow is denied by configured rule 2: 18:41:44.444249 192.168.X.XX.123 > 103.242.68.69.123 : udp 48 Drop-reason: (acl-drop) Flow is denied by configured rule , which is not exactly true: access-list Inside-VLANx _access_in extended permit udp 192.168.X.0 255.255.255.0 object World eq ntp but matches what I see on the client: user@unix:~# tcpdump -ni eth0 'port 123' & [1] 34422 user@unix:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes user@unix:~# ntpdate pool.ntp.org 18:41:44.244668 IP 192.168.X.XX.123 > 80.92.126.65.123: NTPv4, Client, length 48 18:41:44.444249 IP 192.168. X.XX.123 > 103.242.68.69.123: NTPv4, Client, length 48 14 Sep 18:44:46 ntpdate[33645]: no server suitable for synchronization found Any further suggestions?

Alexandre Hautequest · ‎09-11-2017

Marvin, I would still like the devices I cannot change NTP servers to talk to a real NTP server. By putting in an ACL, servers with hardcoded entries would not get their clocks synchronized. The other option I tried was to force any DNS request to *.ntp.org to point at my internal NTP. While this had a positive effect on some devices, others still had hardcoded IP addresses or hostnames outside the *.ntp.org domain. And then there is the management piece of the DNS: this is a network wide change vs a one single subnet - unless I turn on a dedicated DNS box just for that. Thanks for your thoughts though.

Alexandre Hautequest · ‎09-09-2017

Hello all. Is there any way I can configure my ASA to keep internal all NTP traffic from a certain subnet? There are embedded devices and appliances on this network where NTP configurations are not available and the NTP servers are randomly chosen via the NTP pool or to whichever NTP server the vendor decided to hard-coded. Last I saw I had over 50 different IP addresses of public NTP servers, so making a list of them would be too cumbersome to maintain. While the below does not work, it sort of gives an idea of what I am trying to achieve: nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static any NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp Any suggestions?

Alexandre Hautequest · ‎06-15-2017

I know this is a really old topic, but seems there are no many suggestions around when it comes to this subject. The static IP address reservation with VRF is a bit different from a non-VRF aware device, but it makes perfect sense after you do it once. On a non-VRF device, you can create as many pools you want, including a pool for each of your static IP address assignments - naming them as you wish so your configuration is clean and pretty. On a VRF device, you must enter the hardware address/client info under the VRF aware pool itself. Now, the catch is: you can't exclude a range of IP addresses and assign one of the excluded IP to a host. So using the original, 4 year old example, here is how his setup would have been done: ip vrf OFFICE rd 200:2 route-target export 200:2 route-target import 200:2 ! ip dhcp excluded-address vrf OFFICE 10.10.27.1 10.10.27.4 ip dhcp excluded-address vrf OFFICE 10.10.27.6 10.10.27.15 ! ip dhcp pool OFFICE vrf OFFICE network 10.10.27.0 255.255.255.192 default-router 10.10.27.1 dns-server 10.10.1.1 10.10.1.2 domain-name foo.com host 10.10.27.5 client-identifier 01xx.xxxx.xxxx.xx And there you have it. You won't have its name anywhere on the configuration, but you will achieve the final result of a static IP address assigned under a DHCP attached to a VRF interface. May this help the next person Googling around...

Alexandre Hautequest · ‎03-21-2017

I'm still working with TAC on this. So far, nothing moving anywhere. However, I was pointed to this topic today - https://supportforums.cisco.com/discussion/12959476/5506-x-firepower-blocks-traffic-prior-policy-processing-and-does-not-record Seems this is an old issue crippling the product. Also seems bigger ASAs are not seeing much impact, which tends to tell me the 5506 has the SSL Inspection feature but it cannot handle traffic of a single user.

Alexandre Hautequest · ‎03-05-2017

Well, yes, it works with traditional NAT, including the manual IP address assignment. Guess I did not researched long enough, but it explains why it worked on other scenarios (with VRFs) but not on this scenario (without VRFs): http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/26704-nat-faq-00.html Q. What is NAT NVI? A. NVI stands for NAT Virtual Interface. It allows NAT to translate between two different VRFs. This solution should be used in lieu of Network Address Translation on a Stick. Q. Should NAT NVI be used when NATting between an interface in global and an interface in a VRF? A. Cisco recommends that you use legacy NAT for VRF to global NAT (ip nat inside/out) and between interfaces in the same VRF. NVI is used for NAT between different VRFs. Anyway, back to the drawing board. Appreciated your time lending a fresh set of eyes.

Alexandre Hautequest · ‎03-05-2017

The tunnel is a basic EZVPN, with a pre-shared key on the router side, and a road warrior client on the other side - that can be a Cisco VPN client, an iOS device... crypto isakmp policy 1 encr aes 256 hash sha512 authentication pre-share group 14 crypto isakmp keepalive 90 crypto isakmp client configuration address-pool local vpn-ip-pool ! crypto isakmp client configuration group XXX key 6 ... dns 200.200.200.201 domain XXX pool vpn-ip-pool include-local-lan pfs max-users 5 netmask 255.255.255.0 crypto isakmp profile vpn-isakmp-profile match identity group XXX client authentication list XXX isakmp authorization list XXX client configuration address initiate client configuration address respond keepalive 90 retry 2 virtual-template 1 ! crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac mode tunnel ! crypto ipsec profile vpn-ipsec-profile set security-association idle-time 900 set transform-set ESP-3DES-SHA set pfs group1 set isakmp-profile vpn-isakmp-profile ! ip local pool vpn-ip-pool 192.168.1.241 192.168.1.245 The only static route is for the upstream provider, internally all routes are provided via OSPF.

Alexandre Hautequest · ‎03-04-2017

Uhm, not really able to get the config in full. Any partition you are looking in particular? Now, I have to mention that this used to work until the valid IP address was moved off the physical Gi0/0 interface to the VLAN interface. The NAT address was then tied to this interface as of ip nat source list nat - list interface Gi0/0 overload , however now that it should go out using its own static, public address, doesn't work anymore. But that made me think, "what if...", and I did change the NAT to ip nat source list nat-list interface Vlan999 overload and guess what, it "works". Leaves out to the wild with the router VLAN interface IP address and not with my desired IP address, but works. So maybe my follow up question to my own questions are, can't NAT be assigned to an unnumbered interface?

Alexandre Hautequest · ‎03-04-2017

I have a router running IOS 15 on the public Internet which I want to remotely manage using a point to point IPSec tunnel. This tunnel was created just fine, I can log on to the router, I can reach the devices behind this router, any access to behind this router works just fine. I can't, however, go back out on the public Internet while connected via this IPSec tunnel. My NAT configuration attempts so far got me a little frustrated, with three crashinfo files created recently... The Internet facing interface is set as ip unnumbered, with the valid, public IP address on a VLAN interface. The VLAN is part of a ZBW zone labeled LAN. The Internet interface is on the WAN zone. My IPSec tunnel gives me a 192.168.1.x/24 IP address on a Virtual-Access interface, configured on a VPN zone. As far as I can tell, there are no blocks caused by the ZBW. All these interfaces have an ip nat enable on them. The NAT is pretty straightforward: one NAT pool with a single, valid IP address, and one overload entry for the tunnel IP range list to the NAT pool. I can see nat translations on the NVI output, but the access don't really get out - or back to the virtual interface. According to the router, packets are looped. gateway#sh int virtual-access 4 Virtual-Access4 is up, line protocol is up Hardware is Virtual Access interface Description: ** IPSec VPN ** Interface is unnumbered. Using address of Loopback1 (192.168.1.1) MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL Tunnel vaccess, cloned from Virtual-Template1 Vaccess status 0x4, loopback not set Keepalive not set Tunnel linestate evaluation up Tunnel source 200.200.200.201, destination 199.199.199.199 Tunnel protocol/transport IPSEC/IP Tunnel TTL 255 Tunnel transport MTU 1430 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Tunnel protection via IPSec (profile "vpn-ipsec-profile") Last input 00:00:03, output never, output hang never Last clearing of "show interface" counters 00:00:27 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 60 packets input, 3649 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out gateway#show policy-map type inspect zone-pair VPN-WAN sessions detail-debug policy exists on zp VPN-WAN Zone-pair: VPN-WAN Service-policy inspect : VPN-WAN-POLICY Class-map: allow-vpn-wan (match-all) Match: access-group name allow-vpn-wan_acl Inspect Number of Established Sessions = 6 Established Sessions Session 8B53B520 (192.168.1.241:56194)=>(8.8.4.4:53) dns:udp SIS_OPEN Created 00:00:04, Last heard 00:00:03 Bytes sent (initiator:responder) [492:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Session 8B53FEA0 (192.168.1.241:61480)=>(8.8.4.4:53) dns:udp SIS_OPEN Created 00:00:03, Last heard 00:00:02 Bytes sent (initiator:responder) [310:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Session 8B540920 (192.168.1.241:51652)=>(8.8.4.4:53) dns:udp SIS_OPEN Created 00:00:02, Last heard 00:00:01 Bytes sent (initiator:responder) [382:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Session 8B544120 (192.168.1.241:64433)=>(8.8.4.4:53) dns:udp SIS_OPEN Created 00:00:01, Last heard 00:00:00 Bytes sent (initiator:responder) [208:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Session 8B541020 (192.168.1.241:56194)=>(8.8.8.8:53) dns:udp SIS_OPEN Created 00:00:01, Last heard 00:00:00 Bytes sent (initiator:responder) [492:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Session 8B53AE20 (192.168.1.241:61480)=>(8.8.8.8:53) dns:udp SIS_OPEN Created 00:00:00, Last heard 00:00:00 Bytes sent (initiator:responder) [155:0] Initiator->Responder Window size 0 Scale factor 0 Responder->Initiator Window size 0 Scale factor 0 Class-map: INTERNAL_DOMAIN_FILTER (match-any) Match: protocol msnmsgr 0 packets, 0 bytes 30 second rate 0 bps Match: protocol ymsgr 0 packets, 0 bytes 30 second rate 0 bps Inspect Class-map: class-default (match-any) Match: any Drop 0 packets, 0 bytes gateway#show ip nat nvi translations Pro Source global Source local Destin local Destin global udp 200.200.200.200:51652 192.168.1.241:51652 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:53474 192.168.1.241:53474 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:53474 192.168.1.241:53474 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:55029 192.168.1.241:55029 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:55029 192.168.1.241:55029 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:55503 192.168.1.241:55503 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:55503 192.168.1.241:55503 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:56194 192.168.1.241:56194 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:56194 192.168.1.241:56194 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:59885 192.168.1.241:59885 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:59885 192.168.1.241:59885 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:61480 192.168.1.241:61480 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:61480 192.168.1.241:61480 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:64433 192.168.1.241:64433 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:64433 192.168.1.241:64433 8.8.8.8:53 8.8.8.8:53 udp 200.200.200.200:64603 192.168.1.241:64603 8.8.4.4:53 8.8.4.4:53 udp 200.200.200.200:64603 192.168.1.241:64603 8.8.8.8:53 8.8.8.8:53 Below are some of the output from the router console: Mar 4 15:15:44: %CRYPTO-6-EZVPN_CONNECTION_UP: (Server) Mode=CLIENT_OR_NEM_PLUS Client_type=CISCO_SW_VPN_CLIENT User=XXX Group=XXX Client_public_addr=199.199.199.199 Server_public_addr=200.200.200.201 Assigned_client_addr=192.168.1.241 Mar 4 15:15:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access4, changed state to up Mar 4 15:15:45: %IP-3-LOOPPAK: Looping packet detected and dropped - src=8.8.4.4, dst=192.168.1.241, hl=20, tl=103, prot=17, sport=53, dport=51652 in=Virtual-Access4, nexthop=192.168.1.241, out=Virtual-Access4 options=none -Process= "IP Input", ipl= 0, pid= 144 -Traceback= 814D03DCz 81CA21B8z 81C7921Cz 81C79360z 81C79904z 81C7A260z 81C73514z 81C73934z 81C7A7D8z 81C72AE8z 81C72D68z 81C72FD4z 81C732F8z 8068B538z 80672834z Configuration snippet following. Suggestions? interface Loopback1 ip address 192.168.1.1 255.255.255.0 zone-member security VPN interface Virtual-Template1 type tunnel ip unnumbered Loopback1 ip nat enable zone-member security VPN tunnel mode ipsec ipv4 tunnel protection ipsec profile vpn-ipsec-profile interface GigabitEthernet 0/0 ip unnumbered Vlan999 ip nat enable zone-member security WAN interface Vlan999 ip address 200.200.200.201 255.255.255.240 ip nat enable zone-member security LAN object-group network vpn_remote_subnets 192.168.1.0 255.255.255.0 ip access-list extended nat-list permit ip object-group vpn_remote_subnets any deny ip any any ip nat pool wan-ip-pool 200.200.200.200 200.200.200.200 netmask 255.255.255.240 ! single address for the NAT, netmask of the WAN interface ip nat source list nat-list pool wan-ip-pool overload

Alexandre Hautequest · ‎03-02-2017

object-group service DHCP udp port-object eq bootpc port-object eq bootps access-list inside_access_in extended deny udp object any object-group any object-group DHCP access-list outside _access_in extended deny udp object any object-group any object-group DHCP access-list phone _access_in extended deny udp object any object-group any object-group DHCP If you don't have a dhcprelay command, make sure your L3 SVIs on your switch doesn't have an ip helper-address entry.

Alexandre Hautequest · ‎03-02-2017

Monitor All; Inspection Exception - High (to downgrade applications listed as Very High risk) Inspection Exception - Med ( to downgrade applications listed as Very High/High risk) Inspection Exception - Low ( to downgrade applications listed as Very High/High/Medium risk) Inspection Very High risk (with applications listed as Very High risk) Inspection High/Medium risk (with applications listed as High/Medium risk) Inspection Low risk (with applications listed as Low risk) Inspection Very Low risk (with applications listed as Very Low risk) Default Action: Maximum Security Similar on the SSL policies: Monitor All; Do not decrypt (Manual sites) Do not decrypt ( Subject DN) Re-Sign Very High/High risk sites Default action: Do not decrypt And I can see the classification happening, with many sites on the Medium and lower risks still being inaccessible with a test network of one ASA and two clients.

Alexandre Hautequest · ‎03-01-2017

I'm on the same boat too, however with a slightly different setup for my lab. A 5506-X ASA 9.7(1) and FirePower 6.2.0.1. The HTTPS performance is mediocre past the SFR requests to ASA for packets to be dropped. Doesn't matter if the ASA+FP is managed locally via ASDM+IDM, or via FMC. Now, I noticed some of my Access Control Policies were a little too aggressive. For "Very High Risk" sites I made a "Maximum Security" IPS policy, for "High and Medium Risk" sites, a "Security over Connection" IPS policy, and so on. I had to make exception rules prior to those in order to lower specific higher risk sites to a lower IPS policy. That helped with a few packets being blocked for public services, ie Facebook, Twitter, Apple AppStore and Amazon Videos, however other sites classified as "Low Risk" or even Very Low Risk were still being dropped. Then there were a few sites I had to turn SSL inspection off. Sourcefire was such site I added a new DN object, otherwise the appliance would fail to update their own GeoLocation and Rules. My VMWare Horizon portal was too such a location I had to make a network object exception as the tunnel would not be validated because of the man-in-the-middle PKI. Even while I was only actively re-signing Very High and High Risk sites, and leaving everything else go their merry way. I have a TAC open, will see what Cisco replies back from this. Had to turn SSL Inspection off in order to open the TAC page to update my cases... However I'm still up to find out more about it from any fronts.

Date Registered	‎11-16-2010 11:15 AM
Date Last Visited	‎01-20-2019 03:37 PM
Total Messages Posted	68
Total Helpful Votes Received	10

ASA-x ROMMON upgrade for FTD/Sensors

some more hints

Re: How to keep NTP traffic internal

Re: How to keep NTP traffic internal

Re: How to keep NTP traffic internal

How to keep NTP traffic internal

I know this is a really old

I'm still working with TAC on

Well, yes, it works with

The tunnel is a basic EZVPN,

Uhm, not really able to get

Packet loop during NAT

object-group service DHCP udp

Monitor All;

I'm on the same boat too,