|
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
![[be]](/s/countries/be.gif) Shadow Hawkins on Thursday, 14 July 2011 16:19:12
Hello all,
What I fail to find at first sight, is if (and how) I should change my iptables firewall configuration.
Suppose I have a NAT firewall computer from which I will create an IPv6 tunnel with one of SixXS' PoPs. If that NAT firewall computer is also running some services (e.g. samba on port 139), even albeit only internally enabled (but firewall-protected on the outside network interface), could enabling IPv6 on that machine maybe be opening this port ?
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
![[cz]](/s/countries/cz.gif) Carmen Sandiego on Thursday, 14 July 2011 17:24:36
Yes, services which are blindly binding to the all interfaces are exposing their v6sockets as well. You can consult wiki for v6 firewall setup. In short - following setup is sufficient if you don't have any published services:
# Generated by ip6tables-save v1.4.10 on Thu Jul 14 17:21:58 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [195986:18496988]
:OUTPUT ACCEPT [159733:43488024]
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j LOG
-A INPUT -j DROP
-A FORWARD -o eth0 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A FORWARD -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -j LOG
-A FORWARD -o eth0 -j DROP
COMMIT
# Completed on Thu Jul 14 17:21:58 2011
assuming you have eth0 as your internal interface.
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
-A FORWARD -o eth0 -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
What about this little thing called "Packet Too Big", ever heard of it? It is quite useful, especially when you are behind a tunnel which will not have an MTU of 1500...
You might want to not filter ICMP at all actually ;)
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Carmen Sandiego on Thursday, 14 July 2011 18:47:53
Sure I did, it falls under RELATED,ESTABLISHED as part of control protocol and is properly handled by conntrack statefull engine.
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
That would be great if that rule also understood that those packets can come from intermediary routers....
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Carmen Sandiego on Friday, 15 July 2011 07:43:31
Definitely it does, otherwise it is useless :)
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Shadow Hawkins on Saturday, 16 July 2011 21:07:21
(Should I've started a new thread ? Sorry if I'd better)
Aware of this, I have problems not receiving anything as a result of a ping6 on my aiccu interface. I'm using a heartbeat tunnel, and can IPv4 ping www.sixxs.net, see (1)
I adapted my firewall : it's a simple one, not blocking anything, and forwarding everything, see (2)
My kernel is 2.6.25.5-1.1-default from SuSE 11.0
Ping6-ing the local end of the IPv6- tunnel gives (3), so my tunnel and firewall are letting the echo requests out on aiccu. This means also routing issues (and radvd setting issues) are excluded. However, ping6-ing the remote end of the IPv6- tunnel gives no returns (4)
Checking if it really goes out using tcpdump gives (5), proving the same thing. A more elaborated tcpdump taken around the same time doesn't show any replies on DNS requests either (if I'm interpreting the tcpdumps correctly). So really nothing seems to come in on interface aiccu.
What could I be missing here ?
Kind regards,
Ph Bertin
(1) my /etc/aiccu.conf
username XXXX-SIXXS
password xxx
protocol tic
server tic.sixxs.net
tunnel_id Txxxxx
verbose true
daemonize true
automatic true
requiretls false
defaultroute true
(2) my firewall script (only the IPv6- specific part)
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
ip6tables -F
ip6tables -X
ip6tables -P INPUT ACCEPT
ip6tables -P FORWARD ACCEPT
ip6tables -P OUTPUT ACCEPT
(3) result of ping6-ing the local end of the IPv6- tunnel
# ping6 -I aiccu -c 1 2001:6f8:xx:xx::2
PING 2001:6f8:xx:xx::2(2001:6f8:xx:xx::2) from 2001:6f8:xx:xx::2 aiccu: 56 data bytes
64 bytes from 2001:6f8:xx:xx::2: icmp_seq=1 ttl=64 time=0.095 ms
(4) result of ping6-ing the remote end of the IPv6- tunnel
# ping6 -I aiccu -c 1 2001:6f8:xx:xx::1
PING 2001:6f8:xx:xx::1(2001:6f8:xx:xx::1) from 2001:6f8:xx:xx::2 aiccu: 56 data bytes
--- 2001:6f8:xx:xx::1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
(5) Checking the outgoing IPv6 echo request
# tcpdump -t -n -i aiccu -s 512 -vv ip6 or proto ipv6
tcpdump: WARNING: aiccu: no IPv4 address assigned
tcpdump: listening on aiccu, link-type RAW (Raw IP), capture size 512 bytes
IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:6f8:xx:xx::2 > 2001:6f8:xx:xx::1: [icmp6 sum ok] ICMP6, echo request, length 64, seq 1
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Ping6-ing the local end of the IPv6- tunnel gives (3), so my tunnel and firewall are letting the echo requests out on aiccu.
Nope, you are wrong here. Do a "ip -6 get addr <tunnel>::2" and you will see that that address lives on the loopback (lo) interface.
This means also routing issues (and radvd setting issues) are excluded.
Routing for <tunnel>::2 which is local is different from <tunnel>::1. Radvd does not come into play for tunnels (at least you should not configure it for it, as it would not make sensen anyway)
However, ping6-ing the remote end of the IPv6- tunnel gives no returns (4)
Different route, different firewall rules, could also simply be that your tunnel does not work in the first place.
(5) Checking the outgoing IPv6 echo request # tcpdump -t -n -i aiccu -s 512 -vv ip6 or proto ipv6 tcpdump: WARNING: aiccu: no IPv4 address assigned
That is your tunnel interface and you want to check for any kind of packet especially also ICMP.
As that big yellow/orange box notes, look at the "Reporting Problems" list, which points out that you should look at the underlying (ipv4) interface instead, to see if tunneled packets actually go out.
Note also that the tunneled packets can be filtered by your IPv4 firewall. See the FAQ for details on what minimally should be open.
Now if you think/know your tunnel works without a firewall, the best thing you can do is add logging statements to your firewall to see where it kicks out the tunneled packets.
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Shadow Hawkins on Monday, 18 July 2011 16:15:43
I got it running. The problem was indeed located in my IPv4- part of the firewall. However, I'd like to note that while setting up my IPv6 tunnel configuration, I encountered something weird, of which I'm still finding out the explanation why it is like it is: there seems to be a difference between the firewall rule:
iptables -A OUTPUT -p ipv6 -j ACCEPT
and
ip6tables -A OUTPUT -j ACCEPT
or also even
ip6tables -A OUTPUT -p ipv6 -j ACCEPT
The first one works; the last 2 don't. I'm still figuring it out. But it may of course be explained here :-)
I understand that IPv6-in-IPv4 isn't exactly the same as IPv6, but I fail to comprehend the subleties when setting up the firewall...
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Carmen Sandiego on Monday, 18 July 2011 16:26:52
This is because of iptables cmdline parser. When you're supplying ipv6 to -p (protocol) field it chooses the nearest match vhich is 6in4. Proof:
root@ruff:~# iptables -I OUTPUT -p ipv6 -j LOG
root@ruff:~# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 527 packets, 125K bytes)
pkts bytes target prot opt in out source destination
93 21302 LOG 41 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
root@ruff:~#
IPv6 traffic is invisible to iptables as it flows in different stack.
Thus by making
iptables -A OUTPUT -p ipv6 -j ACCEPT
you just allowed outgoing IPv6-in-IPv4 packets for the tunnel.
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Shadow Hawkins on Monday, 18 July 2011 18:16:19
Ruslan,
Thx for answering that promptly. Now, physically speaking, all packets are IPv4, as my external interface doesn't have an (externally usable) IPv6 IP address. However logically speaking, at some point IPv6 packets start moving around in the system's (IPv6) network stack. Hence my (new) question : where is that point ? In other words : where is the point where the IPv4 packets (converted to IPv6 packets) start moving through the IPv6 stack ? Is it aiccu ? lo ? Because that is the point where firewalls care. Maybe a stupid question, but it's that question being answered that would help me better understanding the full picture; I'm just not completely happy with that firewall that "works by accident"...
If I've missed some basic documentation reading, feel free to "just" point me to the link to it.
P.S. I couldn't do ip -6 get addr <tunnel>::2 as Jeroen answered earlier (tough I do believe that aiccu is living on the lo interface!). And I could not find out how ip address help could've helped me out.
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Carmen Sandiego on Monday, 18 July 2011 21:10:30
That point is appearance of the sixxs tunnel (ipv6_interface by default created by aiccu) or any other ipv6 tunnel created manually or by other means.
Once you got ipv6 interface with global scope addressing you're on the hook.
Other approach: once you've done 'modprobe ipv6' on linux (loaded ipv6 stack) you're on the v6 way - you should have link scope addresses on all interfaces. Bringing up sixxs tunnel connects your local ipv6 enabled spot to the outside world and enables global scope address on your router.
With global ipv6 address you can f.i. set SQUID3 proxy and start using v6 sites (before you get subnet)
If your tunnel is brought up properly you should have v6 routes:
root@ruff:~# ip -6 ro
2001:db8:ff00:e8::/64 via :: dev sixxs proto kernel metric 256
2001:db8:ff6d:1::/64 dev eth0 proto kernel metric 256
unreachable 2001:db8:ff6d::/48 dev lo metric 1024 error -101
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
fe80::/64 via :: dev sixxs proto kernel metric 256 mtu 1420
default via 2001:db8:ff00:e8::1 dev sixxs metric 1024
root@ruff:~#
accordingly if you have v6 forwarding enabled
root@ruff:~# sysctl -a 2>/dev/null|grep net.ipv6.conf.all.forw
net.ipv6.conf.all.forwarding = 1
root@ruff:~#
and firewall accepting outgoing traffic
root@ruff:~# ip6tables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 483K packets, 195M bytes)
pkts bytes target prot opt in out source destination
root@ruff:~# ip6tables -nvL FORWARD
Chain FORWARD (policy ACCEPT 228K packets, 36M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmpv6 * eth0 ::/0 ::/0 ipv6-icmp type 128
366K 415M ACCEPT all * eth0 ::/0 ::/0 ctstate RELATED,ESTABLISHED
47 26048 LOG all * eth0 ::/0 ::/0 LOG flags 0 level 4
47 26048 DROP all * eth0 ::/0 ::/0
root@ruff:~#
you should be able to use ipv6 network
root@ruff:~# ping6 -qnc1 switch.ch
PING switch.ch(2001:620:0:14::c) 56 data bytes
--- switch.ch ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 44.287/44.287/44.287/0.000 ms
root@ruff:~#
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Shadow Hawkins on Monday, 18 July 2011 23:08:42
Thx Ruslan. However, this was not what I was after. Let me reformulate my question...
On input (= packets coming from the internet), an IPv6-in-IPv4 packet coming in on eth0 (my external interface) is 'just' IPv4, even if it contains something 'unusual' (i.e. it's IPv6 payload). As from which point in the IP- stack will it start be handled as 'full' IPv6 (and are the ip6tables rules to be used)? As far as I understand, this would be in aiccu. There (still on input), it'll come in as IPv6-in-IPv4 on aiccu, where it's IPv4 headers are stripped. And then from there (= from aiccu) it will be passed along, e.g. to user space or to some other network interface.
Reversely, on output (= packets coming from the local network and going to the internet), it will come in on aiccu as 'full' IPv6. There it will be embedded in a IPv6-in-IPv4 packet and be forwarded for output on eth0.
Is this mental picture correct ? I think it is.
If it is, then why is my following firewall rule needed :
iptables -A OUTPUT -o eth0 -p ipv6 -j ACCEPT
And then why is the combination of iptables firewall rules that already existed :
iptables -A OUTPUT -o eth0 -p tcp -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -j ACCEPT
iptables -A OUTPUT -o eth0 -p icmp -j ACCEPT
not sufficient ?
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
It is very simple:
For filtering IPv4 you use 'iptables'. For filtering IPv6 you use 'ip6tables'.
Your 'default' interface for IPv4 is eth0, for IPv6 it is 'sixxs' (or whatever you call the tunnel interface).
As from which point in the IP- stack will it start be handled as 'full' IPv6 (and are the ip6tables rules to be used)?
These 'full IPv6 packets' arrive on the tunnel interface, thus 'sixxs' and you need 'ip6tables' to filter them out.
There (still on input), it'll come in as IPv6-in-IPv4 on aiccu, where it's IPv4 headers are stripped.
Not quite. The tunneled packet arrives on eth0 (well, your external interface), as that has the destination IPv4 address of the tunneled packet, the kernel processes it as INPUT on eth0. The kernel network handlers kick in for listened protocols, as this is proto-41 or UDP port 5072 for AYIYA, the packet gets decapsulated and the decapsulated packet (the 'full IPv6' as you call it) gets send to the tunnel interface 'sixxs' where you can filter it as INPUT.
Reversely, on output (= packets coming from the local network and going to the internet), it will come in on aiccu as 'full' IPv6. There it will be embedded in a IPv6-in-IPv4 packet and be forwarded for output on eth0.
Other way around: Kernel Packet -> sixxs OUTPUT -> encaps -> eth0 OUTPUT.
Note that if the packet is not local to the host you need to filter in FORWARDING too.
If it is, then why is my following firewall rule needed : iptables -A OUTPUT -o eth0 -p ipv6 -j ACCEPT
That will accept proto-41 packets on eth0. But due heed the warning in the FAQ on connection trackers.
And then why is the combination of iptables firewall rules that already existed : iptables -A OUTPUT -o eth0 -p tcp -j ACCEPT iptables -A OUTPUT -o eth0 -p udp -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -j ACCEPT not sufficient ?
Those filters have NOTHING to do with tunneled IPv6 packets, unless you are using AYIYA (UDP/5072).
Also see the Firewall FAQ.
The best way you can learn how all this works is to fire up this awesome tool called Wireshark and just look at the packets, that in combo with using LOG statements in your firewall rules (don't forget to remove them as your log will run full otherwise ;)
Are IPv4 firewall preparations needed before enabling SixXS IPv6 tunnel ?
Shadow Hawkins on Wednesday, 20 July 2011 10:54:57>If it is, then why is my following firewall rule needed : > iptables -A OUTPUT -o eth0 -p ipv6 -j ACCEPT
That will accept proto-41 packets on eth0. But due heed the warning in the FAQ on connection trackers.
I' d have run into this issue, I guess. Thank you for this warning :-)
|
![[ch]](/s/countries/ch.gif)
on Thursday, 14 July 2011 18:14:57
Posting is only allowed when you are