On 06/05/2018 07:11 AM, Brian J. Murrell wrote: > On Mon, 2018-03-26 at 19:18 -0400, Brian J. Murrell wrote: >> I have this strange problem where ICMP6 router advertisement >> responses >> are not making out to their requester. > > I have narrowed this down to packet connmarking in the mangle table. > First, my mangle table: > > Chain PREROUTING (policy ACCEPT 2728 packets, 790K bytes) > pkts bytes target prot opt in out source > destination > 17946 5909K CONNMARK all * * ::/0 ::/0 > CONNMARK restore mask 0xff00 > 39 8275 routemark all eth0.2 * ::/0 ::/0 > mark match 0x0/0xff00 > 526 64323 routemark all pppoe-wan1 * ::/0 ::/0 > mark match 0x0/0xff00 > 104 66594 routemark all 6in4-henet * ::/0 ::/0 > mark match 0x0/0xff00 > 744 72050 tcpre all * * ::/0 ::/0 > mark match 0x0/0xff00 > > Chain INPUT (policy ACCEPT 140 packets, 9904 bytes) > pkts bytes target prot opt in out source > destination > 1089 84576 tcin all * * ::/0 ::/0 > > > Chain FORWARD (policy ACCEPT 2033 packets, 740K bytes) > pkts bytes target prot opt in out source > destination > 15149 5967K MARK all * * ::/0 ::/0 > MARK and 0xffff00ff > 15149 5967K tcfor all * * ::/0 ::/0 > > > Chain OUTPUT (policy ACCEPT 39 packets, 2940 bytes) > pkts bytes target prot opt in out source > destination > 555 51816 CONNMARK all * * ::/0 ::/0 > CONNMARK restore mask 0xff00 > 18 2016 tcout all * * ::/0 ::/0 > mark match 0x0/0xff00 > > Chain POSTROUTING (policy ACCEPT 2071 packets, 743K bytes) > pkts bytes target prot opt in out source > destination > 15141 5846K tcpost all * * ::/0 ::/0 > > > Chain routemark (3 references) > pkts bytes target prot opt in out source > destination > 39 8275 MARK all eth0.2 * ::/0 ::/0 > MARK xset 0x100/0xff00 > 526 64323 MARK all pppoe-wan1 * ::/0 ::/0 > MARK xset 0x200/0xff00 > 104 66594 MARK all 6in4-henet * ::/0 ::/0 > MARK xset 0x300/0xff00 > 669 139K CONNMARK all * * ::/0 ::/0 > mark match ! 0x0/0xff00 CONNMARK save mask 0xff00 > > Chain tcfor (1 references) > pkts bytes target prot opt in out source > destination > 0 0 CONNMARK all * * ::/0 ::/0 > mark match ! 0x0/0xff CONNMARK save mask 0xff > > Chain tcin (1 references) > pkts bytes target prot opt in out source > destination > > Chain tcout (1 references) > pkts bytes target prot opt in out source > destination > > Chain tcpost (1 references) > pkts bytes target prot opt in out source > destination > > Chain tcpre (1 references) > pkts bytes target prot opt in out source > destination > 14 1120 ~excl0 tcp * * ::/0 ::/0 > tcp dpt:80 > 0 0 RETURN all * * ::/0 ::/0 > mark match ! 0x0/0x300 > > Chain ~excl0 (1 references) > pkts bytes target prot opt in out source > destination > 3 240 RETURN all * * [redacted]::/64 ::/0 > > 11 880 RETURN all * * [redacted]::/64 ::/0 > > 0 0 RETURN all * * [redacted]::/64 ::/0 > > 0 0 MARK all * * ::/0 ::/0 > MARK set 0x400 > > which is all pretty standard for multi-isp and some transparent > proxying. > > If I simply do: > > # ip6tables -t mangle -I OUTPUT -j RETURN > > on the router, router solicitations start working again. > > Does that help any or is this still looking like a/the kernel bug? >
In place of your ip6tables command, please try this one: ip6tables -t mangle -I OUTPUT -p icmpv6 --icmpv6-type 136 -j RETURN Does that also solve the issue? If so, what is the output of 'shorewall6 show routing'? -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users