ZBF Issue

[andypowernet]

Morning,

Im having an issue with ZBF. It needs to allow the guest zone to the inside zone to allow the guest zone to redirect to Cisco ISE webauthentication, which doesn't seem to work.  Anyone any ideas? Config below:

Guest Interface:

interface GigabitEthernet0/0/1.40
description LAN Guest
encapsulation dot1Q 40
vrf forwarding internet
ip address 10.192.203.254 255.255.255.0
ip nat inside
zone-member security GUEST

Inside Interface:

interface Tunnel196
vrf forwarding customer
ip address 10.248.196.242 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication customer
ip nhrp map 10.248.196.254 185.34.234.250
ip nhrp map multicast 185.34.234.250
ip nhrp map 10.248.196.253 195.88.236.250
ip nhrp map multicast 195.88.236.250
ip nhrp network-id 196
ip nhrp holdtime 60
ip nhrp nhs 10.248.196.253
ip nhrp nhs 10.248.196.254
zone-member security INSIDE
ip tcp adjust-mss 1360
qos pre-classify
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 196
tunnel vrf internet
tunnel protection ipsec profile dmvpn-ipsec-profile
endinterface Tunnel196
vrf forwarding customer
ip address 10.248.196.242 255.255.255.224
no ip redirects
ip mtu 1400
ip nhrp authentication customer
ip nhrp map 10.248.196.254 185.34.234.250
ip nhrp map multicast 185.34.234.250
ip nhrp map 10.248.196.253 195.88.236.250
ip nhrp map multicast 195.88.236.250
ip nhrp network-id 196
ip nhrp holdtime 60
ip nhrp nhs 10.248.196.253
ip nhrp nhs 10.248.196.254
zone-member security INSIDE
ip tcp adjust-mss 1360
qos pre-classify
tunnel source GigabitEthernet0/0/0
tunnel mode gre multipoint
tunnel key 196
tunnel vrf internet
tunnel protection ipsec profile dmvpn-ipsec-profile
end

Zone Pairs:

zone-pair security GUEST-TO-INSIDE source GUEST destination INSIDE
service-policy type inspect GUEST-TO-INSIDE

zone-pair security INSIDE-TO-GUEST source INSIDE destination GUEST
service-policy type inspect INSIDE-TO-GUEST

Policy Maps:

policy-map type inspect GUEST-TO-INSIDE
class type inspect GUEST-TO-INSIDE
inspect
class class-default
drop log

policy-map type inspect INSIDE-TO-GUEST
class type inspect INSIDE-TO-GUEST
inspect
class class-default
drop

Class Maps:

class-map type inspect match-any GUEST-TO-INSIDE
match access-group name ZBF-GUEST-TO-INSIDE

class-map type inspect match-any INSIDE-TO-GUEST
match access-group name ZBF-INSIDE-TO-GUEST

ACL:

Extended IP access list ZBF-INSIDE-TO-GUEST
10 permit tcp host 10.248.196.39 eq 8443 any
20 permit icmp host 10.248.196.39 any echo

Extended IP access list ZBF-GUEST-TO-INSIDE
10 permit tcp any host 10.248.196.39 eq 8443
20 permit icmp host 10.248.196.39 any echo

[andypowernet]

Hi

This isn't really practice as the whole idea is that customer and guest are
on separate vrf. And guest traffic locally breaks out for internet on the
router. Where as the customer vrf internet goes via the data center.

[MHM Cisco World]

I dont get your last comment 
there are two VRF 
there are four Zone 
self 
OUT 
LOCAL 
REMOTE

self+OUT in one VRF 
LOCAL REMOTE in ONE VRF 

where is issue here, I dont see any security issue with above 

[andypowernet]

Hi,

The issue is that the customer and guest vrf have to be kept seperate.  

[Aref Alsouqi]

Could you please try to swap ISE IP address with any on the ZBF ACLs and see if that makes any difference? this would help us ruling out any NAT'ing issue, if that doesn't make a difference, could you please remove temporarily the guest and customer interfaces from the ZBF? this would help confirming if routing is working as expected in the first place. You mentioned ping is working from the guest interface, however, ping is stateless so if the echo packets go one way and the replies come on another ping doesn't bother. In other words if you have asymmetric routing ping would still work, but the traffic destined to ISE portal won't as it uses TCP.

[MHM Cisco World]

R1#wr

hostname R1
!
ip vrf Cos
rd 1:200
!
ip vrf ISP
rd 1:100
!
class-map type inspect match-all L-R-Licmp
match protocol icmp
match access-group 100
class-map type inspect match-all R-L-Rtelnet
match access-group 110
match protocol telnet
class-map type inspect match-all L-R-Ltelnet
match protocol telnet
match access-group 100
class-map type inspect match-all L-R-L
match protocol icmp
match protocol telnet
match protocol ssh
match access-group 100
class-map type inspect match-all R-L-Ricmp
match access-group 110
match protocol icmp
class-map type inspect match-all L-R-L2
match access-group 100
!
!
policy-map type inspect R-L-R
class type inspect R-L-Ricmp
inspect
class type inspect R-L-Rtelnet
inspect
class class-default
policy-map type inspect L-R-L
class type inspect L-R-Licmp
inspect
class type inspect L-R-Ltelnet
inspect
class class-default
!
zone security OUT
zone security LOCAL
zone security REMOTE
zone-pair security L-R-L source LOCAL destination REMOTE
service-policy type inspect L-R-L
zone-pair security R-L-R source REMOTE destination LOCAL
service-policy type inspect R-L-R
!
!
!
!
interface Tunnel0
ip vrf forwarding Cos
ip address 5.0.0.1 255.255.255.0
zone-member security REMOTE
tunnel source FastEthernet0/1
tunnel destination 200.0.0.2
tunnel vrf ISP
!
interface FastEthernet0/0
ip vrf forwarding Cos
ip address 10.0.0.1 255.255.255.0
zone-member security LOCAL
duplex auto
speed auto
!
interface FastEthernet0/1
ip vrf forwarding ISP
ip address 100.0.0.1 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route vrf ISP 0.0.0.0 0.0.0.0 100.0.0.5
ip route vrf Cos 20.0.0.0 255.255.255.0 Tunnel0
!
access-list 100 permit ip 10.0.0.0 0.0.0.255 20.0.0.0 0.0.0.255
access-list 110 permit ip 20.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255

this LAB for you GRE with VRF and multi security Zone 

NO issue I can ping from both side of tunnel 

[andypowernet]

Hi,

Thanks for the info.  I've actually managed to resolve this by amending the guest-to-inside and inside-to-guest policy maps to a state of pass rather than inspect.  Not entirely sure why that has resolved the issue, and why inspect wasn't statefully allowing the return traffic.  Not sure if there is any interoperability with the inspect command whilst routing over dmvpn or if it's a bug.  But, it's working.

[MHM Cisco World]

Thans for update me

In end how many zone you config three or four?

[andypowernet]

Hi,

No configuration was changed from the initial post in the end, other than amending inspect to pass.

Cheers.