Unable to allow inbound ICMPv6 on ASA version 9.0(1)

[Vindemiatrix]

I have upgraded an ASA 5505 to 9.0(1) as I would like to use ipv6 version of dhcprelay. That said, I am unable to obtain a global unicast address but the link-local address is able to communication with the ISP's gateway/DHCP provider which I hope will allow v6 dhcprelay provide internal clients with IP's from the ISP. Trouble is, unsolicated inbound ICMPv6 messages from the ISP's gateway are being dropped on the way into outside interface.

 %ASA-3-313008: Denied IPv6-ICMP type=129, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside
 %ASA-3-313008: Denied IPv6-ICMP type=131, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside
 %ASA-3-313008: Denied IPv6-ICMP type=131, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside
 %ASA-3-313008: Denied IPv6-ICMP type=136, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside
 %ASA-3-313008: Denied IPv6-ICMP type=136, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside
 %ASA-3-313008: Denied IPv6-ICMP type=136, code=0 from fe80::201:5cff:fe3b:3c41 on interface outside

I am able to ping the ISP's link-local address of fe80::201:5cff:fe3b:3c41 but I would assume that is because I am initiating the connection. Below is the ASA's configuration. Any help would be appreciated.

!
ASA Version 9.0(1) 
!
hostname edge
domain-name domain.com
enable password 2KFQnbNIdI.2KYOU encrypted
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-session deny udp any6 any6 eq domain
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.255.255.0 
 ipv6 address fec0::/64 eui-64
 ipv6 enable
!
interface Vlan2
 nameif outside
 security-level 0
 ip address dhcp setroute 
 ipv6 enable
 ipv6 nd suppress-ra
!
boot system disk0:/asa901-k8.bin
ftp mode passive
dns server-group DefaultDNS
 domain-name domain.com
object network obj_any
 subnet 0.0.0.0 0.0.0.0
access-list OUTSIDE-IN extended permit icmp6 any any 
access-list OUTSIDE-IN extended permit icmp6 any any membership-report 
access-list OUTSIDE-IN extended permit icmp6 any any membership-report 0 
access-list OUTSIDE-IN extended permit icmp6 any any echo-reply 0 
access-list OUTSIDE-IN extended permit icmp6 any any echo-reply 
access-list OUTSIDE-IN extended permit icmp6 host fe80::201:5cff:fe3b:3c41 interface outside 
access-list OUTSIDE-IN extended permit icmp6 any interface outside membership-report 
access-list OUTSIDE-IN extended permit icmp6 any interface outside membership-report 0 
pager lines 24
logging enable
logging console warnings
logging monitor warnings
mtu inside 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-702.bin
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
!
object network obj_any
 nat (inside,outside) dynamic interface
!
nat (inside,outside) after-auto source dynamic any interface
access-group OUTSIDE-IN in interface outside
ipv6 icmp permit any inside
ipv6 icmp permit any membership-report outside
ipv6 icmp permit any echo-reply outside
ipv6 icmp permit any router-advertisement outside
ipv6 icmp permit any neighbor-solicitation outside
ipv6 icmp permit any neighbor-advertisement outside
ipv6 icmp permit any outside
ipv6 dhcprelay server fe80::201:5cff:fe3b:3c41 outside
ipv6 dhcprelay enable inside
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet 10.0.0.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
dhcp-client client-id interface outside
dhcpd auto_config outside
!
dhcpd address 10.0.0.101-10.0.0.200 inside
dhcpd dns 8.8.8.8 8.8.4.4 interface inside
dhcpd option 3 ip 10.0.0.1 interface inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
username cisco password 3USUcOPFUiMCO4Jk encrypted privilege 15
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect ip-options 
  inspect netbios 
  inspect rsh 
  inspect rtsp 
  inspect skinny  
  inspect esmtp 
  inspect sqlnet 
  inspect sunrpc 
  inspect tftp 
  inspect sip  
  inspect xdmcp 
!
service-policy global_policy global
prompt hostname context 
no call-home reporting anonymous
Cryptochecksum:00029d8b1ed6504390a6e607bd1772dc
: end

[WSLH OIS NOC - OIS Infrastructure]

I don't have direct experience with this configuration (I'm using asa5520's in routed mode with a /48 allocation and static native routing), so I will have to speculate a bit.

More detail about "unable to obtain a global unicast" address would be helpful.  For example, is the upstream ISP emitting router advertisements, or not?  If they are really doing v6 you should be seeing router-advertisements sourced from fe80::/64+their EUI-64 MAC mapping and probably including at least one /64 or larger prefix flagged for autoconfiguration.  Which your outside interface should be able to pick up.  Try replacing ipv6 enable with ipv6 address autoconfig, and regardless write back with the output from show ipv6 interface so we can see what's going on a little better.

In passing, there isn't really any IPv6 NAT, barring the still-experimental RFC-6296 prefix substitution.  And site-local fec0::/10 addresses were deprecated in RFC3879 back in 2004, to the point that newly conforming routers aren't allowed to even configure them as interface addresses, much less forward packets sourced from them.  So you probably need a different IPv6 routing strategy for the inside vlan.  E.g., have your ISP delegate to you a /48 or a /60 or something and put different /64 subnets on the inside and outside interfaces, with an explicit ipv6 default route, e.g

  . ipv6 route outside ::/0 fe80::201:5cff:fe3b:3c41

I don't think there is any IPv6 equivalent of setroute from "ip address dhcp setroute".

Your icmp6 commands puzzle me a little.  ipv6 icmp permit any outside is the default interface behavior, and makes all the preceding permits moot.  Maybe you are planning to replace it with a deny at some future point?  Not filtering ICMPv6 at routed interfaces is less dangerous than in the v4 case, as most of the interesting stuff has restrictions to the on-link VLAN like requiring hop limit=255 or link-local source addresses.

-- Jim Leinweber, State Lab of Hygiene at the University of Wisconsin - Madison

[Vindemiatrix]

Hi Jim, thanks for the reply.

More  detail about "unable to obtain a global unicast" address would be  helpful.  For example, is the upstream ISP emitting router  advertisements, or not?  If they are really doing v6 you should be  seeing router-advertisements sourced from fe80::/64+their EUI-64 MAC  mapping and probably including at least one /64 or larger prefix flagged  for autoconfiguration.  Which your outside interface should be able to  pick up.  Try replacing ipv6 enable with ipv6 address autoconfig, and regardless write back with the output from show ipv6 interface so we can see what's going on a little better.

I did try enabling autoconfiguration but learned that Comcast uses DHCP to distribute their residential customers /64 allocations. My link-local address was able to communicate with their gateway [fe80::201:5cff:fe3b:3c41] which also appeared to be the same device or at least an alias for their DHCP server [ff02::1:2]. I learned this after throwing a tap on the connection and obtaining an global IP with a host that could leverage DHCPv6 verse the ASA which cannot. I also tried pinging ff02::1:2  and the response would come from the aforementioned gateway link-local address but the ASA would block these responses since I guess it was  interpreting them as spoofed. The sh ipv6 int outside only shows the link-local address, even with autoconfiguration enabled.

In  passing, there isn't really any IPv6 NAT, barring the  still-experimental RFC-6296 prefix substitution.  And site-local  fec0::/10 addresses were deprecated in RFC3879 back in 2004, to the  point that newly conforming routers aren't allowed to even configure  them as interface addresses, much less forward packets sourced from  them.  So you probably need a different IPv6 routing strategy for the  inside vlan.  E.g., have your ISP delegate to you a /48 or a /60 or  something and put different /64 subnets on the inside and outside  interfaces, with an explicit ipv6 default route, e.g
  . ipv6 route outside ::/0 fe80::201:5cff:fe3b:3c41
I don't think there is any IPv6 equivalent of setroute from "ip address dhcp setroute".

Interesting and good information! So at the point that I was unable to use autoconfiguration but was able to connect to their link-local address (pongs from my ping), I loaded up the new, shiny 9.0(1) release which supports DHCPv6 relaying and gave it a whirl. I specified the gateway address as the DHCPv6 relay server but no luck. Via some debugging, I saw requests from internal clients on the internal going out but no responses. I assumed that this would work find over the ASA's link-local address as that is what a traditional client that does support DHCPv6 would communicate over but no dice.

Your icmp6 commands puzzle me a little.  ipv6 icmp permit any outside is the default interface behavior, and makes all the preceding permits moot.  Maybe you are planning to replace it with a deny at some future point?  Not filtering ICMPv6 at routed interfaces is  less dangerous than in the v4 case, as most of the interesting stuff has  restrictions to the on-link VLAN like requiring hop limit=255 or  link-local source addresses.

