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

[MHM Cisco World]

only TCP, what about DNS ? I think you need to include the DNS in ACL of policy map

[Marius Gunnerud]

Adding to what MHM has mentioned, you would probably need to add entries for DNS and DHCP depending on where your DNS and DHCP servers are located and how the guest network accesses them.

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. <-- need to swap the source and destination networks for ICMP to work

[andypowernet]

ICMP is actually working (if i source from gi0/0/1.40 in the guest zone)
It's telnet on tcp 8443 that is failing.  All dhcp services are working correctly....

[MHM Cisco World]

only one thing then, the using of real or mapped IP, 
if you use real change it to mapped IP.

[andypowernet]

Hi,

Thanks for your replies.

Where are you referring to a mapped IP?

Regards,
Andy.

[MHM Cisco World]

10.248.196.39 <<- this IP the and GUEST is config with IP NAT INSIDE

[andypowernet]

Hi,

The nat is only applicable to traffic leaving the ouside interface,  not Guest to Inside as in this case:

ip nat inside source route-map NAT interface GigabitEthernet0/0/0 vrf internet overload

[MHM Cisco World]

show policy-map type inspect zone-pair sessions <<- for both Zone-pair 

NOTE:- please confirm that the packet initiate from interface  0.0.1.40 to tunnel to Server 
NOTE:- why the VRF in interface 0.0.1.40 is INTERENT and the tunnel is costumer ?

[andypowernet]

Hey.

Yes, the customers packet who is trying to access the ISE guest portal arrives on the 0/0/1.40 interface.  That is also where i'm testing telnet from (sourcing it from that interface)

The reason it sits on a different VRF is that 0/0/1.40 is in the guest vrf so just local internet breakout, however the route to ISE is leaked from the corporate vrf in to the internet vrf.  And that route's next hop is via a tunnel.  ICMP sourced from 0/0/1.40 is working so to the ISE server so quite a strange scenario,  (especially given that the maps don't seem be getting matched - info requested by yourself below)

Zone-pair: GUEST-TO-INSIDE
Service-policy inspect : GUEST-TO-INSIDE

Class-map: GUEST-TO-INSIDE (match-any)
Match: access-group name ZBF-GUEST-TO-INSIDE
Inspect

Class-map: class-default (match-any)
Match: any
Drop
0 packets, 0 bytes

Zone-pair: INSIDE-TO-GUEST
Service-policy inspect : INSIDE-TO-GUEST

Class-map: INSIDE-TO-GUEST (match-any)
Match: access-group name ZBF-INSIDE-TO-GUEST
Inspect

Class-map: class-default (match-any)
Match: any
Drop
0 packets, 0 bytes

[MHM Cisco World]

OK, 
interface GigabitEthernet0/0/1.40
vrf forwarding customer
zone-member security GUEST
!
interface GigabitEthernet0/0/0
vrf forwarding internet
!
interface Tunnel196
vrf forwarding customer
zone-member security INSIDE
tunnel source GigabitEthernet0/0/0
tunnel vrf internet
tunnel protection ipsec profile dmvpn-ipsec-profile shared <<- this need since you use same interface for both tunnel

this must be the config of tunnel and interface 

[andypowernet]

Hey.

There is only a single tunnel configured on this router, hence no shared keyword when referencing the ipsec protection.

Regards,
Andy.

[MHM Cisco World]

your post show two, then I check the tunnel number is same, so no need shared 
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

[andypowernet]

Interestingly, I did some further debugging on this, and it shows packets being dropped arriving on the tunnel interface (inside zone) destined for the guest zone.  However it's showing the source as the remote tunnel endpoint rather than the original source.

That would suggest to me that it is processing the ZBF prior to decapsulation of the DMVPN headers, however Cisco documentation states otherwise....

%IOSXE-6-PLATFORM: SIP0: cpp_cp: QFP:0.0 Thread:000 TS:00031902468136318644 %FW-6-DROP_PKT: Dropping udp pkt from Tunnel196 195.88.236.250:4500 => 10.192.203.1:33446(target:class)-(INSIDE-TO-GUEST:class-default) due to Policy drop:classify result with ip ident 18807

[MHM Cisco World]

Did you try config I suggest before ?

interface GigabitEthernet0/0/1.40
vrf forwarding customer
zone-member security GUEST
!
interface GigabitEthernet0/0/0
vrf forwarding internet
!
interface Tunnel196
vrf forwarding customer
zone-member security INSIDE
tunnel source GigabitEthernet0/0/0
tunnel vrf internet
tunnel protection ipsec profile