Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
5073
Views
5
Helpful
1
Comments

CWS Tunnel Connector on ISR 4K - Troubleshooting

Kureli Sankar
Cisco Employee
Cisco Employee

‎03-23-2016 07:11 PM - edited ‎03-08-2019 06:59 PM

 

CWS Tunnel Connector FAQ

https://supportforums.cisco.com/document/12949576/cisco-cloud-web-security-cws-tunnel-connector-isr-4k-faq

CWS Tunnel Connector - Step-by-Step Guide

https://supportforums.cisco.com/document/12713171/isr-cws-tunnel-based-redirection-step-step-configuration

CWS Tunnel Connector - Troubleshooting

Tunnel does not come up

ISR is unable to resolve names

If the parameter-map is configured using the tower names, make sure the router can resolve the names. For the router to resolve names, ISR4k should be configured to resolve DNS: Configure ISR4k for DNS resolution. 

CWS-Tunnel-RTR#ping ctr.access509.cws.sco.cisco.com
% Unrecognized host or address, or protocol not running

Incorrect Tower IP addresses configured

Check if you are using the wrong IP address for the access towers. For example in this case the towers provided were

Primary: access509.cws.sco.cisco.com
Backup: access609.cws.sco.cisco.com

These above names resolve to 108.171.129.136 and 108.171.133.136 and these IPs were used in the parameter map as follows:

CWS-Tunnel-RTR(config)#parameter-map type cws-tunnel global
 CWS-Tunnel-RTR(config-profile)# primary
 CWS-Tunnel-RTR(config-cws-pri)#  tower ipv4 108.XX.XX.136
 CWS-Tunnel-RTR(config-cws-pri)# secondary
 CWS-Tunnel-RTR(config-cws-sec)#  tower ipv4 108.XX.XX.136
 CWS-Tunnel-RTR(config-cws-sec)# license 0 CF0DA2A32BA7687F77054D4E4
CWS-Tunnel-RTR#sh crypto ikev2 sa
  IPv4 Crypto IKEv2  SA
 
 Tunnel-id Local                 Remote                fvrf/ivrf            Status
 2         192.168.2.66/500      108.XX.XX.136/500   INET/none            IN-NEG
       Encr: Unknown - 0, PRF: Unknown - 0, Hash: None, DH Grp:0, Auth sign: Unknown - 0, Auth verify: Unknown - 0
       Life/Active Time: 86400/0 sec

It is recommended to use the names of the towers as they were provided to you.  In case if you need to use the IP address, then make sure to configure the ISR for name resolution and then try to ping ctr.access509.cws.sco.cisco.com and ctr.access609.cws.sco.cisco.com which will actually resolve to 108.171.129.200 and 108.171.133.200.  Notice the "ctr" prefix.  The ISR will automatically add "ctr" as prefix to the provided tower name once configured on the ISR.

 

CWS-Tunnel-RTR(config)#parameter-map type cws-tunnel global
 CWS-Tunnel-RTR(config-profile)# primary
 CWS-Tunnel-RTR(config-cws-pri)#  tower ipv4 108.XX.XX.200
 CWS-Tunnel-RTR(config-cws-pri)# secondary
 CWS-Tunnel-RTR(config-cws-sec)#  tower ipv4 108.XX.XX.200
 CWS-Tunnel-RTR(config-cws-sec)# license 0 CF0FDDA22BB7A787F77054D4E4
OR
  CWS-Tunnel-RTR(config)#parameter-map type cws-tunnel global
 CWS-Tunnel-RTR(config-profile)# primary
 CWS-Tunnel-RTR(config-cws-pri)#  tower name accessXXS.cws.sco.cisco.com
 CWS-Tunnel-RTR(config-cws-pri)# secondary
 CWS-Tunnel-RTR(config-cws-sec)#  tower ipv4 accessXXX.cws.sco.cisco.com
 CWS-Tunnel-RTR(config-cws-sec)# license 0 CF0FDDA32BB77687F77054D4E4

Problem solved. Tunnel shows up.

CWS-Tunnel-RTR#sh cry ikev2 sa
 IPv4 Crypto IKEv2  SA 
Tunnel-id Local                 Remote                fvrf/ivrf            Status 
3         128.107.237.254/4500  108.XX.XX.200/4500  INET/INET             READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign: EAP, Auth verify: RSA
      Life/Active Time: 86400/34930 sec
 IPv6 Crypto IKEv2  SA

