NAT rule throw error on forwarding to LAN with IPV4/6 and NAT reflection enabled

ggzengel

After upgrading from 2.3.4 to 2.4.0 I get this error:

There were error(s) loading the rules: /tmp/rules.debug:114: rule expands to no valid combination - The line in question reads [114]: no nat on em0 proto udp from em0 to 192.168.180.100 port 57222

		 <rule><source>
				<any></any>

			<interface>wan</interface>
			<protocol>udp</protocol>
			 <destination><address>192.168.180.100</address>

				<port>57222</port></destination> 

			<associated-rule-id>nat_59bb01acde7a72.56640226</associated-rule-id>
			<tracker>1505427884</tracker>
			 <created><time>1505427884</time>
				<username>NAT Port Forward</username></created></rule>

johnpoz

So that is an associated rule from a port forward you created.. Is the port forward missing?

ggzengel

Sorry I copied the wrong rule.

No. If I disable the port forward the error is gone.


		 <rule><disabled></disabled>
			<source>
				<any></any>

			 <destination><any></any>
				<port>57222</port></destination> 
			<protocol>udp</protocol>
			<target>192.168.180.100</target>
			<local-port>57222</local-port>
			<interface>wan</interface>

			<associated-rule-id>nat_59bb01acde7a72.56640226</associated-rule-id>
			 <created><time>1505427884</time>
				<username>admin@87.128.58.176</username></created> 
			 <updated><time>1507845290</time>
				<username>admin@192.168.180.76</username></updated></rule>

johnpoz

Could you just post up your port forward screenshot of your port forward and wan rules..

Did you try just recreating your port forward? And the port forward is set to associated rule.

ggzengel

Want more?

A new rule is not working too.

Selection_014.png_thumb

Selection_013.png_thumb

Selection_011.png_thumb

ggzengel

I was testing multiple combinations:

Even TCP is not working. Port range doesn't matter.

Only changing destination IP was the solution.
If dest IP lies on a interface with IPV6 it's not working.

If have multiple subnets and two of theme have IPV6 enabled. And with both redirecting to is not possible.

ggzengel

Here are two interface. 10.32.12.0 is not working:


em0_vlan12: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
	ether 02:0a:32:c0:77:04
	inet6 2a01:5c0:5:22:a:32ff:fec0:7704 prefixlen 64 
	inet6 fe80::1:1%em0_vlan12 prefixlen 64 scopeid 0x7 
	inet 10.32.12.1 netmask 0xffffff00 broadcast 10.32.12.255 
	nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 12 vlanpcp: 0 parent interface: em0
	groups: vlan 
em0_vlan13: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
	ether 02:0a:32:c0:77:04
	inet6 fe80::a:32ff:fec0:7704%em0_vlan13 prefixlen 64 scopeid 0x8 
	inet 10.32.13.1 netmask 0xffffff00 broadcast 10.32.13.255 
	nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 13 vlanpcp: 0 parent interface: em0
	groups: vlan</full-duplex></performnud,auto_linklocal></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></up,broadcast,running,simplex,multicast>

ggzengel

Disabling "NAT Reflection mode for port forwards" will suppress this error.
But it's not an option for me. I need pure NAT reflection.

johnpoz

Why does UDP Port forward not have a dest address.. Should normally be your WAN address like your other two forwards.

Having a dest any in the port forward is going to be a borked config out of the gate.

ggzengel

Technical it doesn't make a different. The error is the same as without.
Theoretical if the ISP could use my pfsense for forwarding (as a gateway in this subnet), this could be a problem. But I allow traffic from Internet to a special address so it doesn't matter what IP it hit it's always translated.

It's not a borked config. If you have multiple IP addresses from different subnets, what it is not so unusual, this would match.

Do you tell your guests to use door #1 if they visit you and you have only one door? Here it's the same. If you come in from WAN it doesn't matter which IP you use. Always come in.

johnpoz

Do you have multiple wan IPs? If that is the case then sure using any if you want to forward hitting any of them into that box.. But then you could run into a problem if they hit door #1 that answer doesn't come back from door number #2..

Its bad practice to not call out the destination.. You would either call out wan address or vip on that interface, etc.

