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

Tayga won't start (interface nat64 does not exist) #2094

Closed
pabe-github opened this issue Nov 8, 2020 · 5 comments
Closed

Tayga won't start (interface nat64 does not exist) #2094

pabe-github opened this issue Nov 8, 2020 · 5 comments

Comments

@pabe-github
Copy link

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
[x] The title contains the plugin to which this issue belongs

Describe the bug
Tayga Plugin seems broken as it won't create the required nat64 interface.
Maybe some script isn't calling tayga_interfaces()? (https://github.com/opnsense/plugins/blob/master/net/tayga/src/etc/inc/plugins.inc.d/tayga.inc)

To Reproduce
Steps to reproduce the behavior:

  1. Install plugin os-tayga
  2. Enable plugin under services -> Tayga
  3. Replace IPv6 NAT64 Interface Address with own address
  4. Save

Expected behavior
Tayga starts :-)

Relevant log files

~ # /usr/local/etc/rc.d/opnsense-tayga start
starting tayga
ifconfig: interface nat64 does not exist
ifconfig: interface nat64 does not exist
route: interface 'nat64' does not exist
route: interface 'nat64' does not exist
~ # cat /etc/rc.conf.d/opnsense-tayga 
tayga_var_script="/usr/local/opnsense/scripts/OPNsense/Tayga/setup.sh"
tayga_enable="YES"
tayga_v4address=192.168.255.1
tayga_v4destination=192.168.254.1
tayga_v4pool=192.168.255.0/24
tayga_v6prefix=64:ff9b::/96
tayga_v6address=
tayga_v6destination=MY:PRE:FIX::20

Specifying the tayga_v6address on the GUI (for example to 64:ff9b::c0a8:ff01) adds it to the rc.conf.d/ file, but doesn't change the fact that the interface is missing.

~ # cat /etc/rc.conf.d/opnsense-tayga
tayga_var_script="/usr/local/opnsense/scripts/OPNsense/Tayga/setup.sh"
tayga_enable="YES"
tayga_v4address=192.168.255.1
tayga_v4destination=192.168.254.1
tayga_v4pool=192.168.255.0/24
tayga_v6prefix=64:ff9b::/96
tayga_v6address=64:ff9b::c0a8:ff01
tayga_v6destination=MY:PRE:FIX::20

Environment
OPNsense 20.7.4 (amd64, OpenSSL).
192.168.255.0/24 and 192.168.254.0/24 is not used anywhere in my LAN

@mimugmail
Copy link
Member

Maybe this happened with 20.7 update. Had in mind that FreeBSD 12 already has something native aboard.

@pabe-github
Copy link
Author

Problem possibly found.

Refering to: https://docs.opnsense.org/manual/how-tos/tayga.html

When using 64:ff9b::/96 as IPv6 Prefix, IPv6 Address is NOT optional, not specifying results in:
Error: ipv6-addr directive must be specified if prefix is 64:ff9b::/96 and ipv4-addr is a non-global (RFC 1918) address

As per the HowTo or the helptext the IPv6 Address should be automatically set:
Unless manually configured, Tayga generates its IPv6 Address by mapping its IPv4 Address into its IPv6 Prefix. For example, if the default IPv6 Prefix 64:ff9b::/96 and IPv4 Address 192.168.255.1 are being used, Tayga’s IPv6 Address will be 64:ff9b::192.168.255.1 (64:ff9b::c0a8:ff01).

Manually setting the IPv6 Address to the one mentioned in the HowTo (64:ff9b::c0a8:ff01) unveils why the address won't be set:
Error: ipv6-addr directive cannot contain an address in the Well-Known Prefix (64:ff9b::/96)

Setting the IPv6 Address to some other IPv6 Address (like a GUA of my prefix) brings the interface and service up.

I am not sure if Tayga would work with that configuration, I will try to test that later.

Setting 64:ff9b::c0a8:ff01 as the IPv6 NAT64 Interface Address instead of the IPv6 Address works as well in bringing the interface and service up. But that shouldn't be used:
IPv6 address of the NAT64 interface. Must not have Tayga's IPv6 prefix. Only used for ICMP.

@pabe-github
Copy link
Author

If got myself a working configuration:
grafik

Both censored ipv6 addresses are GUAs of my prefix and not configured anywhere on the firewall.
It is important to not set both to the same address, because local connections (like the peer of a vpn) might fail when the peer only has ipv4 and nat64 gets used. The firewall would send out packets just fine but reply with icmp 17 unreachable to the answer of the peer.
Using the wellknown prefix as ipv6 address (or leaving it empty) still fails to start the service.
Using a different ipv6 address than the one configured as the ipv6 prefix doesn't seem to have any negative consequences.

I think the howto should be changed to state that using the wellknown prefix as an ipv6 address isn't possible / will fail or the reason should be investigated. :-)

@maurice-w
Copy link
Member

@pabe-github, you're right, the IPv6 Address example in the how-to is wrong. Not sure what I was thinking there, especially since I did add a warning that Tayga will refuse to handle addresses composed of the well-known prefix and an RFC1918 address. That applies to Tayga's own IPv6 address, too.

So, the IPv6 Address auto generation only works if you change the IPv6 Prefix to a GUA or the IPv4 Address to a non-RFC1918. Otherwise, you have to specify the IPv6 Address (can be a GUA or ULA). I'll fix this in the how-to (and maybe UI).

As you noticed, setting the IPv6 Address and the IPv6 NAT64 Interface Address to the same address will break things. The solution you came up with (using two unused addresses from your site's GUA prefix) is correct. The only side effect of the IPv6 Address being outside the IPv6 Prefix is that you probably can't ping it (since we only add a route for the prefix). Not a big deal, but if you can confirm this we might want to add a fix.

@mimugmail, sorry for showing up late. I don't frequently browse the issues here.

@mimugmail
Copy link
Member

Please close this one :)

@fichtner fichtner closed this as completed Mar 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants