Thursday, November 8, 2012
Phillips.tc --> EPhillips.us
Wednesday, February 23, 2011
Zone Based Firewall, PPTP pass-through
I am seeing many people migrating from Cisco CBAC to Zone Based Firewall (ZBF) on 800 - 3900 series ISR devices being used as Internet edge firewalls due to the greater flexibility, and better interoperability with policy routing.
The most common question I receive is from a tech that sets up Zone Based Firewall according to Cisco's guide and many examples on the Internet, then finds out clients on the inside are unable to use their PPTP Windows VPN to connect to a server outside the firewall.
I encourage anyone interested in a deep understanding of PPTP to read through RFC 2637, but I will give a quick summary of the pertinent aspects of PPTP here. It is important to understand that PPTP utilizes TCP port 1723 for connection establishment, authentication, and maintenance, it then uses GRE, IP protocol 47, to pass data. By default, ZBF's keyword "match protocol pptp" does not handle the GRE traffic, only the TCP 1723 traffic.
First, let's see how to migrate from CBAC to the most basic ZBF configuration
Exhibit 1: Most Basic ZBF Config
Everything except PPTP will work outbound with this config
Step 1: Define and populate our zones:
!Define two zones
zone security ZONE_INSIDE
zone security ZONE_OUTSIDE
interface fa0/1
!Assume FastEthernet0/1 is our inside interface
zone-member security ZONE_INSIDE
interface fa0/0
!Assume FastEthernet0/1 is our outside interface
zone-member security ZONE_OUTSIDE
!Remove any CBAC commands you had here
no ip inspect CBAC in
no ip inspect CBAC out
!Remove the inbound access-list from the outside interface. Unlike CBAC, we do not control inbound access via an access-list.
no ip access-group ACLin in
Step 2: Define the class maps that identify traffic that is permitted between zones:
class-map type inspect match-any CM_INTERNET_TRAFFIC
match protocol h323
match protocol pptp
match protocol ftp
match protocol tcp
match protocol udp
match protocol icmp
!Note - we add h323 and ftp here specifically to account for upper-layer inspection required for those protocols
Step 3: Configure a policy map which specifies the action for the class map:
policy-map type inspect PM_INSIDE_TO_OUTSIDE
class type inspect CM_INTERNET_TRAFFIC
inspect
Step 4: Configure the zone pair and apply your policy:
zone-pair security ZONEP_INSIDE_OUTSIDE source ZONE_INSIDE destination ZONE_OUTSIDE
service-policy type inspect PM_INSIDE_TO_OUTSIDE
Exhibit 2: I like PPTP, would like!
This config adds outbound PPTP. Note – GRE is not automatically opened by the “match protocol pptp” in the CM_INTERNET_TRAFFIC, so we need to make GRE passed both inside to outside and reverse without inspecting it.
Step 1, Define new class-map that matches all GRE, note that you need to use an ACL for this that is referenced in the class-map:
ip access-list extended GRE
remark Access List to allow PPTP GRE outbound
permit gre any any
class-map type inspect match-any CM_GRE_PROTOCOLS
match access-group name GRE
Step 2: Configure a policy map which specifies the action for the class map:
policy-map type inspect PM_INSIDE_TO_OUTSIDE
class type inspect CM_GRE_PROTOCOLS
pass
class type inspect CM_INTERNET_TRAFFIC
inspect
class class-default
drop
policy-map type inspect PM_OUTSIDE_TO_INSIDE
class type inspect CM_GRE_PROTOCOLS
pass
class class-default
drop
Step 3: Configure the zone pair and apply your policy:
zone-pair security ZONEP_INSIDE_OUTSIDE source ZONE_INSIDE destination ZONE_OUTSIDE
service-policy type inspect PM_INSIDE_TO_OUTSIDE
zone-pair security ZONEP_OUTSIDE_INSIDE source ZONE_OUTSIDE destination ZONE_INSIDE
service-policy type inspect PM_OUTSIDE_TO_INSIDE
Note: The above config is perfect for a SOHO user who is not hosting any internal servers. However, most sites will be hosting servers internally, so below is an example with the naming scheme of how I like to form my class maps, access-lists, and policy-maps. Note that I like to keep all "variable" names in upper case so they pop out to me in my config. (Credit to Internetwork Experts for that tip)
Exhibit 3: I host servers, so I need an inbound firewall
Step 1, Define an access-list with the internal IP of the server:
ip access-list extended HELPDESK
permit ip any host 10.5.0.3
Step 2, Define a "match-any" class-map with the protocols to be allowed:
class-map type inspect match-any CM_HELPDESK_PROTOCOLS
match protocol http
match protocol https
match protocol ssh
Step 3, Define a "match-all" class map to combine the two:
class-map type inspect match-all CM_HELPDESK
match access-group name HELPDESK
match class-map CM_HELPDESK_PROTOCOLS
Step 4, Add the class-map to the OUTSIDE_TO_INSIDE policy-map:
policy-map type inspect PM_OUTSIDE_TO_INSIDE
description Internet to LAN Servers
class type inspect CM_GRE_PROTOCOLS
pass
class type inspect CM_ICMP
inspect
class type inspect CM_HELPDESK
inspect
class class-default
drop
Step 5, Don't forget your nat statement:
ip nat inside source static 10.5.0.3 1.1.1.1
Notes:
- I like to add an ICMP inspect class map so you can ping all servers without needing to explicitly adding ICMP to every server's class-map. You would not want this if permitting pinging is not preferred, or if you are worried about ICMP security risks.
- If you need to add a non-standard port you have two options.
- First, give it a name: ip port-map user-RDP port tcp 3389
- Second, define an ACL with the ports, and add it to the "match-any" CM_SERVER_PROTOCOLS:
ip access-list extended LTIITEDGE_PROTOCOLS
permit tcp any host 10.50.1.10 eq 5061
permit tcp any host 10.50.1.10 eq 8057
permit tcp any host 10.50.1.10 eq 5062
permit tcp any host 10.50.1.10 eq 3478
permit tcp any host 10.50.1.10 range 49152 65535
DocCD items to reference:
Tuesday, May 5, 2009
MPLS + Troubleshooting added to CCIE R/S exam
1.00 | Implement Layer 2 Technologies | √ |
1.10 | Implement Spanning Tree Protocol (STP) | |
(a) 802.1d | ||
(b) 802.1w | ||
(c) 801.1s | ||
(d) Loop guard | ||
(e) Root guard | ||
(f) Bridge protocol data unit (BPDU) guard | ||
(g) Storm control | ||
(h) Unicast flooding | ||
(i) Port roles, failure propagation, and loop guard operation | ||
1.20 | Implement VLAN and VLAN Trunking Protocol (VTP) | |
1.30 | Implement trunk and trunk protocols, EtherChannel, and load-balance | |
1.40 | Implement Ethernet technologies | |
(a) Speed and duplex | ||
(b) Ethernet, Fast Ethernet, and Gigabit Ethernet | ||
(c) PPP over Ethernet (PPPoE) | ||
1.50 | Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control | |
1.60 | Implement Frame Relay | |
(a) Local Management Interface (LMI) | ||
(b) Traffic shaping | ||
(c) Full mesh | ||
(d) Hub and spoke | ||
(e) Discard eligible (DE) | ||
1.70 | Implement High-Level Data Link Control (HDLC) and PPP | |
2.00 | Implement IPv4 | |
2.10 | Implement IP version 4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM) | |
2.20 | Implement IPv4 tunneling and Generic Routing Encapsulation (GRE) | |
2.30 | Implement IPv4 RIP version 2 (RIPv2) | |
2.40 | Implement IPv4 Open Shortest Path First (OSPF) | |
(a) Standard OSPF areas | ||
(b) Stub area | ||
(c) Totally stubby area | ||
(d) Not-so-stubby-area (NSSA) | ||
(e) Totally NSSA | ||
(f) Link-state advertisement (LSA) types | ||
(g) Adjacency on a point-to-point and on a multi-access network | ||
(h) OSPF graceful restart | ||
2.50 | Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP) | |
(a) Best path | ||
(b) Loop-free paths | ||
(c) EIGRP operations when alternate loop-free paths are available, and when they are not available | ||
(d) EIGRP queries | ||
(e) Manual summarization and autosummarization | ||
(f) EIGRP stubs | ||
2.60 | Implement IPv4 Border Gateway Protocol (BGP) | |
(a) Next hop | ||
(b) Peering | ||
(c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP) | ||
2.70 | Implement policy routing | |
2.80 | Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER) | |
2.90 | Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features | |
3.00 | Implement IPv6 | |
3.10 | Implement IP version 6 (IPv6) addressing and different addressing types | |
3.20 | Implement IPv6 neighbor discovery | |
3.30 | Implement basic IPv6 functionality protocols | |
3.40 | Implement tunneling techniques | |
3.50 | Implement OSPF version 3 (OSPFv3) | |
3.60 | Implement EIGRP version 6 (EIGRPv6) | |
3.70 | Implement filtering and route redistribution | |
4.00 | Implement MPLS Layer 3 VPNs | |
4.10 | Implement Multiprotocol Label Switching (MPLS) | |
4.20 | Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers | |
4.30 | Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite) | |
5.00 | Implement IP Multicast | |
5.10 | Implement Protocol Independent Multicast (PIM) sparse mode | |
5.20 | Implement Multicast Source Discovery Protocol (MSDP) | |
5.30 | Implement interdomain multicast routing | |
5.40 | Implement PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and bootstrap router (BSR) | |
5.50 | Implement multicast tools, features, and source-specific multicast | |
5.60 | Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast Listener Discovery (MLD) | |
6.00 | Implement Network Security | |
6.01 | Implement access lists | |
6.02 | Implement Zone Based Firewall | |
6.03 | Implement Unicast Reverse Path Forwarding (uRPF) | |
6.04 | Implement IP Source Guard | |
6.05 | Implement authentication, authorization, and accounting (AAA) (configuring the AAA server is not required, only the client-side (IOS) is configured) | |
6.06 | Implement Control Plane Policing (CoPP) | |
6.07 | Implement Cisco IOS Firewall | |
6.08 | Implement Cisco IOS Intrusion Prevention System (IPS) | |
6.09 | Implement Secure Shell (SSH) | |
6.10 | Implement 802.1x | |
6.11 | Implement NAT | |
6.12 | Implement routing protocol authentication | |
6.13 | Implement device access control | |
6.14 | Implement security features | |
7.00 | Implement Network Services | |
7.10 | Implement Hot Standby Router Protocol (HSRP) | |
7.20 | Implement Gateway Load Balancing Protocol (GLBP) | |
7.30 | Implement Virtual Router Redundancy Protocol (VRRP) | |
7.40 | Implement Network Time Protocol (NTP) | |
7.50 | Implement DHCP | |
7.60 | Implement Web Cache Communication Protocol (WCCP) | |
8.00 | Implement Quality of Service (QoS) | |
8.10 | Implement Modular QoS CLI (MQC) | |
(a) Network-Based Application Recognition (NBAR) | ||
(b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ) | ||
(c) Classification | ||
(d) Policing | ||
(e) Shaping | ||
(f) Marking | ||
(g) Weighted random early detection (WRED) and random early detection (RED) | ||
(h) Compression | ||
8.20 | Implement Layer 2 QoS: weighted round robin (WRR), shaped round robin (SRR), and policies | |
8.30 | Implement link fragmentation and interleaving (LFI) for Frame Relay | |
8.40 | Implement generic traffic shaping | |
8.50 | Implement Resource Reservation Protocol (RSVP) | |
8.60 | Implement Cisco AutoQoS | |
9.00 | Troubleshoot a Network | |
9.10 | Troubleshoot complex Layer 2 network issues | |
9.20 | Troubleshoot complex Layer 3 network issues | |
9.30 | Troubleshoot a network in response to application problems | |
9.40 | Troubleshoot network services | |
9.50 | Troubleshoot network security | |
10.00 | Optimize the Network | |
10.01 | Implement syslog and local logging | |
10.02 | Implement IP Service Level Agreement SLA | |
10.03 | Implement NetFlow | |
10.04 | Implement SPAN, RSPAN, and router IP traffic export (RITE) | |
10.05 | Implement Simple Network Management Protocol (SNMP) | |
10.06 | Implement Cisco IOS Embedded Event Manager (EEM) | |
10.07 | Implement Remote Monitoring (RMON) | |
10.08 | Implement FTP | |
10.09 | Implement TFTP | |
10.10 | Implement TFTP server on router | |
10.11 | Implement Switch-module Configuration Protocol (SCP) | |
10.12 | Implement HTTP and HTTPS | |
10.13 | Implement Telnet |
Monday, April 13, 2009
CCIE ALU - Traffic Control
Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.
Question:
In addition to the 1.1.3.0/24 subnet on R3's FastEthernet0/0 interface, there is also a subnet 1.1.33.0/24, which contains several high bandwidth users. These users have been receiving very large HTTP downloads across the Serial1/3 interface. Limit HTTP responses destined to the 1.1.33.0/24 subnet to 512kbit/sec. All configuration must be done on R3.
Highlight below for the solution:
Solution:
R3:
ip access-list extended HTTP_TO_1.1.33
permit tcp any eq www 1.1.33.0 0.0.0.255
!
class-map match-all HTTP_TO_1.1.33
match access-group name HTTP_TO_1.1.33
!
policy-map QOS1
class HTTP_TO_1.1.33
police 512000
class class-default
!
interface Serial1/3
service-policy input QOS1
Confirmation:
Rack1R3(config-if)#do sh policy-map int
Serial1/3
Service-policy input: QOS1
Class-map: HTTP_TO_1.1.33 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name HTTP_TO_1.1.33
police:
cir 512000 bps, bc 16000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
11 packets, 1088 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Explanation:
Since all configuration must be done on R3, we must use policing because only the very high-end Cisco routers can perform shaping inbound. We create a class that matches TCP traffic with a source port of 80 and any destination port, since the HTTP request is a very small packet going out Serial1/3, and the HTTP response is the very large packet coming in Serial1/3.
One important point to remember is this method of traffic control is ineffective for controlling UDP traffic streams since the traffic has already traversed the serial link between R2 and R3 by the time policing on R3 is enforced. This method of policing on the "far end" is effective when controlling TCP traffic because the applications will set their sliding window to a size that will approximate 512kbit/sec.
If you are not 100% familiar with TCP, sliding windows, and all aspects of TCP retransmission, please read the following site for a great tutorial: http://www.rhyshaden.com/tcp.htm
I highly encourage you to be extremely consistent in the way you name access-lists, class-maps, policy-maps, or other items you create in the IOS. You are free to create any system you would like, but my general guidelines are to make your variables in all capital letters so they stand out in your show commands. I also like to name items according to the section they were created for. For example, if item 4.5 in the QOS section of a test requires me to create an access-list, I will name the access-list QOS4.5. Or if I need to make a numbered ACL, I will number it 45 or 145 depending if I need a standard or extended access-list.
DocCD items to reference:
Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)
ip access-list (Named Access-Lists)
Tuesday, March 24, 2009
CCIE ALU - FRTS and how to compute ts
Foreward: A CCIE ALU is an Autonomous Learning Unit, you can read this post to learn more about them.
Question:
Users have been reporting an increase in the number of dropped packets on the frame relay link between R1 and R2. Your frame relay provider has sent you a notice that they are seeing significantly more traffic attempting to go through the frame relay link then permitted. You have purchased 128kbit/sec of guaranteed bandwidth from the provider, but there is currently no restriction on the amount of traffic permitted out the frame relay link. Limit the amount of traffic traversing the frame relay link to the permitted amount. You will soon be allowing voice traffic across that link, so you must minimize delay and jitter.
Highlight below for the solution:
Solution:
map-class frame-relay FRTS
frame-relay cir 128000
frame-relay bc 1280
frame-relay be 0
!
interface Serial0/0
frame-relay traffic-shaping
frame-relay class FRTS
Confirmation:
R2#show frame pvc 201
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 5 output pkts 5 in bytes 520
out bytes 520 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 1w6d, last time pvc status changed 00:00:01
cir 128000 bc 1280 be 0 byte limit 160 interval 10
mincir 64000 byte increment 160 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo
Output queue 0/40, 0 drop, 0 dequeued
Explanation:
Frame relay traffic shaping is the method of controlling the rate at which packets are allowed to exit an interface. Since frame relay is a multi-access medium, FRTS specifically allows us to specify separate queues for each DLCI, therefore if you need to allow a certain amount of bandwidth between one set of routers, and a separate amount of bandwidth between another set of routers, FRTS is a great option.
By default there is no limit to the amount of traffic exiting an interface, therefore in this case we will be attempting to send traffic up to the full interface speed out the frame relay interface. Since our service provider is limiting us to 128kbit/sec, it is fruitless to send more than that.
The most important part of this question is to understand how CIR, Bc, Be, and Tc relate mathematically. In this case, since we are asked to minimize delay and jitter we need to set our Tc as low as possible, which is 10ms.
You cannot set the Tc for FRTS explicitly, therefore we must calculate it. To obtain the Tc we want, we need to first figure out how many segments should be sent in a single second. To do this we take 1000 ms and divide it by the desired TC:
1000 / 10 = 100
Now we take our CIR and divide it by the number of segments we will send in a given second to figure out how many bits we should send each time segment, that number will be our Bc:
128000 / 100 = 1280
FRTS will now send 1280 bits every 10ms, resulting in 128,000 bits being sent per second.
It is interesting to note that a router cannot actually send data at less than the interface speed. Therefore, if our frame relay connection above is a 1.536Mbit/sec T1, FRTS will send 1280 bits in only 0.84ms, then sit idle for 9.16ms, then repeat that process 99 more times per second, resulting in the equivalent of 128Kbit/sec.
If you remember the above two step process, you will always be able to calculate the Bc needed to achieve a certain Tc.
- Figure out how many segments should be sent in a single second (1000ms / 10ms = 100 segments)
- Divide our CIR by the number of segments to send in a single second to calculate Bc (128000bps / 100 segments = 1280 bits/segment)
DocCD items to reference:
Configuration Guide (Configuring Frame Relay Traffic Shaping)
Tuesday, March 10, 2009
CCIE ALU - CBWFQ and qos-group tagging to match traffic
Foreward: An ALU is an Autonomous Learning Unit to help with CCIE lab preparation , you can read this post to learn more about them.
Question:
All traffic coming in Serial0/1 of R2 needs to be guaranteed 512Kbit/sec of bandwidth when exiting the frame relay interface of R2. All traffic entering FastEthernet0/0 of R2 should be dropped if it tries to exit the frame relay interface of R2, unless it is HTTPS traffic. No change in configuration should be required if any IP addresses change in the future. Also, no part of the packet header should be modified in any way by this configuration.
Highlight below for the solution:
Solution:
R2:
class-map match-all MATCH_HTTPS
match protocol secure-http
class-map match-all MATCH_QOS1
match qos-group 1
class-map match-all MATCH_QOS2
match qos-group 2
!
policy-map IN_S0-1
class class-default
set qos-group 1
policy-map OUT_S0-0
class MATCH_QOS1
bandwidth 512
class MATCH_QOS2
drop
policy-map IN_FA0-0
class MATCH_HTTPS
class class-default
set qos-group 2
!
interface FastEthernet0/0
service-policy input IN_FA0-0
interface Serial0/1
service-policy input IN_S0-1
interface Serial0/0
service-policy output OUT_S0-0
Confirmation:
R2#show policy-map interface
FastEthernet0/0
Service-policy input: IN_FA0-0
Class-map: MATCH_HTTPS (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: protocol secure-http
Class-map: class-default (match-any)
45 packets, 670 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
qos-group 2
Packets marked 45
Serial0/0
Service-policy output: OUT_S0-0
Class-map: MATCH_QOS1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: qos-group 1
Queueing
Output Queue: Conversation 265
Bandwidth 512 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: MATCH_QOS2 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: qos-group 2
drop
Class-map: class-default (match-any)
33 packets, 462 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Serial0/1
Service-policy input: IN_S0-1
Class-map: class-default (match-any)
15 packets, 150 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
QoS Set
qos-group 1
Packets marked 15
Explanation:
Qos-group is a flag that can be set and matched on packets, and is local to the router; that is, it is not an industry standard flag, or a flag that is part of the IP or Ethernet headers. The qos-group is very useful because it allows you to apply QOS policy without modifying a packet. For example, in the above question we could have set a DSCP or IP Precedence value, then matched based on that. However, that would modify the packet and change those values; which might have been set by other devices in the network.
In this example we are setting QOS Group 1 on any packets entering the PPP serial link from R3 using the policy-map IN_S0-1. We are also setting QOS Group 2 on any non-HTTPS packet entering FastEthernet0/0 using policy-map IN_FA0-0. We are then reserving bandwidth for QOS Group 1, and dropping QOS Group 2 in policy-map OUT_S0-0.
An important point to remember is that policy-maps are "first hit exit" policies. Meaning traffic is compared to each class within the policy-map, and as soon as it finds one that matches, the actions in that class are executed and the policy-map is exited. In the example of IN_FA0-0 we can see that we are matching HTTPS traffic, and applying no action to it. All other traffic hits the class class-default and has a QOS-GROUP 2 set on it. An alternative to this configuration would be to set QOS-GROUP 2 on all traffic entering FastEthernet0/0, then in policy-map OUT_S0-0 you could match HTTPS and do nothing to it, thereby bypassing the drop associated with QOS GROUP 2. Both options are valid and would be awarded full credit in the CCIE lab.
DocCD items to reference:
Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)