"ip unnumbered" missing

For testing purpose "ip vrf forwarding" command was removed and re-added to both the tunnel interface. When the command it removed it also removes "ip address" or "ip unnumbered" command under the tunnel interface.  When "ip vrf forwarding" is re-added under the tunnel interface, it does not automatically re-add the "ip address" or "ip unnumbered" command back. 

Removing it from a physical interface will result in an error message but this isn't the case when the command is removed from the tunnel interface.
 

Warning error message present in case of physical interface:

CWS-Tunnel-RTR(config)#int g0/0/0
CWS-Tunnel-RTR(config-if)#no ip vrf forwarding INET   
% Interface GigabitEthernet0/0/0 IPv4 disabled and address(es) removed due to enabling VRF INET

No warning message present in case of tunnel interface:

CWS-Tunnel-RTR#sh run int t100   
Building configuration...

Current configuration : 87 bytes
interface Tunnel100
 ip vrf forwarding INET
 ip unnumbered GigabitEthernet0/0/0
end

CWS-Tunnel-RTR#
CWS-Tunnel-RTR#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
CWS-Tunnel-RTR(config)#int t100
CWS-Tunnel-RTR(config-if)#no ip vrf forwarding INET
CWS-Tunnel-RTR(config-if)#do sh run int t100
Building configuration...

Current configuration : 42 bytes
!
interface Tunnel100
 no ip address
end

Tunnel does not come up due to fragmentation issues.

If all the configuration is correct, try this command to set a lower MTU so packets will be fragmented to smaller chunks. Fragmentation seems to be the issue if you see the following for IKV2 debugs - debug crypto ikev2

Mar 24 13:28:56.241 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Process auth response notify
Mar 24 13:28:56.242 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Searching policy based on peer's identity '10.4.92.62' of type 'IPv4 address'
Mar 24 13:28:56.250 PDT: IKEv2-ERROR:(SESSION ID = 94773,SA ID = 3):: Failed to locate an item in the database
Mar 24 13:28:56.250 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Verification of peer's authentication data FAILED
Mar 24 13:28:56.250 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Auth exchange failed
Mar 24 13:28:56.251 PDT: IKEv2-ERROR:(SESSION ID = 94773,SA ID = 3):: Auth exchange failed
Mar 24 13:28:56.251 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Abort exchange
Mar 24 13:28:56.255 PDT: IKEv2:(SESSION ID = 94773,SA ID = 3):Deleting SA

Please add this below command to lower the MTU for IKV2 authentication packets.

ISR-4451(config)#cry ikev2 fragmentation mtu 1200

Tunnel comes up but traffic is not getting redirected

Egress interface missing "cws-tunnel out"

First and foremost thing to check is routing.  Determine which egress interface the router will use to forward the packet out and make sure that interface has "cws-tunnel out" configured.

Router not running the correct image version

Make sure the router is running XE 3.16.1 or above. In this case the output was captured with the router running XE 3.16 where CWS wasn't officially supported.

CWS-Tunnel-RTR#sh cws-tunnel status 
GigabitEthernet0/0/0-Tunnel100: Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect

Interface: Tunnel100
Profile: cws_ikev2_profile_100
Uptime: 00:44:00
Session status: UP-ACTIVE     
Peer: 108.171.129.200 port 4500 fvrf: INET ivrf: INET
      Phase1_id: 10.3.92.56
      Desc: (none)
  Session ID: 4  
  IKEv2 SA: local 128.XX.XX.254/4500 remote 108.XX.XX.200/4500 Active 
          Capabilities:DNX connid:2 lifetime:23:16:00
  IPSEC FLOW: permit 47 host 128.XX.XX.254 host 108.XX.XX.200 
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/960
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4608000/960

Incorrect redirect ACL

Make sure the redirect ACL included all the LAN subnets interested in CWS

Incorrect towers configured

On a host that gets redirected to CWS, open the browser and go to http://whoami.scansafe.net. The logicalTowerNumber -1 is incorrect.  It should be a 5 digit number like  logicalTowerNumber: 10509

--- 
 authUserName: 172.18.11.11
 authenticated: true
 companyName: IWAN with CWS Demo
 connectorVersion: "tun-ISR-15.5(3)S1a,"
 countryCode: US
 externalIp: 128.XX.XX.254
 groupNames: []
 internalIp: 172.18.111.31
 logicalTowerNumber: -1
 staticGroupNames: 
   - default
 userName: 172.18.111.31

Browser is configured with an explicit proxy

Make sure that the browser is not configured with a proxy. If it does then you would see local NAT getting created for port 80 and 443 traffic like this below. If you see local NAT being created on the router, then that traffic is not getting redirected to the CWS tower at all.

POD1-ISR4451#sh ip nat translations | i 30.30
 tcp  128.107.213.183:4128  10.20.30.30:49370     10.15.255.245:80      10.15.255.245:80
 tcp  128.107.213.183:4096  10.20.30.30:49373     10.15.255.245:80      10.15.255.245:80

Uncheck the proxy setting on the client's browser. Make sure to choose "no proxy" and click "OK".

CWS redirection works for some clients but not others

In some cases CWS redirection may work for certain clients/hosts behind the router but not for others inspite of both working and non-working hosts being on the same subnet. In this case problem was seen with specific android devices while other android devices worked fine. After the 3-way handshake where MSS is negotiated was seen on the packet captures but the page load stalled. 

When a host initiates a TCP session with a server, it negotiates the IP segment size by using the MSS option field in the TCP SYN packet. The actual MSS between two end points is derived as below.

  • MSS = MinPathMTU - MinTCPHeaderLen - MinIPHeaderLen = MTU - 20 - 20 = MTU - 40.
  • When GRE over IPsec Tunnel involved, GRE header + GRE IP Header = 4 + 20 = 24 and IPSec overhead is approx 60 to 72 depending on the encryption used.
  • Interface on the ISR only supports 1500 MTU which means TCP MSS value of 1360 would be safe for an end-to-end TCP session over a GRE-IPSEC Tunnel.

With this in mind if we configure the following on both the CWS tunnel interfaces, these android devices should be able to load the web pages without any problem.

interface Tunnel100
 ip unnumbered GigabitEthernet0/0/0
 ip tcp adjust-mss 1360

interface Tunnel101
 ip unnumbered GigabitEthernet0/0/0
 ip tcp adjust-mss 1360

Whitelist ACL with object-group (not supported)

Tunnel comes up but shows no ecaps or decaps. ISR is providing translation for port 80 and 443 packets which it shouldn't if these packets were to take the tunnel and re-directed. This command below clearly indicates that all traffic is being whitelisted and no packets are re-directed.

ISR-4451#show platform hardware qfp active feature cws datapath stat  
Connector Global Statistics:
==========================

Total Number of Route Lookups:                                            0
Total Number of Whitelisted Packets:                                      26994

Connector WAN Statistics:
==========================

WAN interface :GigabitEthernet0/0/0
     Total Number of Packets redirected:                                  0
     Total Number of NSH encaps added to connector traffic:               0
     Total Number of Pkts dropped because of fail-close:                  0
     Total Number of Pkts skipped because of fail-open:                   0

This is the parameter map that was configured on the router

parameter-map type cws-tunnel global
 logging
 fail-open
 primary
  tower name AcXXX.cws.sco.cisco.com
 secondary
  tower name AXXXX.cws.sco.cisco.com
 license 7 XXXXXXXXXXXXXXXXXX10E0E71
 redirect-list 50
 whitelist
  acl name exempt-ranges

Notice the object-groups used in the whitelist ACL? This is not supported. Pls. refer to this link: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_cws/configuration/xe-16/sec-data-cws-xe-16-book/cws-tunneling.html#reference_929E18E4FB5548ADBB10A8563CC67240
Object-group ACLs are not supported for ACL based whitelisting and redirect list configuration. 

ISR-4451#sh access-list exempt-ranges
Extended IP access list exempt-ranges
    10 permit ip any 10.0.0.0 0.255.255.255
    20 permit ip any object-group IBM
    30 permit ip any object-group Microsoft-Updates
    40 permit ip any object-group ATL-Ext
    50 permit ip any object-group Subs

Once we removed the object-groups in the ACL, encap and decap counts incremented for the cws-tunnel status output and packets got redirected.

4451#sh cws-tunnel status

GigabitEthernet0/0/0-Tunnel200: Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection     
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation     
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect

Interface: Tunnel200
Profile: cws_ikev2_profile_200
Uptime: 00:00:08
Session status: UP-ACTIVE     
Peer:10X.1X1.1XX.XX port 4500 fvrf: (none) ivrf: (none)
      Phase1_id: 10.3.60.69
      Desc: (none)
  Session ID: 11584  
  IKEv2 SA: local 1XX.XX.1XX.XX/4500 remote 10X.1X1.1XX.XX/4500 Active 
          Capabilities:DNX connid:1 lifetime:23:59:52
  IPSEC FLOW: permit 47 host 1XX.XX.1XX.XX host 10X.1X1.1XX.XX
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 46 drop 0 life (KB/Sec) 4607989/3592
        Outbound: #pkts enc'ed 73 drop 0 life (KB/Sec) 4607971/3592

Tunnel comes "up" but only encap count is incrementing

In the following output we see pkts enc'ed is at 200543 but the pkts dec'ed count is at 0

Upon investigating we came to find out that the the redirect ACL was modified to correct the subnet after the tunnel had come up. If the ACL is modified then make sure to bring the tunnel down and up again so the newly added subnets will be included in the RRI that will be used by the tower side to route traffic back to the subnets listed in the redirect ACL.

CWS-Tunnel-RTR#sh cws-tunnel status 

GigabitEthernet2-Tunnel100: Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect

Interface: Tunnel100
Profile: cws_ikev2_profile_100
Uptime: 03:23:59
Session status: UP-ACTIVE
Peer: 108.XX.XX.193 port 4500 fvrf: (none) ivrf: (none)
      Phase1_id: 10.3.92.42
      Desc: (none)
  Session ID: 3
  IKEv2 SA: local 7.X.X.27/4500 remote 108.XX.XX.193/4500 Active
          Capabilities:DNX connid:4 lifetime:20:36:01
  IPSEC FLOW: permit 47 host 7.X.X.27 host 108.XX.12XX9.193
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/1580
        Outbound: #pkts enc'ed 200543 drop 0 life (KB/Sec) 4608000/1580

VRF mismatch error

While configuring zones under the tunnel interface the error "%VRF mismatch. All interfaces in a zone must be in the same VRF" is seen.  The reason for this is that the outside internet facing interface is in a vrf called INET and it is on a zone called Outside. Now, we need to add both the CWS tunnel interfaces to the same VRF and same zone.  In addition to that we also need to make sure to add the vrf information under the IKEV2 profile as well.  Please refer to this link for further reading:

CWS interaction with VRF

If VRF is configured on WAN interface where cws-tunnel out is configured, change the autogenerated Cloud Web Security configuration to the following:
 
  • Add command match fvrf name-of-vrf under dynamically generated Cloud Web Security IKEv2 profile. For example, if WAN interface is configured to be part of VRF ISP, add match fvrf ISP under cws_ikev2_profile_<tunnel_number>.
 
  • Add command tunnel vrf name-of-vrf and vrf forwarding name-of-vrfunder dynamically generated Cloud Web Security tunnel interface.

If cws-tunnel out command is removed and reapplied on WAN interface, the VRF information on Cloud Web Security tunnel interfaces and IKEv2 profile has to be reconfigured.

CWS-Tunnel-RTR-(config-ikev2-profile)#interface GigabitEthernet0/0/2
CWS-Tunnel-RTR-(config-if)description Internet Facing Interface
CWS-Tunnel-RTR-(config-if)#ip address dhcp
CWS-Tunnel-RTR-(config-if)#ip nat outside
CWS-Tunnel-RTR-(config-if)#vrf forwarding INET
CWS-Tunnel-RTR-(config-if)#zone-member security Outside
CWS-Tunnel-RTR-(config-if)#cws-tunnel out tunnel-number 100
"cws-tunnel out" already configured on interface.

CWS-Tunnel-RTR-(config-if)#interface Tunnel100
CWS-Tunnel-RTR-(config-if)#description CWS connector internal primary tunnel
CWS-Tunnel-RTR-(config-if)#zone-member security Outside
%VRF mismatch. All interfaces in a zone must be in the same VRF

CWS-Tunnel-RTR-(config-if)#interface Tunnel101
CWS-Tunnel-RTR-(config-if)#description CWS connector internal secondary tunnel
CWS-Tunnel-RTR-(config-if)#zone-member security Outside
%VRF mismatch. All interfaces in a zone must be in the same VRF
CWS-Tunnel-RTR-(config-if)#exit

