Recent Posts

He has a talent! That is really nice and unique

For mail anti-spam techniques I would probably block it as well, but for a non-sensitive web service I don't know that I would personally worry about it that much.

Follow-up:  Here's a "live" yet invalid PTR I found in my logs today (IPv4):

  89-149-244-240.local (89.149.244.240)

So why should I allow such stupidity?

Just add the following lines , it works.

-A RH-Firewall-1-INPUT -p 41 -j ACCEPT

Is it ok?
Is it safe?
Thanks a lot.

We don't expire tunnels anymore (not for the last 3+ years). Tunnel up, tunnel down, doesn't matter.

Perfect, thanks for the clarification 

We don't expire tunnels anymore (not for the last 3+ years). Tunnel up, tunnel down, doesn't matter.

Hi,Everyone,

I have successfully obtain the IPv6 Tunnel and make it works on my server without iptables running.
Client with ipv6 can ping/ssh/browser the server very well.
When I start my iptables , it does't work.Client(have ipv6 address) can't ping or ssh through ipv6.

Can anyone tell me how to configure my iptables to support ipv6 tunnel?
I'm a beginner of iptables , so please write it down in details.
Any help would be appreciated.

Here is my tunnel configuration:

modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 72.52.104.74 local 76.164.***.*** ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f04:10f9::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

Here is my iptables configuration:

# Generated by iptables-save v1.3.5 on Wed Sep  1 22:40:31 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [575:379396]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A INPUT -s 72.52.104.74 -p ipv6 -j ACCEPT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i heipv6 -j ACCEPT
-A RH-Firewall-1-INPUT -o heipv6 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 8722 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8722 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 50000:50100 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --sport 50000:50100 -j ACCEPT
COMMIT
# Completed on Wed Sep  1 22:40:31 2010

Can anyone tell me how to configure my iptables to support ipv6 tunnel?
I'm a beginner of iptables , so please write it down in details.
Thank you very much !

Hi,

I have registered to configure a tunnel for my study lab. I have an access list that will create an IPv6 tunnel for only specific IPv4 addresses in my LAN on my router. However these devices are not on 100% of the time, therefore what is the policy on having tunnels for such purposes?

Sixxs works on a credit basis, so missing heatbeats etc penalise the user therefore trying to reward continual uptime, although the router will be up and accept protocol 41 etc is this sufficient? If not what are the penalties as there is no credit/points based system?

Thanks so much!  Opening Port 80 did it!

However, (subtly serious question) surely in using /64s on tunnels, are we not halving (poss) the 340 trillion trillion trillion 'ish V6 addresses available for use or at least losing 65532 addresses for each tunnel used?
Would not  /126 be viable?
Currently use native /126 (ptp) and /128 (lo) and wondering why most tunnel brokers go for /64 ? (not yet setup any internal tunnels)

Longer than /64 prefixes are actually not as widely supported.  Some hardware won't do /126s, for example.  Which makes sense a bit if you figure their internals are liable to be tuned best for dealing with 64bit values.  It's also administratively easier to deal with a bunch of /64s than a zillion little /126s.  And even if /126s were used, I'd almost expect /124s would be more widely used than /126s, since they at least fall on a nibble boundary, which once again, makes administration easier (rDNS breaks on an easy spot, can do substring matches on prefixes from scripts, etc.)