Bug 1575431

Summary:	IPv6 Neighbor Solicitation fails.
Product:	[Fedora] Fedora	Reporter:	Jan Hugo Prins <jprins>
Component:	firewalld	Assignee:	Eric Garver <egarver>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	28	CC:	alexl, anthony, bgalvani, dcbw, egarver, fgiudici, john.j5live, jpopelka, jprins, lkundrak, mail, mclasen, norbert.jurkeit, pbrobinson, rhughes, rstrode, sandmann, shigorin, twoerner, vstinner, yk+bug+rh, zaitcev
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	firewalld-0.5.3-2.fc28	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-06 16:44:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Hugo Prins 2018-05-06 22:17:22 UTC

Description of problem:

After upgrading my system from Fedora 27 to Fedora 28 I have a lot of problems with my IPv6 network connectivity. My routers, both at home and at the office, do a neighborhood Solicitation and my system simply doesn't answer. 

23:43:10.232995 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > capetown.lan.betterbe.com: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 00:25:90:6c:f3:86
23:43:10.233077 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) capetown.lan.betterbe.com > _gateway: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is capetown.lan.betterbe.com, Flags [solicited]
23:43:10.279997 IP6 (flowlabel 0xb79e9, hlim 255, next-header ICMPv6 (58) payload length: 64) capetown.lan.betterbe.com > ping.xs4all.nl: [icmp6 sum ok] ICMP6, echo request, seq 271
23:43:10.293983 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 00:25:90:6c:f3:86
23:43:11.304056 IP6 (flowlabel 0xb79e9, hlim 255, next-header ICMPv6 (58) payload length: 64) capetown.lan.betterbe.com > ping.xs4all.nl: [icmp6 sum ok] ICMP6, echo request, seq 272
23:43:11.307554 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 00:25:90:6c:f3:86
23:43:12.328037 IP6 (flowlabel 0xb79e9, hlim 255, next-header ICMPv6 (58) payload length: 64) capetown.lan.betterbe.com > ping.xs4all.nl: [icmp6 sum ok] ICMP6, echo request, seq 273


Version-Release number of selected component (if applicable):

NetworkManager-wifi-1.10.6-2.fc28.x86_64

How reproducible:

I have really no idea. I just upgraded and now I have a lot of problems. Have not yet tested a fresh install.

Steps to Reproduce:
1.
2.
3.

Actual results:

I can't connect outbound on IPv6 and after a little while the network icon in the top right of my Gnome desktop changes into a questionmark.

When I make sure I have a mtr open from my workstation to the outside world everything keeps working because my router doesn't have to do Neighborhood Sollicitations.

Expected results:

Full network connectivity.

Additional info:

