This is an information discussion for an apparent defect I experienced in the new ASA 9.7.1 Integrated Routing and Bridging feature released January 23, 2017.
Cisco ASA 5506W-X running new ASA 9.7 code to implement new Integrated Routing and Bridging feature. ASA configuration was working without problems running ASA 9.6.2 code using routing for each Ethernet interface. Upgraded to ASA 9.7 code to implement required Routing and Bridging feature to replace older remote (small location) ASA 5505 firewalls. To summarize, connectivity is working without problems for WIFI connected DHCP clients on the 5506W-X running 9.7 which use a full IPSec tunnel back to main data center. However, the problem is that the wired Ethernet DHCP clients on the 5506W-X, using the new Integrated Routing and Bridging feature cannot pass any traffic through the VPN tunnel. All traffic from the wired Ethernet DHCP clients get dropped with a VPN handle error message. So the wired connections fail in the packet-tracer going into the full VPN tunnel with a vpn-handle-error message as the packet enters the VPN tunnel step. This is a software defect in the new ASA 9.7 code.
Note if you configure Integrated Routing and Bridging on the inside ports with NAT on the outside ports (no VPN tunnel), just NAT, then I did not experience the problem.
Waited a long time for a new feature that doesn't work.
This is the 9.7.1 code from Cisco support release January 23rd, 2017. It is the first drop of the 9.7 code release and it TAC has accepted as a problem.
Just got my first 5506-x and ran into this same issue.
Simple site to site tunnel. Wired clients cannot pass traffic over the vpn. (using bridge group)
I can ping from the remote end to the inside interface address with the "management-access inside" command in place.
However, after that phase 2 session is up and running, I can actually crash the firewall by attempting to ping a wired client machine from the far end. Instant crash! Every time.
Thanks for providing the additional details about crashing the firewall. TAC finally got a 5506W-X to recreate this VPN-HANDLE-ERROR. It's a pretty sad reflection on Cisco code quality that a problem so obvious as a basic site to site tunnel was not identified in the 9.7.1 code tests prior to availability.
Was going to implement the 5506-X instead of the PA-200 units that we usually run for small offices since the 5506-X could setup a BVI. Ran into this same issue so there was really no point in attempting to implement a 5506-X at this point, the PA-200 gave me multiple routed interfaces.
Between the 6880 that we had come in with a bad iOS that didn't accept the modules purchased with the hardware, a bad module right off the bat, and now this, I'm not sure how much longer I'll push Cisco. The 'Cisco Tax' for a long time used to be worth it, now I'm not so sure.
VPN-HANDLE-ERROR problem as well as the ASA code crash mentioned below were easily re-created by the TAC so my initial TAC problem report was accepted as a defect a week or so ago. I was told that a fix for this defect would be available in 2 months, which I hope is true. The fact that Cisco development missed such a basic VPN function defect prior to release is certainly a big red flag.
Just so everyone is up-to-date, they released asa971-2-lfbff-k8.SPA yesterday and I installed it quick to test the new iOS. Sadly, while the memory leak is fixed so the asa doesn't crash, the vpn-handle-error is still very much present.
If I would have known about this right from the get go I probably would have just purchased another 5505.
Thanks for the update. We currently use 5505s as remote SOHO devices too but I need to purchase a bunch of additional SOHO remote firewalls. We wanted to go with the 5506W-X firewall but this VPN-HANDLE-ERROR is a show stopper. So either Cisco prioritizes fixing the VPN-HANDLE-ERROR defect or we're going to look at other vendors to find a newer generation firewall that actually works.
Thanks for adding the bug id to this discussion. Workaround is to remove the actual BVI1 interface. Great if you're using NAT, not so great if you're actually using VPNs on your firewall.
Just contacted TAC for this issue. Tech must not have been in the know, as he gave no ETA on when this issue would be resolved. His workaround was to create a port channel group for the interfaces instead of BVI. Haven't tested his "workaround" yet.
The port channel group workaround was discussed in (I believe in these Support Forums) way back when the 5506 was released without the L2 support the 5505 had. It's not the same, and from what I remember it did not work. It's now April 14th and I've not been able to get any feedback from Cisco on the estimated new date.
Hey all, unrelated to this exact issue but I have a 5515-X which I specifically loaded on the 9.7.1 release to utilise VTI IPSEC VPN tunnels. The tunnels come UP/UP but when you route data-plane traffic across them (ie actual data) the hardware appliance crashes with a page fault. Luckily for me, I have a HA pair of ASA's, so the 2nd one took over but then unfortunately for me immediately crashed with the same page fault error.
Leaving the tunnels up/up but not routing any traffic across them does not exhibit a page fault crash.
TAC advised me that they were already aware of this issue with an internal-only bug ID: CSCvc35378
This is fixed in 9.7.2 which I am now using. Does IRB work in 9.7.2?
What annoyed me is that the release notes did not mention that VTI tunnels aren't actually functional in 9.7.1, as the bug ID is internal to Cisco only this doesn't help me and resulted in a outage and potential loss of earnings.
i have also tried using the new BVI in routed mode, it works fine as long as you only nat from inside to outside dynamic, but as soon as you enter ANY nat exemption, which you will need for VPN, you get a nice traceback and crash essentially rebooting the ASA.
For a long awaited feature to replace the old 5505, that sure is a bummer.
Cisco... REALLY? How could this have been overlooked?
Was told by Cisco that the VPN-HANDLE-ERROR gets fixed in the ASA 184.108.40.206 release in mid-April. Hopefully this is a real commitment and not a "hope to get fixed".
I'm scheduled to deploy to two remote offices by then, and we would like to utilize the equipment that all remote offices will be updated to. Because of this, I'm not sure I'll even be able to recommend a Cisco product for it; saying that we should utilize something that should maybe be fixed in a month, but maybe not, isn't really going to go over well with management.
Cisco TAC confirmed that the VPN-HANDLE-ERROR defect has been fixed. It is scheduled for interim release 220.127.116.11 to be posted on April 14th, 2017. As per Bug ID CSCvd18126 description it is fixed in the following releases:
Known Fixed Releases: (5)
Wow. I just wasted a day because of this.
When I saw the mess of NAT statements it makes on a default config, I did wonder whether VPN may be affected at all. And then set it up and had the same 'ping of death' that everyone else is getting.
I'm completely amazed that no-one at Cisco wondered the same thing? They even made it the default configuration ffs.
Isn't branch office vpn endpoints what everyone uses these things for? How on earth do you miss that?
I just loaded 9.7(1)4 since it was released this weekend. Issue is still present so here's to hoping that the 9.7(1)5 actually is released on the 14th and actually fixes this.
Thanks for the update on 9.7(1)4. I'm hoping for the 9.7(1)5 release on April 14th to fix the VPN-HANDLE_ERROR but 1 week between interim releases seems short. We'll see...
I opened up a TAC case today and was told that
"The interim version i.e. fix for the bug id CSCvd18126 (18.104.22.168) would be released hopefully by the end of this week."
Thanks for the update. I also got an update from the TAC Engineer who said the VPN-HANDLE-ERROR fix is still scheduled to be within 22.214.171.124 but that release has been delayed and the delays are usually days.
I haven't tested it yet but "iai-admins" just posted that 9.7.1(8) was released and it fixed the "VPN-HANDLE-ERROR" defect. Checkout "iai-admins" post.
I'm running 9.7.1(8) now and the vpn is working.
Here are my only remaining issues with the bridge group configuration.
1. If I configure an "inside" bridge group and also an "inside2" layer 3 interface (non bridge group), I can't get dhcp to work on that inside2 interface after configuring the appropriate dhcpd commands. I can however use the "management-access inside2" command to ssh to the device thru the tunnel to the inside2 ip address.
2. If I configure an "inside2" bridge group instead, dhcp for inside2 interfaces works fine, but I cannot ssh to the inside2 ip address over the tunnel as the command "management-access" does not give you the ability to select bridge group interfaces in the command. For instance I cannot enter "management-access inside2".
So it is more like a quick fix for the VPN Problem but leaves other issues open - again - .
Well Cisco, are you reading this? How come that recently updates to the ASA platform are so messy?
QA anyone? i'm yelling timber on this issue.
(And the issues with the wizard/asdm NAT error has been there for a while now. AAMOF, there are numerous problems with ASDM and NAT configuration. Come to think about there are actually quite a few errors in ASDM. But that is another subject)
(Secretly wishing JAVA would just go away - forever)