Debian, 6rd tunnel, and connection troubles

Question

Long story short, I am having issues with IPv6 using a 6rd tunnel with my ISP, Charter Business. They offer a 6rd tunnel that I think I have properly set up, but the server doesn’t reply to every IPv6 request. When the server has the network interfaces idle with no traffic for about 10 minutes, then IPv6 stops accepting inbound connections. to re-allow it, I must go into the server, and make it do a outbound IPv6 connection (normally a ping) to start it back up. Whats weird though i that if I run iptraf when its not working, it still shows a inbound IPv6 packet… the server is just not replying, and I can’t figure out why. Also, if I try to access my server over IPv6 from a house about 1 mile away on the same ISP, it is never able to connect. it always times out, but again the iptraf shows a IPv6 inbound packet. Again, it just does not reply. To test if my server is accessible through IPv6 I always have to use my vzw 4g phone (they use IPv6) or ipv6proxy dot net.

Here is all of the configuration information my ISP gives on there tunnel server:

6rd Prefix = 2602:100::/32
Border Relay Address = 68.114.165.1
6rd prefix length = 32
IPv4 mask length = 0

Here is my /etc/network/interfaces for IPv6 (used x's to block real addresses)

auto charterv6 
iface charterv6 inet6 v4tunnel
        address 2602:100:189f:xxxx::1
        netmask 32
        ttl 64
        gateway ::68.114.165.1
        endpoint 68.114.165.1
        local 24.159.218.xxx
        up ip link set mtu 1280 dev charterv6

here is my iptables config

filter
:INPUT DROP [0:0]
:fail2ban-ssh – [0:0]
:OUTPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:hold – [0:0]
-A INPUT -p tcp -m tcp —dport 22 -j fail2ban-ssh
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport -j ACCEPT —dports 80,443,25,465,110,995,143,993,587,465,22
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A INPUT -p icmp -j ACCEPT
COMMIT

and last here is my ip6tables firewall config

filter
:INPUT DROP [1653:339023]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [60141:13757903]
:hold – [0:0]
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport —dports 80,443,25,465,110,995,143,993,587,465,22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
COMMIT

So Summary:

1. iptraf always shows IPv6 traffic, so its always making it to the server

2. server stops replying on IPv6 after no traffic for awhile (10 minutesish) until a outbound connection is made, then the process repeats.

3. server is NEVER accessable vi same ISP (yet iptraf still shows IPv6 request)

Notes: When I try to access it from the same ISP from across town, even with iptables and ip6tables allowing ALL inbound traffic, this is what iptraf shows.

IPv6 (92 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0
ICMP dest unrch (port) (120 bytes) from 24.159.218.xxx to 97.92.18.xxx on eth0

It's strange it does this even with the IPv6 address being set in the hosts file to the servers domain name. With iptables set up normally with the above configurations it only says this:

IPv6 (100 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0

Also, another thing I noticed. When I am able to access my server, all the IPv6 requests show this

IPv6 (100 bytes) from 68.114.165.1 to 24.159.218.xxx on eth0

which means they are going through the 6rd relay, yet when on the same ISP requests show to come from the honest source IP, which makes me think routes might have something to do with this.

I'm REALLY stuck on this, and any help would be GREATLY appreciated.

EDIT: Don't know if this will help or not, but here is my routes.

root@XXXXXXX:~# route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::68.114.165.1/128             ::                         U    1024 0     1 charterv6
2602:100::/32                  ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         U    256 0     0 eth1
fe80::/64                      ::                         U    256 0     0 eth2
::/0                           ::68.114.165.1             UG   1024 0    30 charterv6
::/0                           ::                         !n   -1  1    32 lo
::1/128                        ::                         Un   0   3    47 lo
2602:100:189f:xxxx::1/128      ::                         Un   0   1    50 lo
fe80::189f:xxxx/128            ::                         Un   0   1     0 lo
fe80::21b:21ff:fe98:456a/128   ::                         Un   0   1     0 lo
fe80::21b:21ff:feab:bd3c/128   ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 charterv6
ff00::/8                       ::                         U    256 0     0 eth1
ff00::/8                       ::                         U    256 0     0 eth2
::/0                           ::                         !n   -1  1    32 lo

Answer 1

You use stateful filtering for ipv4, and I don't see any rule to allow inbound encapsulated 6rd traffic, maybe that is the problem?

If I'm not mistaken, 6rd also uses protocol number 41?

iptables -I INPUT 3 --protocol 41 -s 68.114.165.1 -j ACCEPT

EDIT: you also need to ACCEPT traffic from the ranges of other 6rd customers from your ISP if you want to receive traffic from them.