"I need pure NAT reflection."

For what reason do you need this? How can it do pure nat reflection if you don't call out the destination so it knows what IP to use when it does the pure nat.. When you use pure nat it needs to create redirect rules for your outbound nat to be able to get there. But you have not have a destination set.

This would be my guess to your problem.

ggzengel

here are three configs:

my config without wan address defined:


rdr on pppoe0 proto udp from any to any port 57222 -> 10.32.13.100
# Reflection redirect
rdr on { em0 em0_vlan12 em0_vlan13 em0_vlan14 em0_vlan190 em0_vlan2134 em0_vlan2135 em0_vlan3456 igb0 em0_vlan9 enc0 openvpn } proto udp from any to 5.5.5.54/32 port 57222 -> 10.32.13.100
no nat on em0_vlan13 proto udp from em0_vlan13 to 10.32.13.100 port 57222
nat on em0_vlan13 proto udp from 10.32.13.0/24 to 10.32.13.100 port 57222 -> 10.32.13.1 port 1024:65535
pass  in  quick  on $WAN reply-to ( pppoe0 77.244.96.15 ) inet proto udp  from any to 10.32.13.100 port 57222 tracker 1505427884 keep state  label "USER_RULE: NAT Catch"

your solution with wan address


rdr on pppoe0 proto udp from any to 5.5.5.54 port 57222 -> 10.32.13.100
# Reflection redirect
rdr on { em0 em0_vlan12 em0_vlan13 em0_vlan14 em0_vlan190 em0_vlan2134 em0_vlan2135 em0_vlan3456 igb0 em0_vlan9 enc0 openvpn } proto udp from any to 5.5.5.54 port 57222 -> 10.32.13.100
no nat on em0_vlan13 proto udp from em0_vlan13 to 10.32.13.100 port 57222
nat on em0_vlan13 proto udp from 10.32.13.0/24 to 10.32.13.100 port 57222 -> 10.32.13.1 port 1024:65535
pass  in  quick  on $WAN reply-to ( pppoe0 77.244.96.15 ) inet proto udp  from any to 10.32.13.100 port 57222 tracker 1505427884 keep state  label "USER_RULE: NAT Catch"

my solution with a second IP on interface WAN:


rdr on pppoe0 proto udp from any to any port 57222 -> 10.32.13.100
# Reflection redirect
rdr on { em0 em0_vlan12 em0_vlan13 em0_vlan14 em0_vlan190 em0_vlan2134 em0_vlan2135 em0_vlan3456 igb0 em0_vlan9 enc0 openvpn } proto udp from any to 5.5.5.54/32 port 57222 -> 10.32.13.100
no nat on em0_vlan13 proto udp from em0_vlan13 to 10.32.13.100 port 57222
nat on em0_vlan13 proto udp from 10.32.13.0/24 to 10.32.13.100 port 57222 -> 10.32.13.1 port 1024:65535
pass  in  quick  on $WAN reply-to ( pppoe0 77.244.96.15 ) inet proto udp  from any to 10.32.13.100 port 57222 tracker 1505427884 keep state  label "USER_RULE: NAT Catch"

1. In all three cases Pure NAT refelction is always working with native Interface IP, that's what I need and use (mostly with roaming devices like mobiles if they connect local Exchange or Tobit David)
It doesn't matter if you declare a destination IP. Pfsense is smart enough.
2. Pfsense/FreeBSD uses reply-to and that's the reasen why I changed to Pfsense six years ago. Every package is leaving the right Interface with the right IP, where it come in even with NAT.
I use a lot of Multi-WAN and Multi-IP Config on several Pfsenses.

reply-to
The reply-to option is similar to route-to, but routes packets that
pass in the opposite direction (replies) to the specified inter-
face. Opposite direction is only defined in the context of a state
entry, and reply-to is useful only in rules that create state. It
can be used on systems with multiple external connections to route
all outgoing packets of a connection through the interface the
incoming connection arrived through (symmetric routing enforce-
ment).

ggzengel

After activating ipv6 on one more interface and touching WAN config the NAT error is gone.
Even after reverting the changes.

I think pfsense should boot twice after upgrading.