net.ipv6.conf.wlp2s0.accept_dad = 1
net.ipv6.conf.wlp2s0.accept_ra = 1
net.ipv6.conf.wlp2s0.accept_ra_defrtr = 0
net.ipv6.conf.wlp2s0.accept_ra_from_local = 0
net.ipv6.conf.wlp2s0.accept_ra_min_hop_limit = 1
net.ipv6.conf.wlp2s0.accept_ra_mtu = 1
net.ipv6.conf.wlp2s0.accept_ra_pinfo = 0
net.ipv6.conf.wlp2s0.accept_ra_rt_info_max_plen = 32
net.ipv6.conf.wlp2s0.accept_ra_rt_info_min_plen = 0
net.ipv6.conf.wlp2s0.accept_ra_rtr_pref = 0
net.ipv6.conf.wlp2s0.accept_redirects = 1
net.ipv6.conf.wlp2s0.accept_source_route = 0
net.ipv6.conf.wlp2s0.addr_gen_mode = 1
net.ipv6.conf.wlp2s0.autoconf = 1
net.ipv6.conf.wlp2s0.dad_transmits = 1
net.ipv6.conf.wlp2s0.disable_ipv6 = 0
net.ipv6.conf.wlp2s0.disable_policy = 0
net.ipv6.conf.wlp2s0.drop_unicast_in_l2_multicast = 0
net.ipv6.conf.wlp2s0.drop_unsolicited_na = 0
net.ipv6.conf.wlp2s0.enhanced_dad = 1
net.ipv6.conf.wlp2s0.force_mld_version = 0
net.ipv6.conf.wlp2s0.force_tllao = 0
net.ipv6.conf.wlp2s0.forwarding = 0
net.ipv6.conf.wlp2s0.hop_limit = 255
net.ipv6.conf.wlp2s0.ignore_routes_with_linkdown = 0
net.ipv6.conf.wlp2s0.keep_addr_on_down = 0
net.ipv6.conf.wlp2s0.max_addresses = 16
net.ipv6.conf.wlp2s0.max_desync_factor = 600
net.ipv6.conf.wlp2s0.mc_forwarding = 0
net.ipv6.conf.wlp2s0.mldv1_unsolicited_report_interval = 10000
net.ipv6.conf.wlp2s0.mldv2_unsolicited_report_interval = 1000
net.ipv6.conf.wlp2s0.mtu = 1492
net.ipv6.conf.wlp2s0.ndisc_notify = 0
net.ipv6.conf.wlp2s0.ndisc_tclass = 0
net.ipv6.conf.wlp2s0.optimistic_dad = 0
net.ipv6.conf.wlp2s0.proxy_ndp = 0
net.ipv6.conf.wlp2s0.regen_max_retry = 3
net.ipv6.conf.wlp2s0.router_probe_interval = 60
net.ipv6.conf.wlp2s0.router_solicitation_delay = 1
net.ipv6.conf.wlp2s0.router_solicitation_interval = 4
net.ipv6.conf.wlp2s0.router_solicitation_max_interval = 3600
net.ipv6.conf.wlp2s0.router_solicitations = -1
net.ipv6.conf.wlp2s0.seg6_enabled = 0
net.ipv6.conf.wlp2s0.seg6_require_hmac = 0
net.ipv6.conf.wlp2s0.suppress_frag_ndisc = 1
net.ipv6.conf.wlp2s0.temp_prefered_lft = 86400
net.ipv6.conf.wlp2s0.temp_valid_lft = 604800
net.ipv6.conf.wlp2s0.use_oif_addrs_only = 0
net.ipv6.conf.wlp2s0.use_optimistic = 0
net.ipv6.conf.wlp2s0.use_tempaddr = 0
net.ipv6.neigh.wlp2s0.anycast_delay = 100
net.ipv6.neigh.wlp2s0.app_solicit = 0
net.ipv6.neigh.wlp2s0.base_reachable_time_ms = 30000
net.ipv6.neigh.wlp2s0.delay_first_probe_time = 5
net.ipv6.neigh.wlp2s0.gc_stale_time = 60
net.ipv6.neigh.wlp2s0.locktime = 0
net.ipv6.neigh.wlp2s0.mcast_resolicit = 0
net.ipv6.neigh.wlp2s0.mcast_solicit = 3
net.ipv6.neigh.wlp2s0.proxy_delay = 80
net.ipv6.neigh.wlp2s0.proxy_qlen = 64
net.ipv6.neigh.wlp2s0.retrans_time_ms = 1000
net.ipv6.neigh.wlp2s0.ucast_solicit = 3
net.ipv6.neigh.wlp2s0.unres_qlen = 101
net.ipv6.neigh.wlp2s0.unres_qlen_bytes = 212992

Systeminfo:

https://paste.fedoraproject.org/paste/D06p656PXlk0E7dxouvlBg

Comment 1 Jan Hugo Prins 2018-05-06 22:46:54 UTC

On my home network:

00:44:36.891136 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:37.881270 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:38.881509 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:40.952331 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:42.892108 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:44.958512 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:45.969903 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:46.993884 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:51.094309 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:52.114081 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:44:53.138773 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:45:09.829049 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:45:17.704142 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) capetown.lan.betterbe.com > _gateway: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has _gateway
	  source link-address option (1), length 8 (1): 9c:b6:d0:df:62:8b
00:45:17.709403 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) _gateway > capetown.lan.betterbe.com: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is _gateway, Flags [router, solicited]
00:45:36.150979 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:45:37.177994 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e
00:45:38.207561 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) _gateway > ff02::1:ffdf:628b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has capetown.lan.betterbe.com
	  source link-address option (1), length 8 (1): 34:31:c4:8a:cf:0e


[root@capetown ~]# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:980:ad8f:1:9eb6:d0ff:fedf:628b/64 scope global dynamic noprefixroute 
       valid_lft 6494sec preferred_lft 3144sec
    inet6 fe80::9eb6:d0ff:fedf:628b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: vmnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:2/64 scope link 
       valid_lft forever preferred_lft forever
4: vmnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:3/64 scope link 
       valid_lft forever preferred_lft forever
5: vmnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:4/64 scope link 
       valid_lft forever preferred_lft forever
6: vmnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:5/64 scope link 
       valid_lft forever preferred_lft forever
