Heard that 9.7 is planned to be released tomorrow. Word is that it will support VTI tunnels (Like IOS) :) I hope it works, this will simplify my network so much!
At the moment I'm passing IPSEC through my ASA-X to an inside Cisco 2921 router specifically for the VTI tunnels. I run OSPF across multiple tunnels to allow fast failover. Downsides to this is that the ASA-X cannot see this traffic and so my layer 7 inspection (antimalware, IPS etc) does not work for VPN traffic. I also have some static routes configured to make this work :( but these static routes do not break anything (like failover) they just tell my core routers where the loopback IP's are (VPN terminates on a loopback on the 2921).
See told you it was a little bit complex.
:awesome:
Can't wait for ASA 9.7 - bug free!
That's big news if true. I've seen deals go to the competition due to route based vpn feature requirement
Quote from: wintermute000 on January 18, 2017, 02:32:35 AM
That's big news if true. I've seen deals go to the competition due to route based vpn feature requirement
Indeed. Probably why they brought in the feature.
Now we need to research the upgrade path from 7.2 to 9.7 for some of our more abandoned firewalls...
Hahahahahaha enjoy. Total syntax rewrite time.
Quote from: wintermute000 on January 18, 2017, 02:57:43 PM
Hahahahahaha enjoy. Total syntax rewrite time.
maybe we'll get our 2 yeas old feature request...Two factor authentication into ASDM. That'd be great....
Quote from: wintermute000 on January 18, 2017, 02:57:43 PM
Hahahahahaha enjoy. Total syntax rewrite time.
May even have to replace the hardware running the 7.2 code... we shall see...
Quote from: deanwebb on January 19, 2017, 10:20:31 AM
Quote from: wintermute000 on January 18, 2017, 02:57:43 PM
Hahahahahaha enjoy. Total syntax rewrite time.
May even have to replace the hardware running the 7.2 code... we shall see...
or at least upgrade the memory, but I think the hardware is EOL so there is not memory available to upgrade to.
Code still isn't out so either my TAC engineer is telling porkies or the usual delayed releases from Cisco.
Quick question about 2-factor auth. Back in the UK we were using RSA tokens which cost like 1500 pounds for just a few tokens. Later on I saw some software tokens installed on blackberries.
Google has something similar, whilst daydreaming in a meeting earlier this week I had a though, could we use 2-factor auth. using the Google thing? I plan on setting this up for us for our AWS accounts.
Delayed release. Everyone expected it today.
And software tokens do the same thing as hardware tokens. It's just that hardware tokens are something to use that's not on the device in order to provide security.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html
Finally they've introduced support for Layer 2 switching on the 5506! That's been a real bugbear of mine!
New default configuration for the ASA 5506-X series using Integrated Routing and Bridging
A new default configuration will be used for the ASA 5506-X series. The Integrated Bridging and Routing feature provides an alternative to using an external Layer 2 switch. For users replacing the ASA 5505, which includes a hardware switch, this feature lets you replace the ASA 5505 with an ASA 5506-X or other ASA model without using additional hardware.
The new default configuration includes:
outside interface on GigabitEthernet 1/1, IP address from DHCP
inside bridge group BVI 1 with GigabitEthernet ½ (inside1) through 1/8 (inside7), IP address 192.168.1.1
inside --> outside traffic flow
inside ---> inside traffic flow for member interfaces
(ASA 5506W-X) wifi interface on GigabitEthernet 1/9, IP address 192.168.10.1
(ASA 5506W-X) wifi <--> inside, wifi --> outside traffic flow
DHCP for clients on inside and wifi. The access point itself and all its clients use the ASA as the DHCP server.
Management 1/1 interface is Up, but otherwise unconfigured. The ASA FirePOWER module can then use this interface to access the ASA inside network and use the inside interface as the gateway to the Internet.
ASDM access—inside and wifi hosts allowed.
NAT—Interface PAT for all traffic from inside, wifi, and management to outside.
If you are upgrading, you can either erase your configuration and apply the default using the configure factory-default command, or you can manually configure a BVI and bridge group members to suit your needs. Note that to easily allow intra-bridge group communication, you need to enable the same-security-traffic permit inter-interface command (this command is already present for the ASA 5506W-X default configuration).
Looks like the VTI is in there too :)
Virtual Tunnel Interface (VTI) support for ASA VPN module
The ASA VPN module is enhanced with a new logical interface called Virtual Tunnel Interface (VTI), used to represent a VPN tunnel to a peer. This supports route based VPN with IPsec profiles attached to each end of the tunnel. Using VTI does away with the need to configure static crypto map access lists and map them to interfaces.
We introduced the following commands: crypto ipsec profile, interface tunnel, responder-only, set ikev1 transform-set, set pfs, set security-association lifetime, tunnel destination, tunnel mode ipsec, tunnel protection ipsec profile, tunnel source interface.
Niceeeee
I saw this come out earlier this week. I am on leave from Tuesday so I've halted big changes. I'll dive into this when I come back in a few weeks because it will make my life easier! And hopefully by then all the bugs will have been reported and resolved :)
About the L2 switching :zomgwtfbbq:
So "same security traffic intra interface" doesn't work on the 5506? I have set up tons of 5505's and own one myself. No problem with l2 switching there :-s (unless it's really routed internally and I am unaware?)
What is the issue with the 5506?(Or rather what was the issue? )
Hey Dieselboy, the 5506 (until 9.7) doesn't support any L2 switching at all. Crazy, I know! I made the mistake of ordering 3 for a project and it wasn't until implementation that I found out. Do a quick google and you'll see a lot of people complaining about it which I why I guess they've introduced IRB into the new code. Who the hell needs 8 x 1Gbps L3 ports on a SOHO device!? :|
Quote from: DanC on January 28, 2017, 05:17:09 PM
Who the hell needs 8 x 1Gbps L3 ports on a SOHO device!? :|
GAMERZ DOIN IT RITE W/ SRS BSNS
:professorcat: :matrix:
I configured VTI tunnel yesterday evening and I can ping between a 2901 ISR and ASA5515-X using a VTI tunnel.
Only BGP and static routes are supported on the ASA so I decided to use static routes.
Once traffic started flowing across the tunnel, the primary ASA Crashed, so the secondary ASA immediately took over and then crashed. Both are registering page faults and listing exact filepaths to the OS like:
Thread Name: DATAPATH-0-1956
Page fault: Address not mapped
Because of how this failed, I think it might be caused by some other config on the ASA pair. IPv6 VTI tunnel is not supported but I do have IPv6 running on the wan interface, I'm wondering if this might be the problem.
As this is a HA pair I configured the VTI tunnel with the "standby" IP. I'm not sure if this is the problem and whether standby IP is not required for VTI tunnel.
Currently the TAC case is stuck with a guy in the US who's off shift. /Annoying. I thought I would of had a quick response on this one, considering I logged the case with:
3 x A4 pages of initial case notes, explaining exactly what I done, what happened and what the desired outcome was. Software versions and the setup / design. What I require from the TAC case (expected outcome). I also mentioned the above points about IPv6 and the standby IP as concerns / possible considerations for cause.
1 x high-level diagram to help explain the long case notes
all four crash dumps from both ASA's
the backup of the asa configuration export
The console output at the time of the crash
What did I miss? The engineer did come back with "did you get a tech support". So I'll do that.
DID YOU GET TECH SUPPORT???? HE ASKS THAT????
:kiwf:
That's not tech support, that's panic in the face of a tricky issue, totally unacceptable. Do you have a channel you can use to escalate the issue and get it reassigned? We had to do that on one really messy call when the TAC guy basically tried to push everything back on us and finally made his last mistake when he took a comment I made out of context and canceled a request to send out a test device to the affected site.
And then went on vacation 30 seconds after canceling the request.
:rage:
TAC got back to me today. They advise that 9.7.1 will crash when traffic is routed across the VTI tunnel.
The issue is fixed in 9.7.1.2 which is not yet released.
:o
Here's the email chain
Quote from: TACH Tony,
The issue seems to be matching an internal bug which should to be fixed in 9.7.1.2.
The issue seems to trigger during route-look up followed by tmatch_domain_lookup due to invalid meta L3 type changed while processing the traffic from cp to dp.
Quote from: DieselboyHi [name deleted],
Thanks for the update. Is this issue affecting only VTI? IS there any immediate workaround?
I only updated to this release to utilise the long-anticipated VTI tunnel on the ASA, does this feature work in 9.7.1 at all? I gather from your email that VTI although present and available to configure, it's not actually functional. I'm trying to discover whether this issue is related to my configuration in whole on the ASA or due to the code itself.
Many thanks,
tony
Quote from: TACHi Tony,
Yes this issue occurs when the traffic goes through VTI tunnel on ASA. There is no work-around as of now. Upgrading to 9.7.1-2 should have the fix for the issue.
PS, ASA code asa971-2 came out on 28/02/17 and it's located under the "interim" section.
Hey, you know that really nice new feature people have been asking for for 10 years? We added it! P.S. Don't use it, you will crash the system.
-Otanx
CISCO: We got VTI! It's great, it works!
Customers: :vendors:
Eesh. :(
IKR! There used to be a time where network engineers had peace of mind, they would configure something and it worked (99%) of the time.
Now, I'm finding that most of the time if you configure something, it's not going to work.
Basically, cannot live without support contracts.
got the bug ID for laughs?
No, still waiting on it! As soon as they provide it I'll post it here. It's an internal only bug, TAC says. I hate it when they do that! I checked the release notes and didnt see any issues hence I began planning to use that code. Then BAM! Total outage.
always a risk to go bleeding edge unless its to squash a critical vulnerability!
terrible luck on your part though, I mean WTF a critical bug on the headline new addition.
Had that happen to me with my NAC product... brand new features, lovely stuff, and then changing a setting in one place puts a default "deny all" condition on our corporate wireless...
:whatudo:
Bug ID: CSCvc35378
Apparently they are working on making it externally visible.
Quote from: Dieselboy on March 02, 2017, 01:04:56 AM
TAC got back to me today. They advise that 9.7.1 will crash when traffic is routed across the VTI tunnel.
The issue is fixed in 9.7.1.2 which is not yet released.
:o
Here's the email chain
Quote from: TACH Tony,
The issue seems to be matching an internal bug which should to be fixed in 9.7.1.2.
The issue seems to trigger during route-look up followed by tmatch_domain_lookup due to invalid meta L3 type changed while processing the traffic from cp to dp.
Quote from: DieselboyHi [name deleted],
Thanks for the update. Is this issue affecting only VTI? IS there any immediate workaround?
I only updated to this release to utilise the long-anticipated VTI tunnel on the ASA, does this feature work in 9.7.1 at all? I gather from your email that VTI although present and available to configure, it's not actually functional. I'm trying to discover whether this issue is related to my configuration in whole on the ASA or due to the code itself.
Many thanks,
tony
Quote from: TACHi Tony,
Yes this issue occurs when the traffic goes through VTI tunnel on ASA. There is no work-around as of now. Upgrading to 9.7.1-2 should have the fix for the issue.
That sucks! I labbed it out on ASAv a couple of days after the code was released and it seemed to work okay in basic form with BGP and a spoke CSR1000v. Glad I didn't take it much further!
Quote from: Dieselboy on March 07, 2017, 01:35:00 AM
Bug ID: CSCvc35378
Apparently they are working on making it externally visible.
Can't see it externally yet :(
Looks like the IRB doesn't work properly either:
https://supportforums.cisco.com/discussion/13221411/vpn-handle-error-new-asa-971-integrated-routing-and-bridging-feature
IRB doesnt even work??? What an effing joke! :o
Who understands Law here? The reason I ask is that if I sold someone a car and knew that said car had no brakes but I still sold the car and allowed the unsuspecting buyer to drive away in it, then had an accident due to the fault; this is negligence on my part. Why are Cisco releasing software that they know does not work? And not just that, they are releasing software specifically for a new feature "hey come use our new feature!" but they know it doesnt work, they have an internal bug ID for the purpose of eventually fixing the issue in a later software release. All the while customers are using this software in their designs and running into problems.
Hope everyone logs tac cases so when they reveiw their stats, they can all have a bored meeting and say "ah-ha! If only we had done this properly the first time!"
Yes, bored meeting. ::)
Check the EULA... what if you bought a product in perpetual beta?
:kramer:
Yeah, I thought you'd react that way. Lots of interesting things are in those EULAs.
:eek: >:D :'(
Just another FYI - seems like "TCP state bypass" might have some issues.. My VTI VPN is working but guys in Sri Lanka are getting weird timeouts when trying to connect to stuff. They keep trying and it works. Issue is random, seemed like TCP port exhaustion. Looks like an embryonic timeout is coming into play even though I've set tcp state bypass for traffic flowing through the ASA which matches my site to site subnets.
I have a TAC case open to confirm my tcp state bypass should also mean the embryonic timeout does not come into play. I now have this timeout set to unlimited on the service policy and the issue has gone away (at the moment, but it's barely been 24 hours). I'm still deciding on whether to re-produce the problem to gather the inspections / captures to dig deep.
Soooooo... if I hear you correctly... you're saying.... DON'T upgrade to 9.7?
:problem?: <- Your TAC guy will make this face
:rage: <- or this one
when you call in with that call that starts with "I just upgraded to 9.7, and..."