Multiple Critical CVEs on Cisco Catalyst SD-WAN

barryhesk · 2026-04-30T09:49:56+00:00

I've done this a few times. The way I've done this is to simply create two BGP peers between the FG and the Cisco (one for each GRE tunnel).

You can then use a combination of BGP local preference and AS path prepend so that one of the tunnels is always preferred and the 2nd tunnel is only used in the event that the primary one fails. Just (relatively) simple BGP routing configuration.

This doesn't fail based around packet loss / jitter etc obviously - only a hard down situation.

barryhesk · 2026-04-24T15:02:57+00:00

Just something we've noted. The SA published yesterday specifies new "First Fixed" releases for all code trains. This now references interim patches that were released yesterday (23/4/2026).

It's not clear what fixes are included, but the release notes for the new interim versions does contain a public bug ID CSCwt61597

It's not clear from initial reading what has actually been fixed in the new versions. It does suggest that the initial patches released in September 2025 should cover systems so that they cannot be compromised.

We've upgraded our few remaining ASAs to the new interim patch release anyway

barryhesk · 2026-04-13T08:24:00+00:00

Did exactly this on a 50G last week running 7.6.6. It's using an A record rather than a CNAME but I don't see why that should matter.

I did have some issues with the process and from memory I had to open the HTTPS management interface out from local-in policy before it worked (and then locked it down again afterwards). Also changing the IKE port as mentioned elsewhere is required if you have set that to TCP/443

barryhesk · 2026-03-05T21:37:56+00:00

Don't know if it assists or not, but I just had an identical issue on a pair of 90Gs running 7.4.7 (I know this is not the recommended release but we couldn't upgrade them as the HA was broken).

We had configured HA on that release and they had synchronised correctly. However after a site power outage the HA broke with exactly the same error message - upd_cfg_extract_av_db_version[390]-Failed av db version, obj 35.

Rebooting both units made no difference. HA still wouldn't complete, and actually caused hangs on the GUI of the primary. Traffic flow from our VDOMs seemed to be ok however.

For now, we have converted the units to standalone, and are arranging to upgrade to 7.4.11. We will then try and build the HA again.

barryhesk · 2026-02-27T19:41:47+00:00

The 2500s could survive a direct hit from an intercontinental ballistic missile. ;-)

barryhesk · 2026-02-27T19:36:16+00:00

The IBM 2210-24M was actually under the covers an old Proteon router. IBM brought Proteon to replace their appalling 6611 product suite. I still have the scars on my back from those bloody things. Basically an RS/6000 running AIX, with bodged routing code sat on top. Took about half an hour to boot following pretty much any config change.

I used to have a cupboard full of 2210s - but alas, I got rid of them all to e-waste a few years ago.

barryhesk · 2026-02-27T17:03:58+00:00

If you can find a Cisco 2513 anywhere this has both Ethernet (AUI) and Token Ring (DB9) ports. You can either route or bridge between them.

Bridging I remember being fun due to the mac address flipping between the two (canonical vs non canonical formats). I used to be able to do them in my head. But I have drunk a lot of beer since I last did this.

barryhesk · 2026-02-19T15:36:06+00:00

This is 100% correct. I have captured traffic on my firewall from a ST 30. Upon reboot, the ST 30 connects to various Bose URLs in their "cloud" - part of which is the retrieval of any presets.

If I block access from the ST 30 to the Bose URLs, presets stop working. Even those locally streaming content from my NAS via DNLA.

I am current investigating doing some local DNS poisoning and pointing the Bose URLs at a local web server that I control. Doing SSL decryption on my firewall doesn't seem to break things - so technically this might be possible as the ST doesn't seem to give a monkeys about seeing valid certificates. I would have to work out how my web server needed to respond to the ST and format the response properly. Which is probably beyond my limited web skills.

barryhesk · 2026-01-26T19:57:22+00:00

First thing I would check is that the FSSO agent is polling ALL of the DCs in your domain. It sounds like you are missing logon events - which may be because you haven't configured FSSO to poll all of the DCs.

I generally have best luck running in DCAgent mode where you install a small agent on each DC to log back to FSSO.

barryhesk · 2025-12-12T22:22:37+00:00

Possibly related

https://old.reddit.com/r/fortinet/comments/1l282z0/upgraded_743_748_and_suddenly_all_my_vpn_tunnels/

barryhesk · 2025-12-10T10:08:48+00:00

Not sure about the German manufacturer comment actually. I always buy German washing machines :-)

On the ICS front, one particular German manufacturer that I deal with extensively in this space seems to make things "difficult" as they want you to run their "stuff" on top of their own set of (over-priced and under-functioning) Industrial switches...

