IPV6 Tunnel (6in4) not receiving any data - transmit works

bjoernhoefer · Thu Aug 04, 2016 1:29 am

Hello,

I'm having a problem getting my IPv6 (6to4) Tunnel up and running. The problem is that I do not receive any data through the tunnel-. Transmitting data works fine - but no data is received - so I've ending up with timeouts...

My Hardware setup
912UAG-5HPnD
Firmware: 3.24
IPv6 and all other package versions: 6.34.3

Related Forum thread at HE's support forum: https://forums.he.net/index.php?action= ... pic=3592.0

My relevant configruations:

ipv6 address print 
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-... INTERFACE        ADV
 0 DL fe80::e68d:8cff:fef7:af59/64                         VLAN666          no 
 1 DL fe80::e68d:8cff:fef7:af59/64                         VLAN10           no 
 2 DL fe80::e68d:8cff:fef7:af59/64                         VLAN1            no 
 3 DL fe80::e68d:8cff:fef7:af59/64                         vlan666          no 
 4 DL fe80::e68d:8cff:fef7:af59/64                         ether1           no 
 5 DL fe80::4421:ccff:febe:507/64                          lte1             no 
 6 DL fe80::200:5eff:fe00:101/64                           gw-vlan10        no 
 7  G 2001:470:25:301::2/64                                sit1             no 
 8  G 2001:470:26:301::1/64                                VLAN666          yes
 9 DL fe80::fefd:0/64                                      sit1             no

ipv6 route print   
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 A S  2000::/3                 2001:470:25:301::1              1
 1 ADC  2001:470:25:301::/64     sit1                            0
 2 ADC  2001:470:26:301::/64     VLAN666                         0

interface 6to4 print 
Flags: X - disabled, R - running 
 #       MTU ACTUAL-MTU LOCAL-ADDRESS   REMOTE-ADDRESS             
 0  R ;;; Hurricane Electric IPv6 Tunnel Broker
        1480       1480 178.112.22.4  216.66.80.98

/ip firewall filter
add chain=input protocol=ipv6
add chain=input connection-state=established,related,new protocol=ipv6
add chain=output protocol=ipv6
add chain=input connection-state=established,related,new log=yes src-address=216.66.80.98
add chain=output dst-address=216.66.80.98
add chain=input comment="Allow limited pings" limit=50,2:packet protocol=icmp
add action=drop chain=input comment="Drop excess pings" protocol=icmp

/ipv6 firewall filter
add chain=output protocol=icmpv6
add chain=input protocol=icmpv6
add chain=output
add chain=input

I've already was in touch with my internet-provider and they do not filter anything.
I've already was in touch with my tunnel provider and they said that the tunnel is setup properly and they told me the same - the receive data, but can't send any data to me...So they think that it is a firewall issue on my router

The problem is also not limited to this tunelbroker - I've experiencing the same problem with other providers.

So can somebody tell me if I should open up something else on my router, or did I miss something.

Sincerely yours

Björn

kamillo · Thu Aug 04, 2016 10:53 am

7 G 2001:470:25:301::2/64 sit1 no
8 G 2001:470:26:301::1/64 VLAN666 yes

I don't understand why do you have the same subnet on 2 different interfaces?
Your default IPv6 route sends traffic to 2001:470:26:301::1 so it goes via VLAN666

bjoernhoefer · Thu Aug 04, 2016 4:06 pm

Hi,

those are two different subnets.
2001:470:25:301::/64 - Server Subnet for transferring data
2001:470:26:301::/64 - Routed Subnet for my clients
Tunnel-Provider has two subnets.

One (the one with 25) is the server subnet - a transfer network.

This has to reside in the sit1 as this is my gateway to the rest of the world.

The subnet with 26 is my routed subnet where my clients/devices reside.(VLAN666 is my testnetwork)

The defualt configration (also provided from my Tunnelbroker) looks lime this:

