Latest download from file exchange completed; As I expected, the CUE version is 8.0.3 (RC3). My question, where do I get the UK localization files that will work with this? They don't seem to exist. Am I also right in thinking I need to stick with 7.1.3 to ensure I can have a localized CUE that doesnt suffer from the recent Jitter voicemail bug with UC560? If so, which version of the software pack should I be using? Also, to add insult to injury, the 8.0.5 download seems to be completley corrupt; !   C:\Documents and Settings\Administrator\Desktop\UC560_8.0.5.zip: The archive is corrupt !   C:\Documents and Settings\Administrator\Desktop\UC560_8.0.5.zip: The archive is corrupt !   C:\Documents and Settings\Administrator\Desktop\UC560_8.0.5.zip: CRC failed in uc500-advipservicesk9-mz.150-1.XA3a. The file is corrupt So that was another 30 minute 250MB download time wasted! Why is it that there is ALWAYS so much trouble getting UC5xx files correct/compatible? I have never deployed a UC5xx system without running into some silly problem such as this right off the bat; and if i leave the factory-shipped IOS on the device, I end up running into crashdump terriroty due to bugs in CUE. Currently feeling like I can't win and it's always the customer that suffers for delayed deployment times/bugs/crashes. Any feedback would be appriciated, as would the location of a working, localized 8.0.2/8.0.3/UC560 package with no known major show-stopping bugs. Thanks again, Matt ... View more

OK, removed the cmap the packet was getting dropped on, so the current self to wan zone-pair policy map looks like this: policy-map type inspect pm-selftowan class type inspect cm-selftowan-he-out   inspect class type inspect cm-dhcpwan   pass class class-default   drop ! class-map type inspect match-all cm-selftowan-he-out match access-group name HETunnelOutbound ip access-list extended HETunnelOutbound permit 41 any any permit ip any host 64.62.200.2 permit ip any host 66.220.2.74 permit ip any host 216.66.80.26 Now we see the same error, just on the 'new' first cmap in the pmap: *Oct  5 02:39:31.316 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session :0 216.66.80.26:0 on zone-pair selftowan class cm-selftowan-he-out due to  Invalid Segment with ip ident 0 Yet as you can see above, we are allowing proto 41 any any. I didn't expect any other result really since the previous cmap had 'permit ip any any' but still any ideas? Thanks, //TrX EDIT: Out of curiosity after reading this post: https://supportforums.cisco.com/thread/2043222?decorator=print&displayFullThread=true I decided to change the outbound cm-selftowan-he-out action to 'pass'. I suddently noticed the following log: *Oct  5 02:39:31.316 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session  216.66.80.26:0 :0 on zone-pair wantoself class  cm- wantoself-he-in due to  Invalid Segment with ip ident 0 Notice this is now inbound having trouble where as before was outbound. I changed the inbound pmap policy for cmap cm-wantoself-he-in to pass also and IPv6 PACKETS ARE GETTING ICMP6 REPLIES FROM GOOGLE! Looking at the original outbound PMAP: policy-map type inspect pm-selftowan class type inspect cm-selftowan   inspect class type inspect cm-selftowan-he-out   inspect class type inspect cm-dhcpwan   pass class class-default   drop cm-selftowan has always been infront of cm-selftowan-he-out, and because that is ip any any, it has been 'grabbing' the IP proto 41 packets and doing ip inspect on them (which fails as it seems ip inspect only handles a handful of proto's). This is why setting cm-selftowan-he-out and cm-wantoself-he-in both to 'pass' instead of 'inspect' in the past has not been doing anything, because the outbound packets were never getting to the cm-selftowan-he-out cmap. Would never have got to this without ip inspect log. Why didn't I think of just trying ip inspect logging two days ago! Anyway, thank you, I have now restored my faith in my own knowledge of ZBF! Hope this helps the OP too //TrX ... View more

Thanks, That makes sense as ZBF is still using the underlying ip inspect. Anyway, on ping6 ipv6.google.com I get the following single line of drop log: *Oct  5 02:21:24.740 GMT: %FW-6-DROP_PKT: Dropping Unknown-l4 session :0 216.66.80.26:0 on zone-pair selftowan class cm-selftowan due to  Invalid Segment with ip ident 0 Unknown L4 session, suggests my outbound Self to WAN zone does not have a classmap matching the outbound traffic type. Also, doing a quick google (found one of your other forum posts in the result actually) suggests 'Invalid Segment with ip ident 0' issues on ZBF could be caused by a class-map matching an access-list with more than one entry. However, as you can see from my config, the only entry I have in cm-selftowan is a 'permit ip any any' ACL. The traffic does not seem to be getting past this cmap though and onto the specially defined cmap below it which permit's the HE.net tunnel dest address (this logic coming from the fact that 'class cm-selftowan' is listed in the drop log above) I will try removing this cmap and just leaving the cm-selftowan-he-out cmap in place (so we know the ZBF is looking at that cmap first). However, can you think of a reason why 'permit ip any any' wlould not be working :S? Due to this I don't have much hope that what I am about to try will work. Back with updates soon. ... View more

Adding full IOS config for clarity (attached). This config is not in production use so can test changes if needbe. ... View more

Small world, I was just about to post a forum thread with exactly the same question. Creating a tunnel (type ipv6ip) to HE's tunnelbroker.net service. ZBF between WAN and LAN interfaces for existing IPv4 traffic already setup. As I understand it, IPv6 traffic will be ignored by ZBF and indeed I do see this behaviour, as I can ping the LOCAL tunnel endpoint IPv6 IP from a host on my LAN with an IPv6 address. However, I cannot get IPv6 traffic any further (ie, up the tunnel) unless I remove the WAN interface from the ZBF configuration. I have tried the following to get around this but to no avail: - policy map to 'pass' IP ANY ANY to the dest of the tunnel brokers IPv4 address on a SELF to WAN zone pair - policy map to 'pass' IP ANY ANY from the dest of the tunnel brokers IPv4 address on a WAN to SELF zone pair - both of the policy maps above at the same time - both of the policy maps above with inspect actions instead of pass - both of the policy maps above but with IP proto 41 any any instead of IP any any with the IP of the remote tunnel endpoint (as proto 41 is ipv6ip) But NONE of these work, if I ping6 ipv6.google.com I get no replies, as soon as I do a 'no zone-member security ZBF-WAN' on the WAN interface, the pings are fine. The only other thing I could think of is where within the black box of cisco IOS does IOS actually 'create' the tunnel traffic, ie, is it from SELF zone or is it from the tunnel interface itself? To test this I added the tunnel interface to the WAN ZBF zone (as interfaces in the same zone should be able to communicate) but this did not help either. Have spent two days on this and am fully stumped! Also, there don't seem to be any decent ZBF debug commands that show you each dropped packet and why they were dropped (ie which pmap/inspect class map caused the drop) if you know any please let me know Thanks in advance, //TrX ... View more