no translation address with matching address family found.

[monreal]

After updating to 18.7.6 I get the followin alert:

opnsense: /usr/local/etc/rc.bootup: New alert found: There were error(s) loading the rules: /tmp/rules.debug:53: no translation address with matching address family found. - The line in question reads [53]: nat on pppoe0 inet proto udp from (pppoe0:network) to $fon -> pppoe0 port 1024:65535 # Fritz!Box VoIP

[fichtner]

Are you sure this is correct? traffic from pppoe0 is natted over pppoe0 ? what is the corresponding GUI outbound rule? Also, it is probably a reboot issue. pppoe0 should have an IP address later and the message should no longer appear. Is that correct?

PS: Probably related to #2837

[monreal]

I deleted ad recreated the rule. Now I get another alert, one about the rule that is now in line 53:

opnsense: /usr/local/etc/rc.newwanipv6: New alert found: There were error(s) loading the rules: /tmp/rules.debug:53: no translation address with matching address family found. - The line in question reads [53]: nat on pppoe0 inet proto tcp from (pppoe0:network) to $freya -> pppoe0 port 1024:65535 # xxx

[monreal]

The outbound rule is the one I posted in the other bug #2837 (comment) - it is probably wrong because I cannot select WAN for the NAT and have to use "Interface address", whatever that is.

The NAT rule in example I is If=WAN, Proto=UDP, SrcAddress=*, SrcPorts=*, DstAddress=WAN address, DstPorts=VoIP(alias), NATIP=fon, NATPorts=VoIP(alias)

[fichtner]

Are you using the patch that @AdSchellevis wrote for you or is this a stock 18.7.x configuration?

[fichtner]

PS: WAN on from / to is not correct most likely. You want the translation target from WAN, but not what you translate as that is transit traffic from e.g. a LAN to the Internet.

[monreal]

Are you using the patch that @AdSchellevis wrote for you or is this a stock 18.7.x configuration?

The patch only lets me select the special networks ("LAN networks") inside the source address. I don't think this is the problem, as I only use the 192.168.178.0/24 net atm so I just added this to the rule. The patch still does not change the problem about being able to select another NAT target as in the automatic rule.

[monreal]

PS: WAN on from / to is not correct most likely. You want the translation target from
WAN, but not what you translate as that is transit traffic from e.g. a LAN to the Internet.

You mean WAN is incorrect as "Translation / Target" and "Interface address" is actually correct? That may very well be the case, as it seems to work fine. However, the automatic rule shows "WAN":

EDIT: compare the different entries under "NAT Address".

[fichtner]

No, incorrect as source / destination.

source: #2841 (comment)
destination: #2841 (comment)

Now your screenshot looks sane.

[monreal]

No, incorrect as source / destination.
Now your screenshot looks sane.

The screenshot below shows the outbound NAT. The rules with with WAN as destination, which are the rules this issue is about, are port-forwarding rules:

Not sure if issue #2837 is connected to this, if the "NAT address"="Interface address" there is actutally fine.

[fichtner]

I'm unsure how to help you as I'm not able to follow. What's not working as expected?

[monreal]

I'm unsure how to help you and I'm not able to follow. What's not working as expected?

Sorry, I guess we got side-tracked after you mentioned issue #2837 in your first comment. This issue is about the "no translation address with matching address family found" alert I get. The error seems to be directly related to the port-forwarding rules, not the outbound rules.

Below you will find all rules related to the Nextcloud forwarding rule shown in the screenshot above:

rdr on pppoe0 inet proto tcp from {any} to {(pppoe0)} port $WWW -> $freya # Nextcloud access
nat on pppoe0 inet proto tcp from (pppoe0:network) to $freya -> pppoe0 port 1024:65535 # Nextcloud access
rdr on igb1 inet proto tcp from {any} to {(pppoe0)} port $WWW -> $freya # Nextcloud access
nat on igb1 inet proto tcp from (igb1:network) to $freya -> igb1 port 1024:65535 # Nextcloud access
rdr on igb0 inet proto tcp from {any} to {(pppoe0)} port $WWW -> $freya # Nextcloud access
nat on igb0 inet proto tcp from (igb0:network) to $freya -> igb0 port 1024:65535 # Nextcloud access

