according to Zone Self rule.
R2(config)#policy-map type inspect WAN-TO-SELF
R2(config)#zone-pair security WAN-TO-SELF source WAN destination self
R2(config-sec-zone-pair)#service-policy type inspect WAN-TO-SELF
Will all the data send back from ISP to LAN be dropped because of R2 Zone Self rule?
Hi @naingnnlwin,
The self zone is only for packets that are destined for the router itself, not for packets that are flowing through the router (like from WAN to LAN).
If you want to permit return traffic that originated from the LAN to the Internet, then youāll need to use a inspect rule in your LAN-TO-WAN zone-pair.
Hi Rene,
thank for your explain.
Thanks,
Nyi Nyi.
When I apply the WAN_TO_SELF service policy as shown in this lesson, as expected R3 cannot ping R2, but R2 also cannot ping R3. Is this expected? Since there is nothing applied in the self > WAN direction I expected that R2 would still be able to ping R3.
Thanks for the great lesson!
Hello Jeremy
Remember that a ping has communication occurring in both directions. When you ping from R2 to R3, you are sending an echo request. This echo request reaches R3, which replies with an echo reply. This reply does indeed go from WAN to Self, so it is caught by the service policy you applied.
I hope this has been helpful!
Laz
Could yo give an example when you can use the pass action instead of the inspect action?
Hello Rodrigo
Such a configuration would not be much different than the one shown in the lesson. The difference is that instead of the inspect keyword, the pass keyword would be used. Now the difference in the behaviour would simply be that the traffic would be passed without any regard to any return traffic.
The pass action would be used in scenarios where there is no session (non TCP traffic such as UDP) or scenarios where there is only one way traffic, such as multicast video (broadcast IPTV for example). Even in these cases however, you may have to provide for a method of communication in the opposite direction (possibly another pass action command) so that traffic travelling in the opposite direction that is associated with such applications (control information etc) can make it through the firewall.
I hope this has been helpful!
Laz
Hello,
Please can someone advise if there is option to configure zones on Cisco CSRv , has anyone done that setup?
Thanks in advance for your response
Hello Zeeshan
You can indeed configure a zone-based firewall on the CSR1000v in the same way as you would do so on a physical IOS device. You can find more information about this at the following link:
I hope this has been helpful!
Laz
Hi Laz,
Thanks for the link, Iām a bit confused on how to proceed with CSR1000v, which is also serving as a VPN end point. Iāve read the above thread and see Simon has asked smiliar question and Rene has responded with an example config. However my confusion is, Iām using GRE+IPSec on CSR1000v. Will I have to assign the virtual interfaces tunnels to separate zones? Or only the OUTSIDE interface ( having cryptomap) will be in a zone? Please can you advise?
EDIT:
Iāve tried to apply below configs, however the GRE over IPsec breaks then BGP adjacency is lost between the CSR and remote end FW as soon as I put CSRās interfaces in security zone. The CSR is behind a NAT router. Iāve attached the topology for reference.
please can you help me point where iām making the mistake?, iād really appreciate your support, please.
Thanks.
CSR2#sh run
Building configuration...
Current configuration : 5638 bytes
!
! Last configuration change at 19:14:15 UTC Sun May 31 2020
!
version 16.3
service timestamps debug datetime msec
service timestamps log datetime msec
no platform punt-keepalive disable-kernel-core
platform console serial
!
hostname CSR2
!
boot-start-marker
boot-end-marker
!
!
enable secret 5 $1$WETh$nFwuPGMClHjYlweGRS1Nb1
!
aaa new-model
!
!
aaa authentication login tacgui group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
aaa session-id common
!
ip dhcp excluded-address 10.40.40.1
!
ip dhcp pool Private
network 10.40.40.0 255.255.255.0
default-router 10.40.40.1
!
!
!
subscriber templating
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
crypto pki trustpoint TP-self-signed-743922911
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-743922911
revocation-check none
rsakeypair TP-self-signed-743922911
!
!
crypto pki certificate chain TP-self-signed-743922911
!
!
license udi pid CSR1000V sn 9RWZ8WIVQ1V
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
username local password 0 local*123
!
redundancy
!
!
!
!
!
!
!
class-map type inspect match-any Internet-cmap
match protocol icmp
match protocol tcp
match protocol udp
match protocol http
match protocol https
match protocol pop3
match protocol pop3s
match protocol smtp
class-map type inspect match-all ICMP-cmap
match access-group name ICMP
class-map type inspect match-all IPSEC-cmap
match access-group name ISAKMP_IPSEC
class-map type inspect match-all SSHaccess-cmap
match access-group name SSHaccess
!
policy-map type inspect inside-outside-pmap
class type inspect Internet-cmap
inspect
class type inspect ICMP-cmap
inspect
class class-default
drop
policy-map type inspect Outside-Router-pmap
class type inspect SSHaccess-cmap
inspect
class type inspect ICMP-cmap
inspect
class type inspect IPSEC-cmap
pass
class class-default
drop
policy-map type inspect outside-inside-pmap
class type inspect ICMP-cmap
inspect
class class-default
drop
!
zone security OUTSIDE
zone security INSIDE
zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
description INSIDE-TO-OUTSIDE TRAFFIC
service-policy type inspect inside-outside-pmap
zone-pair security OUTSIDE-TO-INSIDE source OUTSIDE destination INSIDE
description OUTSIDE-TO-INSIDE TRAFFIC
service-policy type inspect outside-inside-pmap
zone-pair security OUTSIDE-TO-ROUTER source OUTSIDE destination self
description OUTSIDE-TO-ROUTER TRAFFIC
service-policy type inspect Outside-Router-pmap
!
crypto keyring KEY_RING
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
!
!
!
!
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 28800
crypto isakmp profile IPROF
keyring KEY_RING
match identity address 0.0.0.0
!
!
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile IPSECPROF
set transform-set TSET
!
!
!
crypto map MYMAP 10 ipsec-isakmp
set peer 192.4.10.2
set transform-set TSET
match address 101
!
!
!
!
interface Tunnel1
ip address 10.1.1.0 255.255.255.254
zone-member security OUTSIDE
tunnel source GigabitEthernet1
tunnel destination 192.4.10.2
!
!
interface GigabitEthernet1
ip address 10.11.0.2 255.255.255.0
zone-member security OUTSIDE
negotiation auto
no mop enabled
no mop sysid
crypto map MYMAP
!
interface GigabitEthernet2
ip address 10.40.40.1 255.255.255.0
zone-member security INSIDE
negotiation auto
no mop enabled
no mop sysid
!
router bgp 65000
bgp router-id 15.15.15.15
bgp log-neighbor-changes
network 10.40.40.0 mask 255.255.255.0
neighbor 10.1.1.1 remote-as 65001
!
!
virtual-service csr_mgmt
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 10.11.0.1
!
ip access-list extended ICMP
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any traceroute
ip access-list extended ISAKMP_IPSEC
permit udp any any eq non500-isakmp
permit udp any any eq isakmp
permit ahp any any
permit esp any any
ip access-list extended SSHaccess
permit tcp any any eq 22
!
access-list 101 permit ip host 10.11.0.2 host 192.4.10.2
!
!
!
tacacs server tacgui
address ipv4 10.40.40.3
key cisco123
!
!
!
control-plane
!
!
!
line con 0
logging synchronous
stopbits 1
line vty 0
login authentication tacgui
transport input telnet ssh
line vty 1
login authentication tacgui
length 0
transport input telnet ssh
line vty 2 4
login authentication tacgui
transport input telnet ssh
!Hi Rene/Laz,
Iāve managed to get the VPN working.
However Iāve a different question regarding the class-map. this is my class-map for VPN traffic
class-map type inspect match-any vpn-cmap
match protocol dns
match protocol ssh
match protocol telnet
match protocol tacacs
match protocol icmp
match protocol udp
match protocol tcp
and these are the policy map
policy-map type inspect vpn-inside-pmap
class type inspect vpn-cmap
inspect
class class-default
drop
policy-map type inspect inside-vpn-pmap
class type inspect vpn-cmap
inspect
class class-default
drop
Issue is even though the class-map is not having āmatch protocol https or httpā iām still able to open a https page in side of VPN zone. Only time iām not able to open https is when i remove āmatch protocol tcpā
please can you explain why? and is having an access-list in class-map the only way to block https or Layer 7 protocols?
I look forward to your earliest response.
thanks.
Hi Zeeshan,
Good to hear you figured it out. Did you add your GRE interface to a zone? Connections to the router itself should match the āselfā zone.
Your HTTP and HTTPS traffic matches match protocol tcp which is why itās permitted. You could try to create an additional class-map which includes match protocol http and match protocol https, add it before your vpn-cmap class-map, and drop it. That should block your HTTP/HTTPS traffic but still inspect all other TCP traffic.
Rene
Hi Rene,
Thanks for your response, Iād like to take this moment to appreciate this platform which helps all of us in so many ways. This platform is my goto place to find the easiest explanation to a networking concept! keep up the good work 
.
So, Yes I first put the GRE interface to OUTSIDE Zone due to which communication for BGP neighbor ship wasnāt happening. Then I moved the GRE tunnel to INSIDE zone which established the BGP. however my end goal was to have a separate VPN zones for Spokes and have policy-map/class-maps restricting or limiting traffic between VPN & INSIDE Zones through the policy-map.
For HTTP/HTTPS traffic, I just wanted to test a vpn class-map if by removing the statement match protocol http and match protocol https would restrict http/https access. Iād ideally want http/https to pass through. So my other question is, does match protocol tcp means it will allow all other TCP based protocols? What would be the most efficient way in blocking such L7 protocols? Can I not do something for e.g only allow certain protocols I know I want to communicate between VPN-INSIDE zone e.g (http,https,dns,icmp,ssh, telnet, tacacs) and block all other by default or implicitly?
Also, a bit off topic, while using crypto map for Site-to-Site IPsec VPN, is there a better way to optimize the config on HUB (CSR) considering there will be a lot of spokes connecting to the HUB (CSR) ? any pointers or best practice will be really appreciated.
Once again, thank you so much for your guidance.
Regards
Zeeshan
Hello Zeeshan
As Rene mentions in his post, the GRE interface should be in the āselfā zone since traffic to and from this interface are destined and originate from the device itself. Remember that this is the interface to which the tunnel terminates, and all tunnel termination procedures are destined to this interface. The tunnelled traffic (the tunnel interface that is) can and should be in a different zone.
Yes. Any upper layer protocol that uses TCP will be allowed unless specifically indicated in another class map.
You can indeed choose which protocols to allow and which not to allow. You must keep in mind that you can specify protocols of various layers of the OSI model. So if you want to allow TCP for example, but you want to exclude the use of HTTP and HTTPS, then you can:
If you will have many spokes, then the most appropriate technology to use is DMVPN, which is specifically designed to provide you with multiple GRE tunnels using multipoint GRE (mGRE) which can easily add spokes without the need for extra configurations on the hub. You simply configure another spoke and add it. You can apply IPSec security on a DMVPN topology to ensure security and confidentiality. For more information, take a look at the series of lessons on DMVPN starting with these:
I hope this has been helpful!
Laz
Thanks for your response.
Iām still going circles with the match protocol http and match protocol tcp.
below L4 & L7 class-map will allow everything as it allows TCP so i removed this then tried the object-group service for protocols.
class-map type inspect match-any L7-cmap
match protocol dns
match protocol ssh
match protocol telnet
match protocol tacacs
match protocol http
match protocol https
class-map type inspect match-any L4-cmap
match protocol tcp
match protocol udp
match protocol icmp
I just want below protocols and ports to be allowed for which i tried object group service and used tcp protocols for specific tcp protocols to be allowed. however the HTTP, HTTPS, SNMP traffic doesnāt pass between two zones however icmp and ssh works. please can you help me what am i doing wrong?
object-group service ALLOWED_PROTOCOLS_OGS
tcp-udp eq domain
tcp eq telnet
tcp eq tacacs
tcp-udp eq 5060
tcp-udp eq 5061
tcp-udp eq 4569
tcp eq pop3
tcp-udp eq 3389
udp eq 389
tcp eq 853
tcp eq 445
tcp eq 389
tcp eq msrpc
udp eq netbios-ns
udp eq 88
tcp eq 88
tcp eq 636
tcp eq 3268
tcp eq 3269
tcp eq domain
tcp eq 464
udp eq 464
tcp range 49152 65535
udp eq ntp
tcp-udp eq 443
tcp-udp eq echo
icmp
tcp eq 22
tcp eq 443
tcp eq www
tcp eq 161
tcp eq 162
policy-map type inspect vpn-inside-pmap
class type inspect ALLOWED_PROTOCOL_CMAP
inspect
class class-default
drop
policy-map type inspect inside-vpn-pmap
class type inspect ALLOWED_PROTOCOL_CMAP
inspect
class class-default
drop
class-map type inspect match-all ALLOWED_PROTOCOL_CMAP
match access-group name ALLOWED_PROTOCOLS
ip access-list extended ALLOWED_PROTOCOLS
permit object-group ALLOWED_PROTOCOLS_OGS any any
deny tcp any any
appreciate your support.
Thanks
Z
Hello Zeeshan
In your L4 and L7 class-map configuration, your class-map is inspecting traffic and not dropping it. As Rene pointed out in the above post, you should create an additional class-map that matches the HTTP and HTTPS protocols, and drops them. This way all TCP will be allowed, but HTTP and HTTPS will not be. Just make sure that this class-map appears before the matching of TCP. This way, only HTTP and HTTPS traffic will be dropped and not other forms of TCP traffic.
It appears that your object groups are created correctly, and since you are using inspect for your class maps and policy maps, all the protocols/ports in the object group should be allowed to traverse one zone to another. The fact that they donāt, gives me the impression that they may somehow be caught by the class-default drop statement. Try removing this and see the results. Also, try to replace the object group with a single statement for HTTP within the access list to see if that makes a difference. By making these changes and seeing what is allowed or disallowed will help you in pinpointing the problem. It could be a configuration error, or simply even a typo in the implementation of the policy map.
Try these out and let us know your resultsā¦
I hope this has been helpful!
Laz
Hi @lagapidis,
Thanks for your response.
Iād like to apologies, I was actually testing wrong https port. I had allowed TCP 443 however the application home page I was trying to reach between zones was operating on 4443. So that was an oversight from my end.
however, for above, wouldnāt it be more work trying to find all known protocols & ports to block compared to what I know needs to be allowed only? for e.g I want only these protocols allowed (http,https,dns,icmp,ssh, telnet, tacacs) do I need to create first separate class-map for āALLā other TCP protocols that needs to be dropped? and then create a class-map for these (http,https,dns,icmp,ssh, telnet, tacacs) inspecting ? I hope my question makes sense and there is a better way to block.
Thanks again for your support.
Regards
Z
Hello Zeeshan
What is being suggested is the following:
class-map type inspect match-any L7-cmap
match protocol http
match protocol https
class-map type inspect match-any L4-cmap
match protocol tcp
policy-map type inspect MY_PMAP
class type drop L7-cmap
inspect
class type inspect L4-cmap
drop
The above policy map configuration will drop all HTTP and HTTPS while allowing all other traffic using TCP. Here there is no need to specify each and every L7 protocol you want to allow.
I hope this has been helpful!
Laz
Hello @lagapidis,
Thanks for the explanation. apologies I was all this time imagining the policy map is still inspecting L4-cmap 
its clear now, many thanks!
Regards
Zeeshan
I am trying to get a VPN to work with these zone based firewalls. The VPN is not configured on the router. The source of the VPN is elsewhere and the destinaton is on the customer lan.
If i use the config below when the VPN has already been established, the VPN does not drop.
If i apply the config below, and then restart the VPN, it wont establish.
I have read as much as i can, i believe i am making an exception and passing the VPN traffic, but it just does not work.
Any thoughts suggestions would be welcome
! policy-map
policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
class type inspect VPN
pass
class type inspect INSIDE-TO-OUTSIDE-CLASS
inspect
class class-default
drop log
! policy-map
policy-map type inspect OUTSIDE-TO-INSIDE-POLICY
class type inspect VPN
pass
class type inspect OUTSIDE-TO-INSIDE-CLASS
inspect
class class-default
drop log
class-map type inspect match-all VPN
match access-group name Bespoke_VPN
class-map type inspect match-any INSIDE-TO-OUTSIDE-CLASS
match access-group name Egress
class-map type inspect match-any OUTSIDE-TO-INSIDE-CLASS
match access-group name Ingress
ip access-list extended Bespoke_VPN
10 permit udp any any eq isakmp
20 permit ahp any any
30 permit esp any any
40 permit udp any any eq non500-isakmp