7: vmnet6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:6/64 scope link 
       valid_lft forever preferred_lft forever
8: vmnet7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:7/64 scope link 
       valid_lft forever preferred_lft forever
9: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::250:56ff:fec0:8/64 scope link 
       valid_lft forever preferred_lft forever
[root@capetown ~]# ip -6 ro
2001:980:ad8f:1::/64 dev wlp2s0 proto ra metric 600 pref medium
2001:980:ad8f::/48 via fe80::3631:c4ff:fe8a:cf0e dev wlp2s0 proto ra metric 600 pref medium
fe80::/64 dev vmnet2 proto kernel metric 256 pref medium
fe80::/64 dev vmnet3 proto kernel metric 256 pref medium
fe80::/64 dev vmnet4 proto kernel metric 256 pref medium
fe80::/64 dev vmnet5 proto kernel metric 256 pref medium
fe80::/64 dev vmnet6 proto kernel metric 256 pref medium
fe80::/64 dev vmnet7 proto kernel metric 256 pref medium
fe80::/64 dev vmnet8 proto kernel metric 256 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 256 pref medium
fe80::/64 dev wlp2s0 proto kernel metric 600 pref medium
default via fe80::3631:c4ff:fe8a:cf0e dev wlp2s0 proto ra metric 20600 pref medium
[root@capetown ~]#

Comment 2 Jan Hugo Prins 2018-05-06 22:50:32 UTC

During tests I flushed all firewall rules to make sure the firewall was not interfering with the bug hunting.

[root@capetown ~]# ip6tables --list -v -n
Chain INPUT (policy ACCEPT 15488 packets, 4734K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 22638 packets, 2097K bytes)
 pkts bytes target     prot opt in     out     source               destination

Comment 3 Jan Hugo Prins 2018-05-07 14:11:51 UTC

It looks like the issue is only happening on my wireless interface as far as I can see now. In the office I have a fixed connection (Cat5e, 802.1x) and this connection doesn't give me any issues so far.

Comment 4 Jan Hugo Prins 2018-05-08 12:45:08 UTC

Yesterday evening I received a lot of updates. In this updates I had:

NetworkManager.x86_64 1:1.10.6-3.fc28                                               
NetworkManager-adsl.x86_64 1:1.10.6-3.fc28                             NetworkManager-bluetooth.x86_64 1:1.10.6-3.fc28                                     
NetworkManager-config-connectivity-fedora.noarch 1:1.10.6-3.fc28       NetworkManager-glib.x86_64 1:1.10.6-3.fc28                                          
NetworkManager-libnm.x86_64 1:1.10.6-3.fc28                            NetworkManager-ppp.x86_64 1:1.10.6-3.fc28                                           
NetworkManager-team.x86_64 1:1.10.6-3.fc28                             NetworkManager-wifi.x86_64 1:1.10.6-3.fc28                                          
NetworkManager-wwan.x86_64 1:1.10.6-3.fc28

kernel.x86_64 4.16.7-300.fc28                     
kernel-core.x86_64 4.16.7-300.fc28                      
kernel-devel.x86_64 4.16.7-300.fc28              
kernel-modules.x86_64 4.16.7-300.fc28             
kernel-modules-extra.x86_64 4.16.7-300.fc28

It looks like this update set fixed the problem for my Wifi connections, for my OpenVPN connections I still have the same problem.

Comment 5 Jan Hugo Prins 2018-05-08 18:38:08 UTC

> 
> It looks like this update set fixed the problem for my Wifi connections, for
> my OpenVPN connections I still have the same problem.

Scrap this. The updates didn't fix the issue.

Comment 6 Yves Kondoszek 2018-05-18 16:15:18 UTC

I started having the same neighbouring issues after an kernel update to 4.16 on a CentOS Docker host. Downgrading to 4.15.3-1.el7.elrepo.x86_64 fixed the issue.
Seems like we are not the only ones: https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
My money is on the kernel.

Comment 7 Yves Kondoszek 2018-05-19 12:23:32 UTC

So I can confirm that it's the IPv6 rp_filter from firewalld that is blocking the answers to the IPv6 neighbour solicitations; setting IPv6_rpfilter=no in /etc/firewalld/firewalld.conf on latest kernel (4.16.9-1.el7.elrepo.x86_64) solves the issue.

Comment 8 Jan Hugo Prins 2018-05-20 15:04:09 UTC