I got a similar set of rules for the VoIP forwarding. The alert is shown only for Nextcloud or VoIP, depending on which comes first. It happens on boot (see initial post) or when renewing IP (see my first follow up). I have not seen these errors before yesterday's update to 18.7.6 and also have not noticed a loss of functionality since. Still I would like to get rid of the alert.

[enoch85]

I have the same issue, it seems to always be the first rule in the list. Had it since 18.7.something and it's still in 19.1.

Everything works, just outputs this on every reboot.

[monreal]

FWIW I also still get this after a reboot but also after the WAN connection is lost and reconnects.

[fichtner]

Still happening?

[enoch85]

Haven't tested 19.1.5, but it's still present in 19.1.4_1

[Taomyn]

Yes, still happens with 19.1.5 https://forum.opnsense.org/index.php?topic=12412

[fichtner]

@AdSchellevis can we avoid writing rules with targets that have empty addresses in the respective family (probably only relevant for IPv4)? Feel free to take this, you'd know better why and how.

[AdSchellevis]

@fichtner I thought we already had something like that, but looking at the issue again, I'm doubting. I'll look into it

[AdSchellevis]

@fichtner here you go 971df3c , although I'm not totally convinced this won't have side affects (since the error doesn't seem to have a relation with the ifconfig output for some odd reason).

[AdSchellevis]

reverted 971df3c , the issue looks related to the nat reflection rules (which should already check for an address of the requested protocol family).

core/src/opnsense/mvc/app/library/OPNsense/Firewall/DNatRule.php

Lines 129 to 148 in 50e323d

	if (!$rule['disabled'] && !empty($rule['enablenatreflectionhelper'])) {
	$reflinterf[] = $interface;
	foreach ($reflinterf as $interf) {
	if (!empty($this->interfaceMapping[$interf])) {
	$is_ipv4 = $this->isIpV4($rule);
	if (($is_ipv4 && !empty($this->interfaceMapping[$interf]['ifconfig']['ipv4'])) ||
	(!$is_ipv4 && !empty($this->interfaceMapping[$interf]['ifconfig']['ipv6']))
	) {
	// we don't seem to know the ip protocol here, make sure our ruleset contains one
	$rule['ipprotocol'] = $is_ipv4 ? "inet" : "inet6";
	$rule['rule_type'] = "nat_refl";
	$rule['interface'] = $interf;
	$rule['staticnatport'] = !empty($rule['staticnatport']);
	yield $rule;
	}
	}
	}
	}
	}
	}

core/src/opnsense/mvc/app/library/OPNsense/Firewall/ForwardRule.php

Lines 142 to 171 in d8f23d5

	// When reflection is enabled our ruleset should cover all
	$interflist = array($tmp['interface']);
	if (!$tmp['disabled'] && !$tmp['nordr'] && in_array($tmp['natreflection'], array("purenat", "enable"))) {
	$is_ipv4 = $this->isIpV4($tmp);
	$reflinterf = $this->reflectionInterfaces($tmp['interface']);
	foreach ($reflinterf as $interf) {
	if (($is_ipv4 && !empty($this->interfaceMapping[$interf]['ifconfig']['ipv4'])) ||
	(!$is_ipv4 && !empty($this->interfaceMapping[$interf]['ifconfig']['ipv6']))
	) {
	$interflist[] = $interf;
	}
	}
	}
	foreach ($interflist as $interf) {
	$rule = $tmp;
	// automatically generate nat rule when enablenatreflectionhelper is set
	if (!$rule['disabled'] && empty($rule['nordr']) && !empty($rule['enablenatreflectionhelper'])) {
	if (!empty($this->interfaceMapping[$rule['interface']]) && (
	!empty($this->interfaceMapping[$rule['interface']]['ifconfig']['ipv4']) ||
	!empty($this->interfaceMapping[$rule['interface']]['ifconfig']['ipv6'])
	)) {
	$rule['rule_types'][] = "rdr_nat";
	$rule['staticnatport'] = !empty($rule['staticnatport']);
	}
	}
	$rule['interface'] = $interf;
	yield $rule;
	}
	}
	}

