Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
openwrt-bot opened this issue Feb 6, 2017 · 6 comments
Open

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

openwrt-bot opened this issue Feb 6, 2017 · 6 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Feb 6, 2017

bolvan:

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/6to4.sh

48,53c48,53
< [ -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"
          return
  fi

  [ -z "$ipaddr" ] && ipaddr=$ipladdr

76c76
< json_add_string local "$ipaddr"

  json_add_string local "$ipladdr"

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 6, 2017

bolvan:

Attached patch file

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 6, 2017

jow-:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2017

bolvan:

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

ip tunnel add tun6to4 mode sit ttl XXX remote any local 190.1.2.3

instead of correct

ip tunnel add tun6to4 mode sit ttl XXX remote any local 10.1.2.3

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2017

dedeckeh:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 7, 2017

bolvan:

6in4 works from the box because 6in4.sh does not have

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

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 8, 2017

bolvan:

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant