ASA 5505 to 5506 replacement - using the 5506 with bridged (switched) ports and vpn 9.8.x

Michael Braun · ‎07-11-2017

Hi guys,

it has been a pain and a year long ongoing process to get Cisco to implement (sorta) switched ports into the ASA 5506.

Most of us probably use the 5505 for small branches due to the fact it has a built-in switch.

Now while we were all exited to get our hands on the new 5506 when it finally came out, we also ran into a huge problem. It did not have any switched ports. Jars dropped - worlds crushed.

While it was pretty neat to have routed interfaces, no small branch would ever need that. Instead most are probably using the convenient switch ports on the 5505 - actually, that was a big selling point to not have to buy a separate switch.

So all our dreams crushed and shattered (the following s..storm to Cisco WTH???), all our ASA5505 still have to stay in place or worse (or not) switch to a different vendor. Some of us may have had no choice as they had to be replaced or demanded so by the customer.

I decided to convince my customers to hang in there, making promises that Cisco will release an update so that the new ASA will have switching ports as well. AND we waited and waited and nothing seemed to happen. Cisco forgot all about the little guy, forgot that all the hundreds of branches are essentially connected to the HQ, also running the big guy version of the ASA.

Then once again, we saw the end of the tunnel with the release of v9.7.x, OMG bridge groups ! Something routers had for , I don't know, EVER maybe?

Well anyway, switching on the 5506 seemed so close, will our dreams come true - finally?

Quick, get me a 5506, I have got to do this NOW... and tell everyone that we have switching capacity on the ASA now !!! It works oh my good, I can ping two pc's through two interface connected with a bridge group.

There it is there it is - lets get going and do VPN... oh wait... VPN Handle Error, code crash oh no, I am dead. As I sit here in tears of joy of switching ports, NAT and VPN killed the beat.

Cisco Cisco on the wall, can you not get the code straight for us all.

Well, months have passed , the world moved on, we will remember out hero as he has been lynched by his customers for not delivering switching ports as promised.

But leaving this all behind us, it is now the glory of 9.8 that will get us to where we want to go.

And this is what everyone has been waiting for - switching ports (well sorta not really), vpn and nat without crashes (so far).

And how in the world do I get this darn thing running like a 5505?

While it was pretty straight forward with the 5505, the 5506 seems to be a bumpy curvy road around a mountain top.

But enough of the tales of our demise, here is watcha gotta do...

First, make yourself a bridge group interface:


interface BVI1
 nameif inside
 security-level 100
 ip address 10.4.83.1 255.255.255.0

#(feels good right?)

now add your routed interfaces to the bridge-group...

interface GigabitEthernet1/2
 bridge-group 1
 nameif inside2
 security-level 100
!
interface GigabitEthernet1/3
 bridge-group 1
 nameif inside3
 security-level 100
!
interface GigabitEthernet1/4
 bridge-group 1
 nameif inside4
 security-level 100

and so on...(getting funky)