Can anyone with the issue try to disable "Automatic outbound NAT for Reflection" in Firewall->Advanced and test again? As far as I can see that's these are the only areas in the code generating a rule with as target an interface.

[monreal]

Can anyone with the issue try to disable "Automatic outbound NAT for Reflection"
in Firewall->Advanced and test again?

No message after a reboot with that option OFF. I don't remember why I set it in the first place but I will probably find out sooner or later...

[Taomyn]

I've disabled it on mine and will see how it goes

[fichtner]

@Taomyn any results to share? :)

[Taomyn]

I haven't seen the message since and so far no ill-effects.

[fichtner]

@AdSchellevis do we need another safeguard or close as is?

[AdSchellevis]

close, as far as I know, we can't solve this from user space

[enoch85]

I still see it on 19.1.7. But, I didn't disable automatic rules. Don't know what they do so maybe I break something (yes, lack of documentation on my part). I'm sure I put them there for a reason some time back in the days.

[Sot3]

If anyone's interested, this still occurs in 20.7 when automatic rules are enabled.

[enoch85]

Yeah, same here. Annoying actually. :/

[AdSchellevis]

@enoch85 @Sot3 can you try 54c42a1 ?

[enoch85]

Sorry, I can't find the proper line.

This is what I've got:

    private $procorder = array(
        'disabled' => 'parseIsComment',
        'type' => 'parseType',
        'direction' => 'parseReplaceSimple,any:|:in',
        'log' => 'parseBool,log',
        'quick' => 'parseBool,quick',
        'interface' => 'parseInterface',
        'gateway' => 'parseRoute',
        'reply' =>  'parsePlain',
        'ipprotocol' => 'parsePlain',
        'protocol' => 'parseReplaceSimple,tcp/udp:{tcp udp},proto ',
        'from' => 'parsePlainCurly,from ',
        'from_port' => 'parsePlainCurly, port ',
        'os' => 'parsePlain, os {","}',
        'to' => 'parsePlainCurly,to ',
        'to_port' => 'parsePlainCurly, port ',
        'icmp-type' => 'parsePlain,icmp-type {,}',
        'icmp6-type' => 'parsePlain,icmp6-type {,}',
        'flags' => 'parsePlain, flags ',
        'state' => 'parseState',
        'set-prio' => 'parsePlain, set prio ',
        'prio' => 'parsePlain, prio ',
        'tag' => 'parsePlain, tag ',
        'tagged' => 'parsePlain, tagged ',
        'allowopts' => 'parseBool,allow-opts',
        'label' => 'parsePlain,label ",",63',
        'descr' => 'parseComment'
    );

[fichtner]

Just run this...

# opnsense-patch 54c42a1

[enoch85]

Done, now let's wait and see.

[Sot3]

Same here. When I logged in I had 5 of those messages pending. Is there any way to see those in their entirety without copying and pasting them somewhere else? That's what I had to do to see that they were from two days ago - May 2.

[fichtner]

There's nothing more than these messages. You have NAT rules that require a target address, but it is not available while the rules are reloading for "reasons" in your network.

Try the patch to see if it works.

[enoch85]

@fichtner Good news! The fix seems to work! :D

Please add it in the next maintenance release.

Thanks!

[Sot3]

@fichtner I did load the patch (hence "same here") and I understand what the messages say (though it's still beyond me why they're appearing - I see no "reasons" since the target addresses are there).

My question is how one might read the entire messages instead of just the tail end of them. When the date/time stamp is somewhere off to the left where I can't see it, it's difficult to judge how often they appear. Since the previous ones were two days old, I'm not yet certain that I won't see more, given that only one day has elapsed since the patch was applied. I'll check back again.

[AdSchellevis]

@Sot3 we will ditch the notices in a future release, intermediate we will start sending the messages to syslog as well 1f4bf17 to ease debugging.

[Sot3]

Sorry, I don't understand what that means to me. But I thought I'd stop in to let you know that I still have no further messages popping up today. I guess the fix worked.

[fichtner]

We won't add this in the next maintenance release without a proper testing iteration on the development version. So maybe 20.1.8, maybe later.