Debian, 6rd tunnel, and connection troubles
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:
iptraf
always shows IPv6 traffic, so its always making it to the serverserver stops replying on IPv6 after no traffic for awhile (10 minutesish) until a outbound connection is made, then the process repeats.
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
Solution 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.