I just tested this on my OpenVPN and my wireless connections and it indeed seems to fix the issue. Makes me wonder what is going wrong here. rpfilter should not filter these packets.

Comment 9 Beniamino Galvani 2018-05-21 07:18:08 UTC

I'm reassigning this bug to firewalld for investigation.

In the meantime, can you please enable again IPv6 rp_filter, reproduce the problem and paste the output of:

  ip6tables -v -t raw -L

?

Comment 10 Jan Hugo Prins 2018-05-21 11:09:38 UTC

[root@capetown firewalld]# ip6tables --list -v -t raw
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere             ipv6-icmp router-advertisement
    0     0 DROP       all      any    any     anywhere             anywhere             rpfilter invert
    0     0 PREROUTING_direct  all      any    any     anywhere             anywhere            
    0     0 PREROUTING_ZONES_SOURCE  all      any    any     anywhere             anywhere            
    0     0 PREROUTING_ZONES  all      any    any     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 OUTPUT_direct  all      any    any     anywhere             anywhere            

Chain OUTPUT_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PREROUTING_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 PRE_FedoraWorkstation  all      wlp2s0 any     anywhere             anywhere            [goto] 
    0     0 PRE_FedoraWorkstation  all      +      any     anywhere             anywhere            [goto] 

Chain PREROUTING_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PREROUTING_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PRE_FedoraWorkstation (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 PRE_FedoraWorkstation_log  all      any    any     anywhere             anywhere            
    0     0 PRE_FedoraWorkstation_deny  all      any    any     anywhere             anywhere            
    0     0 PRE_FedoraWorkstation_allow  all      any    any     anywhere             anywhere            

Chain PRE_FedoraWorkstation_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PRE_FedoraWorkstation_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PRE_FedoraWorkstation_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

Comment 11 Jan Hugo Prins 2018-05-21 11:14:57 UTC

There is an RFC that specifies what ICMPv6 you should allow in your firewalls to have IPv6 work correctly. 

https://tools.ietf.org/html/rfc4890

Based on this RFC I always put the following lines in my firewall scripts on my servers etc:

ip6tables -N ICMPv6
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 133/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 134/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 135/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 136/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 137/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 141/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 142/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 128/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 3/0 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 4/1 -j ACCEPT
ip6tables -A ICMPv6 -p ipv6-icmp -m icmp6 --icmpv6-type 4/2 -j ACCEPT

I notice in the firewall rules that there is a general allow all rule for ICMPv6 and in the beginning of the raw tables something to drop very specific things. Maybe it is a good idea to redesign this a little.

Comment 12 Victor Stinner 2018-06-05 16:23:46 UTC

I had IPv6 issues with my Livebox (DSL box, my router) on my Fedora 28 laptop which uses wifi. I enabled logs in firewall-config: rp_filter dropped ICMPv6 type 135. ip
-6 neigh shows me STALE on livebox public IPv6. Setting IPv6_rpfilter=no in /etc/firewalld/firewalld.conf fixed my issue!

I'm using uncommon network interfaces: tun0 for corporate VPN, docker0 for Docker, and another one for virtual machines. Maybe the kernel rp_filter is confused by them? Or the issue comes from DST=ff02::1 of dropped ICMPv6 type 135 (Neighbor Solicitation)?

My laptop worked well on Fedora 27.

When I used a ping to my Livebox using the local link IPv6 (fe80), the Livebox replied and it didn't change anything. But when I used a ping to my Livebox using its public IPv6 (2a01:...), it unblocked all applications which were stuck on establishing IPv6 connections. It seems like the firewall denies input (neighbor solicitation) packets, but allows outcoming ICMPv6 pings and the ping repairs/wakes up the link.

Comment 13 Victor Stinner 2018-06-05 16:26:26 UTC

Example of a log of a blocked incoming packet:

kernel: rpfilter_DROP:
   IN=wlp4s0 OUT= MAC=33:33:00:00:00:01:b0:b2:8f:9b:a9:f0:86:dd 
   SRC=fe80:0000:0000:0000:b2b2:8fff:fe9b:a9f0 
   DST=ff02:0000:0000:0000:0000:0000:0000:0001 
   LEN=72 TC=192 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0

Log comes "journalctl -k -f", I enabled log on DROP in firewall-config.

Comment 14 Victor Stinner 2018-06-05 16:35:17 UTC

I don't understand why incoming IPv6 packages are filtered:

$ sudo ip6tables -v -t raw -L
Chain PREROUTING (policy ACCEPT 52 packets, 18211 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   432 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere             ipv6-icmp router-advertisement
   13  1000 LOG        all      any    any     anywhere             anywhere             rpfilter invert LOG level warning prefix "rpfilter_DROP: "
   13  1000 DROP       all      any    any     anywhere             anywhere             rpfilter invert
   52 18211 PREROUTING_direct  all      any    any     anywhere             anywhere            
   52 18211 PREROUTING_ZONES_SOURCE  all      any    any     anywhere             anywhere            
   52 18211 PREROUTING_ZONES  all      any    any     anywhere             anywhere

(...)

13 packets have been dropped, example of logs:

rpfilter_DROP: IN=wlp4s0 OUT= MAC=33:33:00:00:00:01:b0:b2:8f:9b:a9:f0:86:dd SRC=fe80:0000:0000:0000:b2b2:8fff:fe9b:a9f0 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=72 TC=192 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0 

The first rule explicitely allows incoming "ipv6-icmp router-advertisement" from anywhere, but my issue comes from ICMPv6 type 135.

The workaround for me is to allow explicitly incoming ICMPv6 type 135 in the PREROUTING chain of the raw table:

$ sudo ip6tables -t raw -I PREROUTING 2 -p icmpv6 --icmpv6-type=135 -j ACCEPT

Comment 15 Yves Kondoszek 2018-06-05 17:21:08 UTC

I forgot to mention that I also have a docker0 interface for Docker, and a tunnel interface for OpenVPN (in container).
Pinging the host's public IP also wakes the link up for 36 seconds before it goes mute again.

Comment 16 Pete Zaitcev 2018-06-15 21:50:55 UTC

(In reply to Victor Stinner from comment #12)
> Setting IPv6_rpfilter=no in
> /etc/firewalld/firewalld.conf fixed my issue!

I think we might want to change the component for this bug from firewalld
to kernel. The erroneous check is implemented in the kernel, right?
The firewalld just enables or disables the feature. The bug is not
in firewalld, then.

Commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 may be the fix
(judging by the changelog -- I don't understand how it works).

Comment 17 Pete Zaitcev 2018-06-15 21:51:57 UTC

*** Bug 1591867 has been marked as a duplicate of this bug. ***

Comment 18 Victor Stinner 2018-06-15 22:14:32 UTC

"I think we might want to change the component for this bug from firewalld to kernel. The erroneous check is implemented in the kernel, right?"

The bug comes from the PREROUTING table which should allow ICMPv6 type 135: see my comment 14. I can fix the issue by adding a new ACCEPT rule using ip6tables, without touching to the kernel.

Comment 19 Jan Hugo Prins 2018-06-15 23:26:16 UTC

I think the best solution is to follow the RFC which explains exactly what ICMPv6 messages should be allowed.

Comment 20 Jan Hugo Prins 2018-06-15 23:27:01 UTC

I think the best solution is to follow the RFC which explains exactly what ICMPv6 messages should be allowed.

Comment 21 Eric Garver 2018-06-16 07:34:24 UTC

(In reply to Pete Zaitcev from comment #16)
> (In reply to Victor Stinner from comment #12)
> > Setting IPv6_rpfilter=no in
> > /etc/firewalld/firewalld.conf fixed my issue!
> 
> I think we might want to change the component for this bug from firewalld
> to kernel. The erroneous check is implemented in the kernel, right?
> The firewalld just enables or disables the feature. The bug is not
> in firewalld, then.
> 
> Commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 may be the fix
> (judging by the changelog -- I don't understand how it works).

Thanks for the pointer - that seems likely. I'll try to verify.

47b7e7f82802 is in 4.16, but the fix (cede24d1b21d) is sitting in net-next. I'm not sure why it went to net-next instead of net for fixes.

Comment 22 Pete Zaitcev 2018-06-25 01:48:14 UTC

I didn't check the source, but the kernel-4.17.2-200.fc28.x86_64 solves
the issue for me.

Comment 23 Victor Stinner 2018-06-28 10:10:28 UTC

> I didn't check the source, but the kernel-4.17.2-200.fc28.x86_64 solves the issue for me.

On Fedora 28 with 4.17.2-200.fc28.x86_64, I still have the bug.

Comment 24 Frank Ansari 2018-06-28 18:36:26 UTC

I also ran recently into IPv6 issues. Suddenly IPv6 is not reachable anymore without any changes done. When I stop firewalld it works.

A very simple test is pinging www.google.de.

I noticed that when I start firewalld the ping works and then suddenly blocks.

I did a whireshark trace and found that the ping is still sent out but does not receive any replies.

[fansari@bat trace]$ ping www.google.de
PING www.google.de(ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003)) 56 data bytes
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=1 ttl=56 time=27.1 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=2 ttl=56 time=22.4 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=3 ttl=56 time=22.3 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=4 ttl=56 time=23.1 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=5 ttl=56 time=22.5 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=6 ttl=56 time=22.6 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=7 ttl=56 time=23.4 ms
64 bytes from ams17s01-in-x03.1e100.net (2a00:1450:400e:80b::2003): icmp_seq=8 ttl=56 time=22.4 ms
^C
--- www.google.de ping statistics ---
11 packets transmitted, 8 received, 27% packet loss, time 10065ms
rtt min/avg/max/mdev = 22.385/23.266/27.119/1.495 ms


Since icmpv6 is not blocked anywhere in my firewall settings this was a complete riddle to me.

Today I found that when I disable IVP6_rpfilter

IPv6_rpfilter=no

the ping is running even if firewalld is started.

This is strange. As far as I understood the documentation this setting is for preventing packages to flow into a wrong direction. But in this simple case packages go out to the default gw and replies arrive there.

Comment 25 Frank Ansari 2018-06-28 18:48:53 UTC

I can also confirm that this only happens when using Wifi. Using Ethernet I could not reproduce this issue.

Comment 26 Eric Garver 2018-07-02 21:18:30 UTC

(In reply to Eric Garver from comment #21)
> (In reply to Pete Zaitcev from comment #16)
> > (In reply to Victor Stinner from comment #12)
> > > Setting IPv6_rpfilter=no in
> > > /etc/firewalld/firewalld.conf fixed my issue!
> > 
> > I think we might want to change the component for this bug from firewalld
> > to kernel. The erroneous check is implemented in the kernel, right?
> > The firewalld just enables or disables the feature. The bug is not
> > in firewalld, then.
> > 
> > Commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 may be the fix
> > (judging by the changelog -- I don't understand how it works).
> 
> Thanks for the pointer - that seems likely. I'll try to verify.
> 
> 47b7e7f82802 is in 4.16, but the fix (cede24d1b21d) is sitting in net-next.
> I'm not sure why it went to net-next instead of net for fixes.

I have verified 47b7e7f82802 as the cause and cede24d1b21d the fix. It fails on kernel 4.16.16-300.fc28, but works as expected on 4.18.0-rc2+. So it's broken on 4.16.x and 4.17.x kernels.

firewalld can probably workaround these broken kernels versions by explicitly allowing Neighbour Solicitation as it does for Router Solicitation. I'll leave this BZ open for that effort.

Thanks for all the information everyone.

Comment 27 Victor Stinner 2018-07-03 07:03:21 UTC

Would it be possible to backport the fix to 4.17? Or is Fedora 28 going to upgraded to 4.18 once 4.18 will be released? In the meanwhile, this bug is a major pain: Firefox blocks randomly, and I have to run mtr or ping explicitly the public IPv6 of my router to unblock Firefox. Or I should add an ip6table rule, like:

sudo ip6tables -t raw -I PREROUTING 2 -p icmpv6 --icmpv6-type=135 -j ACCEPT

Comment 28 Peter Robinson 2018-07-03 08:12:15 UTC

(In reply to Victor Stinner from comment #27)
> Would it be possible to backport the fix to 4.17? Or is Fedora 28 going to
> upgraded to 4.18 once 4.18 will be released? In the meanwhile, this bug is a

Yes F-28 will get 4.18 but it's a good 6 weeks out.

Can you try this scratch build (note it won't be signed if you have secure boot it won't work):
https://koji.fedoraproject.org/koji/taskinfo?taskID=27997924

Comment 29 Eric Garver 2018-07-03 19:27:28 UTC

I just pushed a workaround upstream.

  3d6a50635663 ("IPv6 rpfilter: explicitly allow neighbor solicitation")

Comment 30 Fedora Update System 2018-07-03 20:56:27 UTC

firewalld-0.5.3-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca9b42c690

Comment 31 Fedora Update System 2018-07-04 18:21:51 UTC

firewalld-0.5.3-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca9b42c690

Comment 32 Fedora Update System 2018-07-06 16:44:17 UTC

firewalld-0.5.3-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 33 Eric Garver 2018-08-10 14:50:37 UTC

*** Bug 1574297 has been marked as a duplicate of this bug. ***