/interface 6to4 add comment="Hurricane Electric IPv6 Tunnel Broker" disabled=no local-address=178.113.15.165 mtu=1280 name=sit1 remote-address=216.66.80.98
/ipv6 route add comment="" disabled=no distance=1 dst-address=2000::/3 gateway=2001:470:25:301::1 scope=30 target-scope=10
/ipv6 address add address=2001:470:25:301::2/64 advertise=no disabled=no eui-64=no interface=sit1

From my other routers (e.g. 2001:470:26:301::2/64)
I can ping 2001:470:25:301::2
But from none (even not the one which holds the sit1 interface) I cannot ping 2001:470:25:301::1 which would be mandatory to get traffic going

So everyone is thinking that it is a firewall issue, but I dont get the point in my config where it is blocked.

Thu Aug 04, 2016 9:19 pm

Make sure your IPv4 firewall filter's input chain allows protocol 41 (not port 41 - protocol 41 - where TCP/UDP would normally go) from at least the remote IP of your 6in4 tunnel.

bjoernhoefer · Fri Aug 05, 2016 12:53 pm

Hi already did it.

In the Output and Input Chain.
Both directions without any restrictions of ip/interface/state

On the output-chain I see packets/bytes going out.

On the input chain I see nothing moving.

As mentioned before this situation could be recreated with some other IPv6 TunnelBroker. So its not limited to this Broker and as my Internet-Provider stated, they do not block/filter any traffic going from or to me.

pe1chl · Fri Aug 05, 2016 2:32 pm

Start a packet sniff on your external interface and check if you see the incoming protocol 41 packets.
If not, you are sure that the cause is external to you (because the sniff works on data before the firewall filters).
When you do see the packets there, the cause is in your own router config...

Fri Aug 05, 2016 11:05 pm

Start a packet sniff on your external interface and check if you see the incoming protocol 41 packets.

+1

And just to make sure - the Mikrotik has your public IP address directly on it, right? It's not behind another NAT device, right?
If it's behind NAT then that would be a problem too. I assume you have the public IP address shown in your configurations posted at the beginning of the thread. I was unable to ping that IP, so if you still have that IP, then something's amiss - even though your firewall rule accepts pings....

bjoernhoefer · Tue Aug 09, 2016 8:23 pm

Hi,

sorry for the late response.

My IP is not static it is changing dynamically - thats why you couldn't reach it.

If I start the packet sniffer with that commands

/tool sniffer set streaming-enabled=yes streaming-server=192.168.10.250 filter-interface=lte1
/tool sniffer start

And start a ping from my router

ping 2001:470:25:301::1

I receive a timeout from this ping.

on my client (192.168.10.250) I start tcpdump with the following parameters

tcpdump -i vlan0 -vv -n ip proto 41

I receive none - neither in nor out
VLAN0 is my VLAN Adapter to the "backbone" network where my routers reside.

To double check I've started tcpdump to see icmp-messages (even icmp6)

with

tcpdump -i vlan0 -vv -n icmp6

I'll get also no packets

with

tcpdump -i vlan0 -vv -n icmp

I'm at least get some "interesting" data.

19:15:47.273795 IP (tos 0x0, ttl 64, id 51032, offset 0, flags [none], proto ICMP (1), length 56, bad cksum 0 (->1d20)!)
    192.168.10.250 > 192.168.10.2: ICMP 192.168.10.250 udp port 37008 unreachable, length 36
	IP (tos 0x0, ttl 64, id 9174, offset 0, flags [none], proto UDP (17), length 1547, bad cksum 9aee (->babf)!)
    192.168.10.2.53596 > 192.168.10.250.37008: [no cksum] UDP, length 1519

I'm also using wireshark but see nothing reasonable

Trying the following command

/tool sniffer protocol print

I see

# PROTOCOL IP-PROTOCOL PORT                    PACKETS      BYTES        SHARE
 0 ip                                               434     514840         100%
 1 ip       tcp                                      11       7576        1.47%
 2 ip       udp                                     423     507264       98.52%
 3 ip       tcp         80 (http)                    11       7576        1.47%
 4 ip       tcp         59562                        11       7576        1.47%
 5 ip       udp         37008                       423     507264       98.52%
 6 ip       udp         53596                       423     507264       98.52%