My understanding was also that ICMPv6 stuff should work fine without the statements, but after failed autoconfiguration and DHCPv6 relay attempts I was trying to get a little creative, or disparate. I reached out to Comcast's Business and put in a TAC ticket. Although this was for a residential setup, Comcast support (at least the three representatives I spoke with) did not know what IPv6 was and wanted to charge me for premium support (you can imagine my reluctance). I reached out to their business side and they were more interested in helping. Not having an account limited my support but in short, they did not at this time support static /64 allocations, at least that's what I was told. It might of been worth upgrading to a business account if they did but instead I am going to purchase a router which will support DHCPv6...

[WSLH OIS NOC - OIS Infrastructure]

I did try enabling autoconfiguration but learned that Comcast uses DHCP to distribute their residential customers /64 allocations... The sh ipv6 int outside only shows the link-local address, even with autoconfiguration enabled.

Interesting.  The long-range speculation is that residential IPv6 will use DHCPv6 for prefix delegation of /60's, which the local router or firewall will then parcel out into /64's for DMZ, gaming, regular clients, or whatever.  However, in the interoperability tests at U. of New Hampshire's lab last spring, this was the scenario most likely to be gotten wrong (only 1 device passed), so its not surprising that Comcast is sending /64s instead.  The lack of an autoconfigured address suggests that the Comcast router advertisements have the managed flag on, in keeping with the insistence on DHCPv6.

... their DHCP server [ff02::1:2]. I learned this after throwing a tap on the connection and obtaining an global IP with a host that could leverage DHCPv6 verse the ASA which cannot. I also tried pinging ff02::1:2  and the response would come from the aforementioned gateway link-local address but the ASA would block these responses since I guess it was  interpreting them as spoofed. 

ff02::1:2 is the IANA registered "all DHCPv6 relays" group address, just like ff02::1 is all-hosts and ff02::2 is all-routers.  I'll have to experiment to see if I can replicate the ping issues, which I don't understand either.

... I loaded up the new, shiny 9.0(1) release which supports DHCPv6 relaying and gave it a whirl. I specified the gateway address as the DHCPv6 relay server but no luck. Via some debugging, I saw requests from internal clients on the internal going out but no responses. I assumed that this would work find over the ASA's link-local address as that is what a traditional client that does support DHCPv6 would communicate over but no dice.

What I would expect to work in the comcast scenario for IPv6 is if the Cisco firewall is in transparent mode, so that the client ICMPv6 router solicitations get the upstream router advertisements which flag for doing DHCPv6, the DHCPv6 requests with the client link-local fe80::/64 address just pass through the Cisco to the Comcast modem on group ff02::1:2, and a unicast DHCPv6 response comes back from Comcast and passes throught the Cisco back to the ultimate client.   With a /64, I'm naively assuming Comcast would register multiple IPv6 devices via DHCPv6, though that might not be the case.  The problem with this ploy is that it messes up IPv4, as only one of the downstream devices could get an IPv4 address from Comcast.  Unless the Comcast cable modem could be configured to do both DHCPv6 and v4 DHCP locally, in which case running the Cisco in transparent mode would be fine.

In routed mode, with NAT on for v4, I don't think you can make v6 work with only a single /64.   One ploy might be using multiple security contexts, doing all the v6 with the transparent context and all the v4 with the routed context, but the 5505's don't support that, either.  I'm not sure the vlan structure for that would work for non-trunked clients, anyway.

For test purposes, a single PC running either windows 7 or Linux would probably do both IPv4 and IPv6 with Comcast if plugged directly into the cable modem, but that would exclude your Cisco 5505 and any downstream wifi router, which is not a happy place on the v4 side of things.

Switching to a v6-certified (wifi?) router/firewall as a replacement for the Cisco 5505 would probably work, yes.

Good luck with it,

-- Jim Leinweber, State Lab of Hygiene, UW-Madison

[Vindemiatrix]

Jim, thanks again for the thougtful reply.

Interesting.  The long-range speculation is that residential IPv6 will  use DHCPv6 for prefix delegation of /60's, which the local router or  firewall will then parcel out into /64's for DMZ, gaming, regular  clients, or whatever.  However, in the interoperability tests at U. of  New Hampshire's lab last spring, this was the scenario most likely to be  gotten wrong (only 1 device passed), so its not surprising that Comcast  is sending /64s instead.  The lack of an autoconfigured address  suggests that the Comcast router advertisements have the managed flag  on, in keeping with the insistence on DHCPv6.

Note, I may of been mistaken about regarding the allocation size.

Switching to a v6-certified (wifi?) router/firewall as a replacement for the Cisco 5505 would probably work, yes.

Yep, have my eye on a 3825 or maybe a 2900 series router! Thanks again.