View previous topic :: View next topic |
Author |
Message |
NP_complete Tux's lil' helper
Joined: 21 Mar 2009 Posts: 110
|
Posted: Wed Nov 05, 2014 6:37 pm Post subject: [SOLVED] Firewall kills IPv6 traffic |
|
|
On my laptop, I get
Quote: | $ ping6 google.com
connect: Network is unreachable |
Disabling the IPv6 side of the firewall makes the problem go away. I use the following rules (see below) which are identical (with obvious corrections) to IPv4. Bizarrely, they work for IPv4 but not for IPv6. I can't wrap my brain around this.
Quote: | # ip6tables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all ::/0 ::/0 ctstate RELATED,ESTABLISHED
ACCEPT all ::/0 ::/0
DROP all ::/0 ::/0 ctstate INVALID
ACCEPT icmpv6 ::/0 ::/0 ipv6-icmptype 8 ctstate NEW
UDP udp ::/0 ::/0 ctstate NEW
TCP tcp ::/0 ::/0 tcp flags:0x17/0x02 ctstate NEW
REJECT udp ::/0 ::/0 reject-with icmp6-port-unreachable
REJECT tcp ::/0 ::/0 reject-with tcp-reset
REJECT all ::/0 ::/0 reject-with icmp6-port-unreachable
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain TCP (1 references)
target prot opt source destination
Chain UDP (1 references)
target prot opt source destination
|
The above rules were generated by
Code: | *filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp6-port-unreachable
COMMIT
|
Many thanks.
Last edited by NP_complete on Thu Nov 06, 2014 2:09 pm; edited 2 times in total |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Wed Nov 05, 2014 7:46 pm Post subject: |
|
|
Your default policy for FORWARD is DROP and you have no other rules in there, so no traffic is allowed to be routed.
EDIT: NVM did not realize this are the rules on the notebook |
|
Back to top |
|
|
NP_complete Tux's lil' helper
Joined: 21 Mar 2009 Posts: 110
|
Posted: Thu Nov 06, 2014 2:55 am Post subject: |
|
|
Solved it! IPv6 differs from IPv4 in the way it uses ICMP. In my particular case, allowing all incoming ICMPv6 traffic took care of things:
Code: | -A INPUT -p icmpv6 -j ACCEPT |
|
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
|
Back to top |
|
|
NP_complete Tux's lil' helper
Joined: 21 Mar 2009 Posts: 110
|
Posted: Thu Nov 06, 2014 2:07 pm Post subject: |
|
|
charles17,
I've seen the code you linked to. But it doesn't work, as far as IPv6 goes, and IPv4 works fine. Go figure...
Quote: | $ ip6tables -L -nv
Chain INPUT (policy DROP 223 packets, 16200 bytes)
pkts bytes target prot opt in out source destination
326 45279 ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all lo * ::/0 ::/0
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 3
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 11
0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmptype 12
0 0 REJECT tcp * * ::/0 ::/0 tcp dpt:113 flags:0x17/0x02 reject-with tcp-reset
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 602 packets, 66414 bytes)
pkts bytes target prot opt in out source destination
|
Quote: | $ ip6tables-save
# Generated by ip6tables-save v1.4.21 on Thu Nov 6 08:58:47 2014
*mangle
:PREROUTING ACCEPT [2604:1736259]
:INPUT ACCEPT [2604:1736259]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2303:395377]
:POSTROUTING ACCEPT [2303:395377]
COMMIT
# Completed on Thu Nov 6 08:58:47 2014
# Generated by ip6tables-save v1.4.21 on Thu Nov 6 08:58:47 2014
*filter
:INPUT DROP [227:16524]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [602:66414]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 11 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 12 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 113 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset
COMMIT
# Completed on Thu Nov 6 08:58:47 2014
|
|
|
Back to top |
|
|
skaloo n00b
Joined: 18 Jul 2014 Posts: 21
|
Posted: Sat Nov 22, 2014 9:44 am Post subject: |
|
|
IPv6 auto-configuration uses ICMP, as you found out. This is the way your router/ISP and your host agree on an IPv6 address. No ICMP -> no routable address -> can't talk to the world.
It's done using 'link-local' addresses, so you may restrict the allowed packets to the FE80::/10 network, if you want to be restrictive with the PINGs your host replies to.
Code: | ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT |
If your linux also does routing, you need also that one:
Code: | ip6tables -A FORWARD -s fe80::/10 -p ipv6-icmp -j ACCEPT |
|
|
Back to top |
|
|
NP_complete Tux's lil' helper
Joined: 21 Mar 2009 Posts: 110
|
Posted: Sat Nov 22, 2014 10:04 pm Post subject: |
|
|
skaloo, thanks! I used the first rule only, of the two you suggested (because I don't do routing), and it worked! For posterity: Code: | *mangle
:PREROUTING ACCEPT [2521:1799758]
:INPUT ACCEPT [2521:1799758]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1982:462517]
:POSTROUTING ACCEPT [1982:462517]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [81:7085]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
COMMIT | PS Someone in charge should fix the IPv6 portion of https://wiki.gentoo.org/wiki/Iptables#Generating_firewall_rules_for_client |
|
Back to top |
|
|
charles17 Advocate
Joined: 02 Mar 2008 Posts: 3664
|
Posted: Sun Nov 23, 2014 7:52 am Post subject: |
|
|
When the policy is DROP why should one need "-j DROP" some lines further down? Quote: | Code:
*mangle
:PREROUTING ACCEPT [2521:1799758]
:INPUT ACCEPT [2521:1799758]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1982:462517]
:POSTROUTING ACCEPT [1982:462517]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [81:7085]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp6-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset |
Everybody posting here is also in charge of doing so. Feel free to improve Gentoo wiki. |
|
Back to top |
|
|
skaloo n00b
Joined: 18 Jul 2014 Posts: 21
|
Posted: Sun Nov 23, 2014 9:55 am Post subject: |
|
|
charles17 wrote: | When the policy is DROP why should one need "-j DROP" some lines further down? |
There are actualy a couple situations where people use this, most common being to drop ASAP some packets we really don't want the kernel to waste time on.
If the configuration has lots of complex/deep chains, dropping those 'INVALID' packets early on saves the kernel further processing.
On a purely conceptual point of view, though, you are right, the rule is not 'required'.
Another case would be to simplify/speed-up some complex situation, let's say we want to allow some packet family which contains (many) different sub-groups but explicilty drop *one* of these sub-groups. For instance we want to accept packets 'A', 'B', ..., 'Z' but specificaly not the 'D' packet. You'd have to write 25 accept rules. But you could also first write one rule that drops packets 'D', then one rule that accepts family 'alphabet', and you're done with only 2 rules. It's easier to configure/maintain and it's also faster to process in kernel, and it's even less memory used to store the rules. |
|
Back to top |
|
|
|