Meraki MX is one of the best selling products in Meraki history. Last year my team sold more MX than ASAs.
That said, customers commonly want to know about AnyConnect support for Meraki MX.
It simply isn’t there today….check out my video below on the use case of using Meraki MX + ASAv (Anyconnect VPN concentrator).
What a fun day! Thanks to all who attended my session at the Northern Ohio Security Summit “TRUE CRIME – the first 48 hours in your network” it was a packed house!
As promised, here are some resources to enable you to LIGHT up your network.
Feel free to hit me up on Linkedin with any questions.
Over the last year, I was introduced to a really cool open-source tool called Guacamole.Pretty funny name huh? It’s pretty much a HTML5 web based KVM with a central repository of all rdp, vnc, ssh, telnet resources.
I try to keep my sandbox, lab and home networks isolated. My workstation usually resides on my home network. To simplify remote access, I access the Guacamole web app that is hosted on my Ubuntu server.The Ubuntu server only has access to 3389/SSH into my sandbox and lab networks. Guacamole offers two factor support…for all you security people out there. General disclosure use at your own risk 🙂
Few notes of interest.. 1.Settings for Server 2012 “hostname: (as appropriate) username: (as appropriate) password: (as appropriate) domain: (as appropriate) color depth: True color (24-bit) security mode: NLA (Network Level Authentication) Ignore server certificate: ticked” https://sourceforge.net/p/guacamole/discussion/1110834/thread/b63b6dd5/
2.Main menu – After you login into one rdp session, you might want to open other tabs, navigate to the below link for a listing of all resources. http://serverIPaddress:8080/guacamole/#/settings/sessions
I am a big fan of building a separate layer for VPN client services kinda like what we used to do with the old school VPN concentrators. To accomplish this I like to use the ASAv…it’s inexpensive and easy to manage. Check out my videos, configuration and links below to learn more. As always let me know if you have any questions.
Anyconnect + ASAv Design- learn about vpn client design on the ASAv.
ASAv AnyConnect Configuration– learn how to configure AnyConnect on ASAv .
Meraki MX Perimeter Firewall + ASAv VPN Concentrator- In my above videos, I recommend leveraging a separate firewall for VPN client services. You can present your VPN concentrator to the public in a few different ways like one to one nat, port forwarding, etc. In my lab I configured port forwarding (443) to my ASAv. Check out the below video to learn how to configure the MX for this use case.
ASAv Configuration Template
#######################Interface Configuration################
#OUTSIDE configuration
interface GigabitEthernet0/0
nameif OUTSIDE
security-level 0
ip address 192.168.1.252 255.255.255.0
no shut
!
#Inside interface configuration
interface GigabitEthernet0/1
nameif INSIDE
security-level 100
ip address 192.168.30.252 255.255.255.0
no shut
#Copy VPN client package to ASA
copy tftp disk0:anyconnect-win-4.4.01054-webdeploy-k9.pkg
#setup default route for VPN clients, I do not have split tunnel configured for my lab
route inside 0.0.0.0 0.0.0.0 192.168.30.1 tunneled
#Anyconnect network object
object network VPN_CLIENT_VLAN30
subnet 192.168.30.0 255.255.255.0
#Anyconnect VPN client DHCP – you could use your own DHCP server
ip local pool VPN_CLIENT_VLAN30_POOL 192.168.X.50-192.168.X.70 mask 255.255.255.0
#######################ENABLE SSL VPN#######################################
#enable anyconnect webvpn
webvpn
enable outside
tunnel-group-list enable
anyconnect enable
#image for anyconnect – part of webvpn
anyconnect image disk0:/anyconnect-win-4.4.01054-webdeploy-k9.pkg
#################GROUP POLICY##############################################
#group-policy configuration – define VPN attributes (DNS server, domain name etc.)
group-policy GP_VPN internal
group-policy GP_VPN attributes
vpn-tunnel-protocol ssl-client
#DNS server configuration for client, note using my internal Umbrella Virtual Server
dns-server value X.X.X.X
default-domain value ccietim.com
#sub group policy – split tunnel (If split)
#split-tunnel-policy tunnelspecified
#split-tunnel-network-list value SPLIT-TUNNEL
############TUNNEL GROUP##############################
#create tunnel group – Core of VPN configuration, define GP, address pool, etc.
#Pre login requirements connection protocol, aaa authentication etc.
Finally we should create a tunnel group:
#NAT exception even if not enable
nat (inside,outside) 2 source static any any destination static VPN_CLIENT_VLAN30 VPN_CLIENT_VLAN30 no-proxy-arp route-lookup
#####################Filtering, if controlling access to what VPN clients can access##################
#access-list vpn-filter permit tcp 192.168.30.0 255.255.255.0 192.168.5.0 255.255.255.0 eq 22
#group-policy VPN-POLICY attributes
#vpn-filter value VPN-FILTER
For clients on-prem, Cisco Umbrella applies protection and reporting based on your public IP address. In a Meraki world, if your public IP changes there is no built-in way for Meraki to update Umbrella. To solve this, I found a really cool python script on GitHub. https://github.com/meraki/dns-o-matic
With this script, you can query your Meraki network for active public IP addresses(via the API). Next, the IP address data is imported to a free cloud service called DNS-O-Matic(https://www.dnsomatic.com/). DNS-O-Matic will then notify Cisco Umbrella of any public IP address changes.
This python script is relatively simple to run, a few things to call out…
1.Your password for DNS-O-Matic must end in a letter or number
2.Your Meraki username must have API access to all organization association with the account.
Check out my video below to learn more and see the script in action.
To finalize configuration and actually pass traffic through the FTD appliance, an access control policy is needed. This would be similar to an access control list that is applied to an ASA…in the Cisco world.
Access Control Policy is a policy that pulls together rule sets for L3/L4,L7(Application), URL filtering, IPS/IDS, File/AMP (Advanced Malware Protection). This is one of my favorite aspects of FMC, you can create a single policy and apply it to one or multiple devices. When making a policy change, it is pushed to all associated devices. The days of managing each device individually are over 🙂
Cisco’s definition…
“Access control is a hierarchical policy-based feature that allows you to specify, inspect, and log (non-fast-pathed) network traffic. Especially useful in multidomain deployments, you can nest access control policies, where each policy inherits the rules and settings from an ancestor (or base) policy. You can enforce this inheritance, or allow lower-level policies to override their ancestors. Each managed device can be targeted by one access control policy”
In the following videos you will learn how to setup the different components that make up an access control policy. We will build out different rules sets and tie them back to a single Access Control Policy.
*Before we start on access policy, please check out the following note on object management.*
Reusable Objects- You will see in the following videos a reference to a DNS object. An object is simply a pointer or hostname description for a network, host etc. Create these by going to Objects->Object Management.
Access Control Policy( L3/L4 rules) – This video highlights configuration of L3/L4 firewall rules by blocking ICMP traffic.
Access Control Policy (Application rules) – In this video you will see how to configure application based firewall rules.
Access Control Policy (URL Filtering rules)– This video shows how to configure URL Filtering.
Access Control Policy (File Policy/AMP) – This video shows how to configure a policy to block malware . Use the file policy to permit/deny certain file types and/or detect/prevent malicious files(Malware).
Access Control Policy (IPS Policy) – In this video learn how to configure a balanced IPS policy.
Now that we have covered ACP, I wanted to share a cool optional policy that can reduce overhead and increase performance on FTD.
PreFilter Policy – Have you ever run into that traffic that doesn’t need advanced inspection? A few examples could be VPN tunnels, encrypted traffic(that your not decrypting) and blocking IPs/networks.
To implement, create a PreFilter policy and associate it to the an ACP.
Per Cisco.com “Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation. Prefilter policies deployed to managed devices use limited outer-header criteria to quickly handle traffic.
Contrasted with the rest of access control, which uses inner headers and has more robust inspection capabilities, prefiltering is simple, fast, and early.
Configure prefiltering if you want to:
Improve performance— The sooner you exclude traffic that does not require inspection, the better. You can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation headers, without inspecting their encapsulated connections. You can also fastpath or block any other connections that benefit from early handling.
Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels, so that you can later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary because after prefiltering, access control uses inner headers.” (Cisco.com- see exact link below)
I hope you have found these blog posts helpful. I will continue to update my page with more details on FirePOWER. Please post any questions or comments in comments section below.
Looking for instructions on how-to deploy FirePOWER Management Center(FMC) and FirePOWER Threat Defense(FTD)? Then you have come to the right place! The following blog post/videos will walk through a start to finish vFMC and vFTD perimeter deployment (many of these principles can apply to physical deployments). If you are not familiar with FMC/FTD check out my previous blog post.
Before you get started…I want to send a shout out to Jason Maynard Cisco Security CSE in Canada, he created the videos below…. Check out his other content here.
Feel free to use the comments section for questions or feedback! Let’s get started!
FirePOWER management/FTD appliance – VMware Deployment – This video shows the initial steps in deploying vFMC and vFTD.
2. vFTD initial configuration – This video outlines configuration of vFTD interfaces and FMC management ip address (pointer to FMC responsible for managing the FTD appliance).
There is a two step process to manage FTD from FMC.
“configure manager [IP of FMC] [key]” -Via CLI on the FTD appliance, point FTD appliance to FMC (note the password, you will need it in the next step)
4. FTD interface configuration – The following video shows the configuration of FTD routed interfaces. See the link below to learn more interface configuration options.
5. (Optional) Setup TAP interface (i.e. connect to span port)- A potential use case for this configuration is a branch site where I may want to span my internal data vlan(capture east/west traffic) and send it to my FTD appliance. The FTD appliance will then inspect traffic in/out(routed) and east/west(passive interface).
6. FTD Routing Configuration (Static/Dynamic Routing)- This video details inbound/outbound routing configuration.
7. FTD NAT/PAT Configuration – The video highlights PAT (Port Address translation) configuration. PAT is typically used when there are many internal devices that need to share one public IP address . See the link below to learn more about NAT/PAT and configuration options.
8. FTD DHCP Server Configuration – This video shows how to setup a DHCP server for an inside network behind a FTD firewall. This configuration is typically used in a branch site or lab where a DHCP server is unavailable. Check out the link below to learn how to redirect DHCP/DNS request to a remote DHCP server.
9. FTD Platform Policy -When deploying network devices it is usually a best practice to configure management, time, access control settings etc. The following video highlights how to configure ( ssh access, icmp,smtp, snmp,syslog, time synchronization, timeouts etc. )
With FMC, there is the option to create a single policy and role it out to one or many devices. In my opinion, this greatly simplifies configuration.
Ok we are almost there….before actually routing traffic through the FTD appliance an Access Control Policy must first be created. This policy pulls together rule sets for L3/L4,L7(Application), URL filtering, IPS/IDS , and File/AMP (Advanced Malware Protection).
Before we jump into ACP configuration…Take a break, grab some coffee, and see you over in my next blog post!
In talking to my customers, many are unaware of the new FTD (Full Threat Defense) options/image. I thought I would do a quick write up on FTD. Cisco now offers the ability to run the next generation firewall engine(FirePOWER) natively on your X series ASA with the FTD image.
History
When Cisco acquired SourceFire they brought in SourceFire’s Next Generation security platform FirePOWER that included Layer 7 firewall, URL Filtering, AMP (Advanced Malware Protection) and IPS/IDS. In my opinion, Cisco had L3/L4 and VPN mastered on the ASA but had some catching up to do in the next gen feature space. Personally, being both a customer of Sourcefire and Cisco, I was ecstatic when I saw the news on Twitter. SourceFire provided me deep security visibility and alerted me on what mattered with very little man power needed.
Initially Cisco offered the ability to run FirePOWER code set on top of the ASA like a VM. You could create rules in the ASA code to choose what traffic you wanted to send over to FirePOWER. So, to manage the ASA, you would use tools like CLI, ASDM, and CSM. To manage the FirePOWER component, you would leverage FirePower Management Center (Formerly known as Defense Center).
To simplify the stack, Cisco worked to combine features from ASA and FirePOWER together in a single code FTD. With the introduction of the FTD code you can run a single OS on your ASA-X firewall or leverage one of the new FTD appliances. In addition, Cisco announced several new FTD firewalls. (Note: FTD boxes can only run the FTD code or ASA code not both.)
To be fair, there are a few caveats to what is supported on FTD….not all features have been moved over from ASA to FTD. The biggest feature (for my customers) not yet supported on FTD is AnyConnect VPN, however, site to site is supported. Cisco is working diligently to add new features. (Check release notes for more info)
FirePower Mangement
FirePower Management Center (virtual or physical)– This is the tool used to monitor/manage ALL FirePOWER appliance. I will put together future post on FMC, but it is way more than just a pretty management tool.
ASDM FirePower plugin(FMC Light) – this is for small business and customers who only have a single firewall typically (ie 5506-X). You can manage FirePower policy and gain high level visibility from this plugin. (More Details)
FirePower Implementation options
ASA + FirePOWER – manage ASA code and FirePOWER separately (supported on most ASA 5500-X) For the 5585-X you run FirePOWER on a separate blade.
FTD on ASA – single image that can be consumed on most ASA 5500-X boxes
FTD Firewall- Along with the announcement of the FTD code/image, Cisco announced several new FTD firewalls. The FTD boxes can only run the FTD code or ASA code not both.
vFTD – You can run FTD virtually, this is perfect for datacenters, remote offices where you want to FTD on your router, the cloud(ie AWS) or my favorite lab.