Internet access fails despite all outputs show proper status

Route Leaking via ip policy route-map

show cws-tunnel status
show cws-tunnel statistics
show that tunnel is up and is passing and receiving packets. Still the client behind the router is unable to go to the internet when CWS is enabled.
Interface: Tunnel500
Profile: cws_ikev2_profile_500
Uptime: 00:33:13
Session status: UP-ACTIVE
Peer: 108.171.131.208 port 4500 fvrf: IWAN-TU200 ivrf: IWAN-TU200
      Phase1_id: 10.3.220.71
      Desc: (none)
  Session ID: 3
  IKEv2 SA: local 97.71.123.170/4500 remote 108.171.131.208/4500 Active
          Capabilities:DNX connid:3 lifetime:23:26:47
  IPSEC FLOW: permit 47 host 97.71.123.170 host 108.171.131.208
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 6065 drop 0 life (KB/Sec) 4607668/1606
        Outbound: #pkts enc'ed 2571 drop 0 life (KB/Sec) 4607721/1606

Route leaking between global and f-vrf was done via route-map and it wasn't manually replicated to the tunnel interfaces.

interface GigabitEthernet0/0/0
 description INTERNET
 bandwidth 10000
 vrf forwarding IWAN-TU200
 ip address XX.XX.XX.XX 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 zone-member security OUTSIDE
 cws-tunnel out tunnel-number 500
 ip policy route-map INET-INTERNAL
 load-interval 30
 negotiation auto

The highlighted red text route-map needs to be manually added to both the CWS tunnel interfaces.

Pls. add the following red test route-map under the tunnel interfaces:

interface Tunnel500
 description CWS connector internal primary tunnel
 backup interface Tunnel501
 vrf forwarding IWAN-TU200
 ip unnumbered GigabitEthernet0/0/0
 zone-member security OUTSIDE
 tunnel source GigabitEthernet0/0/0
 tunnel destination XX.XX.XX.XX
 tunnel vrf IWAN-TU200
 tunnel protection ipsec profile cws_ipsec_profile_500
 ip policy route-map INET-INTERNAL
!
interface Tunnel501
 description CWS connector internal secondary tunnel
 vrf forwarding IWAN-TU200
 ip unnumbered GigabitEthernet0/0/0
 zone-member security OUTSIDE
 tunnel source GigabitEthernet0/0/0
 tunnel destination XX.XX.XX.XX
 tunnel vrf IWAN-TU200
 tunnel protection ipsec profile cws_ipsec_profile_500
 ip policy route-map INET-INTERNAL

This should resolve the problem and the client should be able to browse the internet when CWS is enabled.

Route Leaking

In case route leaking is not done via ip policy route-map like the case above, care must be taken to leak routes both ways. In some cases the LAN interface is in a VRF and the WAN interface is in the global and it other cases the WAN interface is in the global and the LAN interface is in a VRF. 

Let us assume the following:

  1. All the CWS configuration is correct and the tunnel shows up fine. encaps and decaps are incrementing
  2. Router is not providing translation for the client traffic (meaning traffic redirection is fine).
  3. Client is able to get DNS resolution fine. 
  4. Still page doesn't load on the client's browser.

We identified that the default route from LAN vrf to global WAN was correct but for the returned traffic from the portal, upon decrepting the packets, the route from global WAN to the vrf LAN subnet was incorrect. 

So, even though we see return traffic coming back from the portal (decaps incrementing), response packets didn't make it back to the client. 

Whitelist Download from Tower not working

First, we need to understand how whitelist download from the tower feature works. Two things that need to happen before WL (Whitelist) would work.

  1. Name resolution has to work fine to get the IP mapping for the whitelist download page to the WL server which is cwsuploads.sco.cisco.com ==> 80.254.145.86
  2. Next, the router sends as tcp request via the tunnel on port 443 to grab the whitelist that is configured on the tower side portal.
Non-working due to DNS failure:
 