Am I doing something wrong???

pe1chl · Tue Aug 09, 2016 9:10 pm

I advise to do a simple trace not the complicated way you use here. Just trace to memory,
or trace to a file and then download the file and view it in wireshark.

Sob · Tue Aug 09, 2016 10:47 pm

Your testing seems too complicated to me, or lets say error-prone. I'd do following simple test instead. Add logging rule:

/ip firewall mangle
add action=log chain=prerouting in-interface=<WAN> protocol=ipv6

Then take your current IPv4 address and use it to create fake 6to4 address (2002:xxxx:xxxx::1) using this command:

ipv4="178.112.22.4"; printf "2002:%02x%02x:%02x%02x::1" `echo $ipv4 | tr "." " "`

Find some online IPv6 ping service which allows to ping entered IPv6 address from their server. Use the fake 6to4 address and it will send some protocol 41 packets to your public IPv4 address. If they reach your router (you'll see them logged), it's a good sign, and you can move to next step and think why these came and those from HE didn't. If nothing comes, try another ping service, just in case the first one had broken routing to 2002::/16. But if neither next one(s) work, it would suggest that ISP might not be telling the truth about not filtering anything.

Wed Aug 10, 2016 12:49 am

Streaming encapsulates the packet capture in a wrapper protocol which is going to cause tcpdump to mis-interpret what it's seeing.
That's why you're getting no results.

There is a utility called traffr (on the Mikrotik downloads page) for Linux which lets you open the streamed captures.

I've never used it - I agree with the previous two posters that you should just capture to flash (choose a file name and size limit) and then download the file to your computer and open it with Wireshark after you stop the capture.

Sob · Wed Aug 10, 2016 6:01 am

Or if you really like tcpdump, there's tzsp2pcap and then you can do:

tzsp2pcap -f | tcpdump -r -

kamillo · Wed Aug 10, 2016 9:55 am

Since you have dynamic IP address this may be a problem

From HE.com web page: https://ipv6.he.net/certification/faq.php

My IPv4 endpoint address is dynamic. Can I still create a tunnel? If yes, what do I need to do when my IP address changes?

Yes, you can still create a tunnel even if you are using a dynamic IPv4 endpoint address. If your IPv4 endpoint address changes, you can either login to the tunnelbroker.net page and update your IPv4 endpoint address or use https://ipv4.tunnelbroker.net/nic/update which is designed to be used to update your IPv4 endpoint address.

Do you have HE end of the tunnel configured correctly (with correct, current IP)? Do you change your IP address there when your IP changes?

bjoernhoefer · Wed Aug 17, 2016 9:06 pm

Hi all, sorry for the late reply. (back at work now...)

Thanks for the whole feedback.

I've made a packet sniff whom I stored to the local disk and analyzed with wireshark.
Findings:
None

No traffic from the tunnel-provider - no feedback from IPv6 pings to my default gateway.

I've also added the log-option to any ipv6 packets coming to my lte1 Interface - no log entries.
I've tried to add the ip: 2002:4d74:8469::1/64 to my lte1 interface and tried to ping it from https://mebsd.com/ipv6-ping-and-traceroute - no packets logged...

The dynamic ip is no problem - I've got a good script which updates my ip every time it changes...

Any suggestions - or should I just wait (100 years) till my provider offers ipv6...

Thanks so far for your support and creative ideas to find the problem.

pe1chl · Wed Aug 17, 2016 10:23 pm

You are doing this on an LTE interface???
That is not going to work. Too many filters, NAT boxes and stupid modems along the route.

bjoernhoefer · Wed Aug 24, 2016 9:50 pm

Yes

Ok, so I will cancel that and maybe try an complete different solution...

So far thanks for your patience with and help.

Björn

IPV6 Tunnel (6in4) not receiving any data - transmit works

IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Re: IPV6 Tunnel (6in4) not receiving any data - transmit works

Who is online