6rd tunnel not created in snapshot

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi all

I have a Rpi4 running snapshot
I am trying to create a 6rd tunnel with this config:

config interface 'WANT'
        option proto '6rd'
        option peeraddr '81.xxx.xxx.xxxx'
        option ip6prefix '2001:xxxx:xxxx:xxxx::'
        option force_link '1'
        option ipaddr '93.xx.xxx.xxx'
        option ip6prefixlen '32'
        option ip4prefixlen '0'

There is no error but the interface 6rd-WANT is not created
Package 6rd is installed on the system

--edit--

Actually there is an error repeating in log:

Mon May 25 10:48:49 2020 daemon.notice netifd: WANT (24228): Command failed: Unknown error
Mon May 25 10:48:49 2020 daemon.notice netifd: Interface 'WANT' is now down
Mon May 25 10:48:49 2020 daemon.notice netifd: Interface 'WANT' is setting up now

Some details: my openwrt router is behind a ISP router, I get IPv4 private address from it (Openwrt is in DMZ) and I am trying to open a 6rd tunnel directly on openwrt

Can anyone help in troubleshoot this?

Thanks

2

So actually I figured out that I do not need to put the IPv4 field in prefix, with this configuration the 6rd tunnel goes up:

config interface 'want'
        option proto '6rd'
        option ipaddr '93.xx.yyy.zzz'
        option peeraddr '81.aaa.bbb.ccc'
        option ip6prefix '2001:ttt::'
        option ip6prefixlen '32'

However on the openwrt router the IPv6 connectivity does not work, If I ping ipv6.google.com I can see the packet going out on the 6rd-want interface but never coming back:

root@MenionRouter:~# tcpdump -i 6rd-want "icmp6 && ( ip6[40] == 128 || ip6[40] == 129)"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 6rd-want, link-type RAW (Raw IP), capture size 262144 bytes

11:20:18.785548 IP6 2001:ttt:yyyy:zzzz::1 > mil04s04-in-x0e.1e100.net: ICMP6, echo request, seq 0, length 64
11:20:19.785840 IP6 2001:ttt:yyyy:zzzz::1 > mil04s04-in-x0e.1e100.net: ICMP6, echo request, seq 1, length 64
11:20:20.786166 IP6 2001:ttt:yyyy:zzzz::1 > mil04s04-in-x0e.1e100.net: ICMP6, echo request, seq 2, length 64
11:20:21.786493 IP6 2001:ttt:yyyy:zzzz::1 > mil04s04-in-x0e.1e100.net: ICMP6, echo request, seq 3, length 64
11:20:22.786808 IP6 2001:ttt:yyyy:zzzz::1 > mil04s04-in-x0e.1e100.net: ICMP6, echo request, seq 4, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
root@MenionRouter:~# cat /etc/config/network

but actually no 6rd packet is generated on wan interface:

root@MenionRouter:~# tcpdump -i eth0.3 proto 41
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.3, link-type EN10MB (Ethernet), capture size 262144 bytes


^C
0 packets captured
4 packets received by filter
0 packets dropped by kernel

It is like that the 6rd tunnel is not working at all

3

Can you try to have the OpenWrt directly connected to the ISP and not behind the router of the ISP?
6rd usually works automatically as all settings are advertised with DHCP, but you are not getting them if you don't get dhcp packets.

4

No I cannot because it is a VDSL + VoIP subscription
The 6rd tunnel information should be ok, since are well known on internet. 6rd tunnel on ISP router (Fritzbox) works.
The strange thing is that if I configure them into a 6in4 tunnel it works, but then I have problem with the /64 prefix given.

In this case I would like to troubleshoot why I do not get proto 41 packet on physical WAN interface as it should (and as it happens for example with a Hurricane 6in4 tunnel)

5

I think the ipaddr configured as local endpoint is used both when calculating the IPv6 prefix and as source address of the packets. Which won't work if the address isn't assigned to a local interface.

If you do assign it to a local interface, and then add SNAT and DNAT rules to translate the proto 41 packets to your private IPv4 address then it could work.

6

Ok, it was my doubt also, but should I see at least outcoming proto 41 packet?

7

You will only see outgoing packets if you have configured 93.xx.yyy.zzz on an interface with proto 'static'. (With proto '6rd' and other tunnel protocols the ipaddr option can only contain an address that has been assigned on another interface.)

8

I see, it makes sense. So my only option, already testerd is to enable IPv6 on ISP router and use DHCPv6 relay on Openwrt router. The only thing I have to tune is the ICMPv6 that appear to be filtered on ISP router

9

Don't you think configuring your public IPv4 address on OpenWrt and using DNAT and SNAT to translate to/from the private IPv4 address will work?

10

Can you give me more datails on how do it? If I set local endpoint to my private WAN address the entire 6rd packet is malformed or?

11

Try this in /etc/firewall.user

PUBLICIP=93.xx.yyy.zzz
DMZIP=x.x.x.x
iptables -t nat -A postrouting_rule -s $PUBLICIP -o eth0.3 -p 41 -j SNAT --to-source $DMZIP
iptables -t nat -A prerouting_rule  -d $DMZIP -i eth0.3 -p 41 -j DNAT --to-destination $PUBLICIP

After modifying NAT rules you need to delete conntrack entries (conntrack -D -p 41) or restart OpenWrt.

You also need to configure $PUBLICIP/32 on a local interface.

Edit: Renamed WANIP->PUBLICIP and LANIP->DMZIP

1 Like
12

But what is LANIP? Also I need a "dummy" interface configured with WANIP (which is on ISP router) ?

13

I renamed the IPs above. DMZIP is the IP that's used between the OpenWrt and the main router.

You can configure the IP address on the loopback interface "lo" this way.

config interface 'local'                      
        option proto 'static'                 
        option ipaddr '93.xx.xxx.xxx'            
        option netmask '255.255.255.255'
        option ifname '@loopback'
1 Like
14

@mikma So it was enough to create a local interface with PUBLICIP

If you think about it it makes sense. Traffic originated from LAN (even if I did not put the local in LAN) is already SNAT/DNAT to WAN in this case DMZIP despite of the fact if the address are private or public IP

15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.