OpenWrt/LEDE Project

  • Status Waiting on reporter
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by bolvan - 06.02.2017

FS#472 - 6to4 support with 1:1 nat

One-to-one NAT means you have LAN address on interface and its mapped 1:1 to external ip addresses.
You can have incoming connections.

In such configuration “ipaddr” must be specified in 6to4 protocol section.
But due to bug this addr is submitted as local address for tunnel creation.
It does not work.

I fixed this with the following patch to /lib/netifd/proto/

< [ -z “$ipaddr” ] && {
< if ! network_get_ipaddr ipaddr “$wanif”; then
< proto_notify_error “$cfg” “NO_WAN_ADDRESS” < return
< fi
< }

if ! network_get_ipaddr ipladdr “$wanif”; then
> proto_notify_error “$cfg” “NO_WAN_ADDRESS”
> fi
> [ -z “$ipaddr” ] && ipaddr=$ipladdr
< json_add_string local “$ipaddr”

json_add_string local “$ipladdr”

I suggest you integrate this patch or do something similar yourself.

bolvan commented on 06.02.2017 09:43

Attached patch file

Jo-Philipp Wich commented on 06.02.2017 09:58

I do not understand your patch. All it does is making 6in4 fail when it finds no wan ip even if the user specified an ip in the configuration. It does not change anything in the actual tunnel setup logic.

What is this bug you're referring to?

bolvan commented on 07.02.2017 08:27

Imagine wan has ipv4 "". Its mapped 1:1 by isp to
I specify option "ipaddr" as correctly calculates 2002:BE01:0203::1 but then it sets up link as

ip tunnel add tun6to4 mode sit ttl XXX remote any local

instead of correct

ip tunnel add tun6to4 mode sit ttl XXX remote any local

And it does not work.
In my patch I force actually present IP to netifd.
Yes, my approach may be not 100% optimal. There may not be WAN if at all.
I've just experienced non-working 6to4 in my setup and found the reason.
You know better how to fix it perfectly
But note that local addr can be dynamic. Its bad to require to hardcode it in config.

Project Manager
Hans Dedecker commented on 07.02.2017 08:40

But is that not misconfiguration by the user ?
I mean if you specify an IP address via uci config I expect this IP address to be applied even if the wan interface has an IP address.
All other tunnel protocols like 6in4, 6rd behave in the same way

bolvan commented on 07.02.2017 08:46

6in4 works from the box because does not have

test_6to4_rfc1918 "$ipaddr" && {
proto_notify_error "$cfg" "INVALID_LOCAL_ADDRESS"

6in4 does not need to find out actual external ip address.
6to4 need it because its used to construct 2002:

bolvan commented on 08.02.2017 10:41

"ipaddr" option is documented as "Local IPv4 endpoint address". it can be useful when interface has multiple IPs. ipaddr must be one of the locally present IPs, not ephemeral "external IP".
we can leave it as is but we need to override generation of 6to4 prefix
we need either specify "external_ip" (as its done in miniupnpd uci conf) or directly 2002: prefix and abandon its auto-generation
Now 2002 prefix is generated only from either "ipaddr" or ip taken from interface and there's no option to change this, also no way to disable autogeneration.


Available keyboard shortcuts


Task Details

Task Editing