NOTE1: yes you need a name (and no they can't all be named the same, so I used numbers) and YES they need to be in the same security level

NOTE2: IN CASE you want to or need to change the bridge-group assignment, you have to "no nameif" first, change the BG and do "name if" again.

Additional Note 2.1: Funny thing, while removing the nameif - all your rules referencing to the now gone interface - lol - are gone too
So... copy the missing stuff back from the startup-config and i hope you did not save in between or at least had a copy in notepad.

NOTE3: with the ASDM, it will complain that it can only have 4 interfaces in a bridge group - apparently that is a lie, cause with the shell, it works.

(If you do not use nameif, the interface will simply not come up)

NOTE4: Of course now you have to allow inter interface traffic as well:

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

Whoohoo, I can ping... but not to the outside...yet

No, you can not simply NAT to the BVI (Cisco ?? Really?)

Instead, you have to NAT/PAT ALL of your physical interfaces...

e.g. with "before NAT rules"

nat (inside4,outside) source dynamic any interface dns
nat (inside5,outside) source dynamic any interface dns

or Object NAT rules - however you like it better (at this point I assume you are familiar with how NAT on the ASA works)

ok ok, here...

object network NAT_OUT_DYN_I6
        subnet 0.0.0.0 0.0.0.0
        nat (inside5,outside) dynamic interface dns

Lazy version that is.

NOTE: You HAVE to use interface names, (ANY,OUTSIDE) does NOT work.

So yes for all "switched" interfaces you need a dynamic pat rule - if you want to get out of the matrix, uhm outside interface I mean.

Same difference, VPN

nat (inside4,outside) source static NETWORK_OBJ_10.4.83.0_24 NETWORK_OBJ_10.4.83.0_24 destination static VPN_TO_HOME VPN_TO_HOME no-proxy-arp route-lookup
nat (inside5,outside) source static NETWORK_OBJ_10.4.83.0_24 NETWORK_OBJ_10.4.83.0_24 destination static VPN_TO_HOME VPN_TO_HOME no-proxy-arp route-lookup

ALL you NAT are belong to us.

Ok, Scotty, just don't forget about the access-list, and you probably guessed - for EACH interface.

So overall, it is a really big hassle to do it since configuration is multiplied by the number of interfaces you have in the bridge-group.

On another note, with the last ASDM I tested this funky bridge-group stuff, half is not working right or doing something the shell does not understand - so watch the output before you send it, chances are it is not correct, especially anything with NAT or NAT-EXEMPT

Also, if you want to access your ASA.... yeah really it is just like that.....

ssh 0.0.0.0 0.0.0.0 inside2
ssh 0.0.0.0 0.0.0.0 inside3
ssh 0.0.0.0 0.0.0.0 inside4
ssh 0.0.0.0 0.0.0.0 inside5
ssh 0.0.0.0 0.0.0.0 inside6
ssh 0.0.0.0 0.0.0.0 inside7
ssh 0.0.0.0 0.0.0.0 inside8

and for telnet and for http...

or use the management interface if you can - unless you use Firepower ...little treacherous firewall...

This should cover the base, getting the 5505 replaced by the 5506.

We switched, we PAT/NAT and we's VPNed.

Should take care of most 5505 setups out there.

Thanks for reading now get out of the basement and plant a tree or do something useful instead of wasting away in front of putty.

Cheers

Markus

p.s. This config was NOT tested with Firepower Services installed so i have no clue how those two will react to each other considering how "abstract" the config looks like. Somehow i have doubts Cisco did some tests with it either....

Michael Braun · ‎07-11-2017

..and of course there has to be something that does not work...

DHCP RELAY

can't enable it on any of the bridge-group interfaces nor on the BVI itself....

johannes88 · ‎07-12-2017

Thank you for the comprehensive description, for both the WHAT and especially the HOW!

cheers

Johannes

Michael Braun · ‎07-12-2017

You are very welcome, in case you run into additional issues, please post them here too.

I have only one setup right now that requires bridged ports and it is not due for installation for another two weeks - if that.

Markus

Philip Vilhelmsson · ‎07-20-2017

Thank you verry much! I've spent 2 hours trying to figure this out. I couldn't understand why I wasn't able to do a simple "nat(inside,outside)..." So one rule per interface it is then.

Michael Braun · ‎07-20-2017

Welcome, we all have been wondering that i am sure.

Let's just hope in the future this will be changed so that the BVI interface actually gets to do what it is ment to do.

Although, i recently tested the new Firepower Device Manager (its the one supposedly replacing the ASDM) and it works the same way except, the Web Interface does the work for you.

Worst of all, no more console access with it. So it is one thing to stay away from as far as possible.

Markus

MCITadmin · ‎10-04-2017

Thank you for that information! That is probably the config I should have used but I went a different route and I am finding I have issues with Port Forwarding. I am going to change my NATing to your example above. Did you get a chance to mess with port forwarding with your NAT for the interfaces set up the way you have them?

Thanks!

Brett

ScottyMac · ‎02-24-2018

Hi did you get the port forwarding to a bridge-group inside-server working? I've tried everything but the packet trace gets to un-nat and matches the correct rule and shows the proper host and port target - but then chokes with a "no valid adjacency, route failed to find next hop" Forwarding to a single inside interface, even logical ones, works fine. If anybody could post a working config example of this i would be much indebted...

ScottyMac · ‎02-24-2018

got it! "nat (outside,any)" changed to a bunch of "nat (outside, inside_1)"
this was the key to the solution. turns out that even though you can have a few ports "bridged" you still have to repeat the nat rules specifically for each physical interface - both the inbound nat and outbound pat rules. imho one should be able to setup nat rules against just the bridge-group logical interface, as it is with any other logical interface. cisco should then internally span those rules to each physical interface that is part of the bridge group on their own behind the scenes.

MCITadmin · ‎10-04-2017

Thank you for that information! That is probably the config I should have used but I went a different route and I am finding I have issues with Port Forwarding. I am going to change my NATing to your example above. Did you get a chance to mess with port forwarding with your NAT for the interfaces set up the way you have them?

Thanks!

Brett

Fee · ‎11-10-2017

Hiya,

Can you advise if this will work in the same way for 2 outside interfaces being added to a BVI? I have a few ACL entries for incoming traffic outside and NAT's on my 5506-X and need to implement a solution for a Primary and secondary outside connections on the same subnet.

Thanks in advance

Fee :-)

ScottyMac · ‎02-24-2018

Hi thanks for the info - i wish i would have seen this "for each interface"quirk from the start, i would have many less grey hairs. I've got most of my bridge-group dreams figured out except for one item: port-forwarding to an inside-server in a bridge group. The packet trace gets to un-nat and matches the correct rule and shows the proper host and port target - but then chokes with a "no valid adjacency, route failed to find next hop" Forwarding to a single inside interface, even logical ones, works fine. If anybody could post a working config example of this i would be much indebted...

ScottyMac · ‎02-24-2018

got it! "nat (outside,any)" changed to a bunch of "nat (outside, inside_1)"
this was the key to the solution. turns out that even though you can have a few ports "bridged" you still have to repeat the nat rules specifically for each physical interface - both the inbound nat and outbound pat rules. imho one should be able to setup nat rules against just the bridge-group logical interface, as it is with any other logical interface. cisco should then internally span those rules to each physical interface that is part of the bridge group on their own behind the scenes.