ip6tables firewall problem
Shadow Hawkins on Monday, 25 August 2008 14:21:14
Hi. I'm running trying to set up a /48 subnet on my Linux machine (latest Debian running 2.6.25.6) and I'm having a slight problem with the https transactions. Clients on my subnet (called 2001:4830:xxx2::/48 in the rules below) seem to be able to do all other kinds of connections and can get to websites like kame.net but when I try to do an ipv6 https connection then it just hangs and never completes. Can someone tell me what I'm missing in my rules below? Let me know if there's a better way to represent this
Chain INPUT (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all lo * ::/0 ::/0
ACCEPT all * * fe80::/10 ::/0
ACCEPT all * * ff00::/8 ::/0
ACCEPT icmpv6 sixxs * ::/0 ::/0 limit: avg 4/sec burst 5
ACCEPT icmpv6 !sixxs * ::/0 ::/0
ACCEPT all internal * ::/0 ::/0
ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:53
ACCEPT udp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 udp dpt:53
ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:80
ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:25
DROP all * * ::/0 ::/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
target prot opt in out source destination
ACCEPT all * * fe80::/10 ::/0
ACCEPT all * * ff00::/8 ::/0
ACCEPT icmpv6 sixxs * ::/0 ::/0 limit: avg 10/sec burst 5
ACCEPT icmpv6 internal * ::/0 ::/0
DROP tcp sixxs * ::/0 ::/0 tcp dpts:0:1023
DROP udp sixxs * ::/0 ::/0 udp dpts:0:1023
DROP tcp sixxs * ::/0 ::/0 tcp flags:0x17/0x02
DROP udp sixxs * ::/0 ::/0 udp dpts:!32768:60999
ACCEPT tcp sixxs * ::/0 ::/0
ACCEPT udp sixxs * ::/0 ::/0
ACCEPT all !sixxs * 2001:4830:xxx2::/48 ::/0
DROP all * * ::/0 ::/0
Chain OUTPUT (policy ACCEPT 273 packets, 26475 bytes)
target prot opt in out source destination
ACCEPT all * * fe80::/10 ::/0
ACCEPT all * * ff00::/8 ::/0
ACCEPT icmpv6 * * ::/0 ::/0
ACCEPT all * sixxs 2001:4830:xxx2::/48 ::/0
ACCEPT all * sixxs 2001:4830:xxx1:xxxx::2/128 ::/0
ACCEPT all * internal ::/0 ::/0
ip6tables firewall problem
Jeroen Massar on Monday, 25 August 2008 20:31:37 ..INPUT... ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:53 ACCEPT udp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 udp dpt:53 ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:80 ACCEPT tcp sixxs * ::/0 2001:4830:xxx1:xxxx::2/128 tcp dpt:25
So you allow $anything to $you:{53|80|25} to work. Thus is that host a webserver?
Note that these INPUT rules apply locally on the host that terminate the traffic.
Chain FORWARD (policy DROP 0 packets, 0 bytes) [..]
DROP tcp sixxs * ::/0 ::/0 tcp dpts:0:1023 DROP udp sixxs * ::/0 ::/0 udp dpts:0:1023 DROP tcp sixxs * ::/0 ::/0 tcp flags:0x17/0x02 DROP udp sixxs * ::/0 ::/0 udp dpts:!32768:60999
You block out a LOT of combinations there which might just be valid, especially for DNS queries and other things.
ACCEPT tcp sixxs * ::/0 ::/0 ACCEPT udp sixxs * ::/0 ::/0
That allows almost everything, thus the rest is useless to be specified.
You might want to look at the ESTABLISHED rule, this works from 2.6.25 upwards or something, just like the IPv4 variant.
ip6tables firewall problem
Shadow Hawkins on Tuesday, 26 August 2008 12:03:07 So you allow $anything to $you:{53|80|25} to work. Thus is that host a webserver? Note that these INPUT rules apply locally on the host that terminate the traffic.
Anything to those ports on the routing host is allowed, yes. Blocking incoming connections on those ports to other hosts behind my router was the intended behavior
You block out a LOT of combinations there which might just be valid, especially for DNS queries and other things. That allows almost everything, thus the rest is useless to be specified. You might want to look at the ESTABLISHED rule, this works from 2.6.25 upwards or something, just like the IPv4 variant.
Actually I probably shouldn't have shown a copy of those rules since that was a work in progress while I was trying to get things to behave properly. I hadn't had any luck with getting the ESTABLISHED rule to behave properly. Do you know what the proper form of the ESTABLISHED rules should be? I was trying
$IP6TABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IP6TABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
in an earlier form
ip6tables firewall problem
Shadow Hawkins on Tuesday, 26 August 2008 15:55:14
You might want to run ip6tables with the -v option to see which rules are matched. E.g ip6tables -nvL
Another nice debugging option is replacing the DROP target with a log-n-drop table. I use this:
/sbin/ip6tables -N logdrop
/sbin/ip6tables -F logdrop
/sbin/ip6tables -A logdrop -j LOG --log-level info
/sbin/ip6tables -A logdrop -j DROP
This is then used instead of DROP, like
/sbin/ip6tables -A INPUT -j logdrop
You'll probably want to turn off the logging after finishing the debugging. This way, you'll only have to comment out a single line.
ip6tables firewall problem
Shadow Hawkins on Tuesday, 26 August 2008 16:53:25
There's hardly ever a reason to DROP traffic. Just REJECT it. See http://madduck.net/docs/ipv6 for a discussion.
ip6tables firewall problem
Shadow Hawkins on Wednesday, 27 August 2008 12:19:59
Actually I did use -v and do a similar type of logging but I trimmed all that stuff out when posting so it wouldn't confuse things. Even with the logging turned on I didn't notice anything in my https connection that was being blocked. http, ssh, dns, etc all work fine from the clients behind the firewall but https still seems to hang. Guess I'll have to experiment more and determine what's different about https than the others
ip6tables firewall problem
Shadow Hawkins on Wednesday, 27 August 2008 22:02:21
Nevermind, I got it working.
I'm not entirely sure what I did differently this time when I put the established rules in there but it seems to work fine now. I think I had it working many times while I was fiddling with it but since I run a firewall on my laptop also that was probably causing problems. Anyway, they're both updated and all is working fine. Thanks for the help
Posting is only allowed when you are logged in. |