4451#debug cws-tunnel whitelist
*Aug 30 22:30:20.579: CWS-TUN-WHITELIST:TIMER EVENT
*Aug 30 22:30:20.579: CWS-TUN-WHITELIST:CWS WL DLD timer event: tmr 561C5C77BBA0
*Aug 30 22:30:20.579: CWS-TUN-WHITELIST:Found channel
*Aug 30 22:30:20.579: CWS-TUN-WHITELIST:Found channel
*Aug 30 22:30:20.579: CWS-TUN-WHITELIST:contacting DNS server to resolve the server cwsuploads.sco.cisco.com
*Aug 30 22:30:28.581: CWS-TUN-WHITELIST:channel connect failed: destination server ip not resolved.Same will be resolved on next connect
*Aug 30 22:30:28.581: CWS-TUN-WHITELIST: Could not connect WL Channel

Non-working due to WL server reachability failure:
In this case there is a problem with the whitelist site.  DNS resolution worked but, the router was not able to complete the tcp handshake with the WL server on the head end.
 
ISR4451# debug cws-tunnel whitelist
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Trying to send messages to CWS
whitellist process
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Whitelist download timer started
for  interval of 6 minutes
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Message sent to whitelist process
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Domain Whitelist item enqueued
to whitelist process: Domain whitelist config state: CLI Disabled:
Download Enabled
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:QUEUE EVENT: Domain whitelist
config state: CLI Disabled: Download Enabled
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Cannot add domain whitelist
patterns to DSA: Nothing to add
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:MESSAGE EVENT
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:CWS Message event:WL DLD start
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Found channel
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:Found channel
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:channel connect : resolved OOB
server ip:80.254.145.86
*Aug 17 13:23:50.575: CWS-TUN-WHITELIST:channel connect:
TCP_DONTROUTE_IOS nexthop 108.171.130.209
*Aug 17 13:23:50.576: CWS-TUN-WHITELIST:channel: Connecting to
80.254.145.86(443) from src 67.132.8.22: socket 0: status -1: errno 11
channel status0
*Aug 17 13:23:50.576: CWS-TUN-WHITELIST:UNKNOWN EVENT 128
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST: SOCKET EVENT
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST:Found channel
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST:Write socket event on socket 0
for channel
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST:
*Aug 17 13:24:20.576:  WL Req sent: GET /ISR/exception_list HTTP/1.1
Host: cwsuploads.sco.cisco.com
Accept: text/xml
If-Modified-Since:
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST:TCP Channel is not connected:
errno 257
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST:Cleaning up the channel
*Aug 17 13:24:20.576: CWS-TUN-WHITELIST: SOCKET EVENT

Working whitelist download debug:

*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Trying to send messages to CWS whitellist process
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Whitelist download timer started for  interval of 6 minutes
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Message sent to whitelist process
*Nov  1 14:47:14.991: %PARSER-5-CFGLOG_LOGGEDCMD: User:demotme  logged command:download interval 6
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:MESSAGE EVENT
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:CWS Message event:WL DLD start
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:channel connect : resolved OOB server ip:80.254.145.86 
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:channel connect: TCP_DONTROUTE_IOS nexthop 108.171.135.219
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:Active oob tunnel vrfid is 2
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:channel: Connecting to 80.254.145.86(443) from src 128.107.213.185: socket 0: status -1: errno 11 channel status0
*Nov  1 14:47:14.991: CWS-TUN-WHITELIST:UNKNOWN EVENT 128
*Nov  1 14:47:14.995: CWS-TUN-WHITELIST:UNKNOWN EVENT 128
*Nov  1 14:47:14.995: CWS-TUN-WHITELIST: SOCKET EVENT 
*Nov  1 14:47:14.995: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:14.995: CWS-TUN-WHITELIST:Write socket event on socket 0 for channel
*Nov  1 14:47:14.995: CWS-TUN-WHITELIST:
*Nov  1 14:47:14.995:  WL Req sent: GET /ISR/exception_list HTTP/1.1
Host: cwsuploads.sco.cisco.com
Accept: text/xml
          
If-Modified-Since: 