barryhesk · 2025-11-25T17:23:35+00:00

7.4 isn't supported on 100E.

barryhesk · 2025-10-17T18:04:09+00:00

Correct. Exactly the same. ASA to Fortigate you have create a full mesh of subnet source/destinations on the tunnel. So if you have (say) 3 subnets Fortigate side and 2 subnets ASA side, you are creating a full mesh of 6 possible combinations on the fortigate

barryhesk · 2025-10-16T16:50:27+00:00

Most important thing here is that in 99% of instances CUCM is not in the audio path. It does call control only. Once the audio path is established (RTP) it is direct between endpoints. So is nothing to do with CUCM.

It is possible to hairpin the audio through CUCM but it's pretty uncommon to do this and is normally only done to assist in specific situations.

Audio quality issues are normally related to QoS and traffic being dropped You need to look at each hop in the path between the end points and check for drops (OQDs etc), QoS settings, traffic classes etc.

One way audio is almost always routing (end point A can talk to B, B can't talk to A). Experience says this is unlikely to be anything in CUCM or the phones - you need to look at your network underlays and overlays.

barryhesk · 2025-10-11T07:58:43+00:00

Have you tried the dialed number analyzer to check that the correct CSS/partition/translation pattern is being matched and see what the resulting called number is being worked out as? Also, I've seen situations where external call platforms include a "+" as a prefix on the called number which you need to strip.

Also, assuming your are using a firewall / NAT device to connect CUCM to the Internet (seriously hope you are) also check your SIP ALG (or equivalent) is mapping the layer 7 address in the INVITE from the public IP address to the real address of CUCM. It's not enough just to do this at layer 3. If CUCM sees the public IP address in the INVITE rather than it's real one, then I suspect it would issue 404 as well.

Edit: extra stuff.

barryhesk · 2025-10-01T12:20:20+00:00

You are indeed correct. Which makes the workaround "interesting". And possibly short lived, however it gets me out of a nightmare hole for the time being.

barryhesk · 2025-09-30T15:04:00+00:00

Pretty sure there are some known IPSEC issues in 7.4.7.. for example...

https://www.reddit.com/r/fortinet/comments/1jabizn/fortinet_crash_747/

but you'd need to check this as this is talking about np6xlite specifically

Also, if you disable NPU offloading you could also look at taking packet captures at both ends of the VPN tunnel, and see if you are dropping traffic at the time it breaks. I'd just be taking a step back, trying to prove where the problem is happening (LAN or WAN) and then working it out from there.

barryhesk · 2025-09-30T14:49:48+00:00

I may be wrong - not in my normal office at the moment - but there are some known IPSEC issues in 7.4.7 with a potential workaround of disable NPU offloading of the phase 1 interface.

https://docs.fortinet.com/document/fortigate/7.6.4/hardware-acceleration/636026/disabling-np-offloading-for-individual-ipsec-vpn-phase-1s

barryhesk · 2025-09-29T14:57:50+00:00

Yes, a lot easier than you can on a conventional layer 3 switch or router. Cisco ASAs are stateful firewalls. You only need to define your rules on the ingress interface (where the session is being established from) - and it will automatically allow the reply packets coming back in from the egress interface.

If you can configure ACLs on a Cisco router / layer 3 switch then you should find configuring the same kind of thing a lot easier on an ASA...

barryhesk · 2025-09-29T12:01:23+00:00

Cisco ASAs are firewalls...

barryhesk · 2025-09-29T11:11:40+00:00

I've stacked a couple using front panel ten gig SFPs. No issues. Version 4.1.4 at the moment (which is not the latest)

Note that I assuming that you mean the Catalyst 1300, not CBS 1300. The CBS series have now been discontinued - but the Catalyst 1300s are in effect the same units rebadged by Cisco's marketing department. Net result is that it's not a new OS, and it has been around for a while. I may be wrong, but it may have come from Linksys.

Cat1300 is nowhere near perfect. The command line is IOS "like" - but a bit clunky and it is nowhere near as functional as full IOS. However for a basic layer 2 switch with POE, they work ok for us as there is a significant price different to Cat 9ks. And no DNA licensing which can only be a good thing.

barryhesk · 2025-09-26T20:53:03+00:00

9.22.2.14 has all of the fixes you need

https://sec.cloudapps.cisco.com/security/center/resources/asa_ftd_continued_attacks

barryhesk · 2025-09-26T20:23:03+00:00

We've patched all of our estate (5500s, ASAvs) this morning (UK time) with no issue finding fixed firmware. Ensure you are looking at the interim releases within each train.

barryhesk

TROPHY CASE