*Nov  1 14:47:14.995: CWS-TUN-WHITELIST:channel: TCP connected on 0
*Nov  1 14:47:16.187: %SYS-5-CONFIG_I: Configured from console by demotme on vty1 (10.118.34.8)
*Nov  1 14:47:18.004: CWS-TUN-WHITELIST:SSL Handshake OK
*Nov  1 14:47:18.004: CWS-TUN-WHITELIST:channel: SSL Handshake success
*Nov  1 14:47:18.004: CWS-TUN-WHITELIST:channel: Succesfully sent 107(107) bytes on fd 0, partial count 0
*Nov  1 14:47:18.004: CWS-TUN-WHITELIST:sent_bytes: 107, buf_len: 107
*Nov  1 14:47:18.004: CWS-TUN-WHITELIST: SOCKET EVENT 
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST: SOCKET EVENT 
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:Read socket event on socket 0 for channel
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:channel: Received 259 bytes
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:CWS Tun WL DLD response: 259 bytes received
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST: CWS Tun WL resp: HTTP/1.1 200 OK
Server: nginx
Date: Wed, 01 Nov 2017 15:10:24 GMT
Content-Type: text/xml
Content-Length: 331
Access-Control-Allow-Origin: *
Last-Modified: Wed, 01 Nov 2017 11:09:28 EDT
X-Frame-Options: DENY
Keep-Alive: 60
Via: HTTP/1.1 proxy10828


*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:CWS Tun WL: Received response for GET request
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:cws_tun_wl_parse_response_code HTTP/1.1 200 OK
        
Server: nginx
Date: Wed, 01 Nov 2017 15:10:24 GMT
Content-Type: text/xml
Content-Length: 331
Access-Control-Allow-Origin: *
Last-Modified: Wed, 01 Nov 2017 11:09:28 EDT
X-Frame-Options: DENY
Keep-Alive: 60
Via: HTTP/1.1 proxy10828

*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:HTTP response parsing for  Response code is 200
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:CWS Tun WL: DLD response parsing: timestamp Wed, 01 Nov 2017 11:09:28 EDT
*Nov  1 14:47:18.343: CWS-TUN-WHITELIST:WL DLD response handling: Partial data received
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:WL DLD response: ContLen: 331, HrdLen: 259, Recv_buf_len: 259
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST: SOCKET EVENT 
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Read socket event on socket 0 for channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:channel: Received 1 bytes
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:CWS Tun WL DLD response: 1 bytes received
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST: CWS Tun WL resp: <
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:CWS Tun WL: Received response for GET request
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:WL DLD response handling: Partial data received
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:WL DLD response: ContLen: 331, HrdLen: 259, Recv_buf_len: 1
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST: SOCKET EVENT 
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Read socket event on socket 0 for channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Found channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:channel: Received 330 bytes
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:CWS Tun WL DLD response: 330 bytes received
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST: CWS Tun WL resp: ?xml version="1.0" encoding="UTF-8" standalone="no"?><scansafe-filters encoding="UTF-8">
    <whitelist-info>
        <domain>
            <domain-name>appstate.edu</domain-name>
            <domain-name>ford.com</domain-name>
        </domain>
        <ip-address/>
        <user-agent/>
    </whitelist-info>
</scansafe-filters>
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:CWS Tun WL: Received response for GET request
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:WL DLD response: ContLen: 331, HrdLen: 259, Recv_buf_len: 330
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Downloaded whitelist pattern appstate.edu
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Downloaded whitelist pattern ford.com
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Cleaning up the channel
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Domain Whitelist item enqueued to whitelist process: Domain whitelist config state: CLI Disabled: Download Enabled
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:CWS TUN WL DLD:Downloaded timestamp Wed, 01 Nov 2017 11:09:28 EDT
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:ACL list updated
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:UNKNOWN EVENT 128
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:QUEUE EVENT: Domain whitelist config state: CLI Disabled: Download Enabled
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Sending downloaded pattern appstate.edu
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Sending downloaded pattern ford.com
*Nov  1 14:47:18.344: CWS-TUN-WHITELIST:Added domain whitelist patterns to DSA
*Nov  1 14:47:18.348: CWS-TUN-WHITELIST: SOCKET EVENT

 

 

 

 
Labels:
Comments
ranjit123
Level 3
Level 3
‎06-23-2017 05:00 AM

Hello,

I am getting this error when i am trying to add the interface which is in VRF as a zone-member

“%VRF mismatch. All interfaces in a zone must be in the same VRF”

PS :---> I have outisde natting ( overload) on my WAN interface and and NAT  on LAN Interface..

Also have a VRF interface which wants to communicate to the interface with same WAN IP so i have a NAT IN on this VRF interface..

will i able to do this with my LAN interface part of a VRF and WAN in global mode

Regards,

Ranjit

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents