NAT, port aliases, redirect not working after upgrade

[ssachse]

Hi all, after upgrading to version 18.1, none of my port forwarding based on port aliases works. looking at /temp/rules.debug I just found following

......
UnifiPorts = "{ 8080 8443 8880 8843 27117 3478 }"
table <UNIFISERVER> persist
UNIFISERVER = "<UNIFISERVER>"
......

which seems ok, but

......
rdr on igb0 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan10 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan3 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan1003 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan1007 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan1005 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on ovpnc2 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on openvpn inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan8 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb0_vlan101 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan10 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan3 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan1003 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan1007 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb1_vlan1005 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on ovpnc2 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on openvpn inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080
rdr on igb2_vlan8 inet proto {tcp udp} from {any} to {(self)} port $UnifiPorts -> $UNIFISERVER port 8080

......

the rules for redirecting just resolve to the first port in the alias

What can I do ? in the 17 branch everything worked .... Is there a fix ? I have lots of those definitions in my rules. O do I have to revert to the 17 branch ? If, how is it done ?
This way I rendered mi production setup unusable  ;-(

Thanks a lot
Stefan

[frank_p]

I can confirm. same issue here.
seems that the first value of an alias (when more then one) is always fetch by the rule.
The NAT rule is not using all values or definitions.

[slackadelic]

Tested here as well, and I can recreate the issue you are referring to.

Now I say that, to say this: I wasn't using Port aliases before, and was planning on doing so, but will most likely wait at this point.

My individual NAT Port Forward rules are working fine IF I'm not doing port aliases with them.

[marjohn56]

Port Aliases are working in my system using NAT. Still running 18.1.rc2.

So I have Binat rules as I have multiple external IP's. Create that and then create a WAN firewall rule any to my internal mail server with the ports that I have open 443,465 and 993 using a ports alias list and it works fine. I have just deleted the rules, checked that the ports were not accessible and then re-created them again, working fine.

[slackadelic]

Well, I think that's the difference, this is on the production release.. so something changed between that RC and the production release it appears..

[marjohn56]

I can check that but not until after 17:30 GMT, I cannot take opnsense down at the moment, I will get an ear bashing!  :)

[slackadelic]

Hahahaha.. I hear you :)

[frank_p]

Have one alias for web-traffic (ports 80 and 443).
Using that alias to forward traffic to respected servers (Mail and Cloud)
NAT rule uses ALWAYS the first parameter (it was 80). Means also HTTPS traffic was forwarded as port 80 traffic.
As i changed the sequence of parameter from 80,443 to 443,80, the traffic is now forwarded to 443, but not port 80 traffic.

Until V17 both parameter was handeled by the rule like expected 80->80 and 443->443

[marjohn56]

OK, I have just done a test with my 'TEST' unit, virgin 18.1

By default this unit had just the rules it comes with out of the box.

I created a port forward from the WAN to the LAN, forwarding ports 80,443,465 and 993, directing them at my laptop.

Then on my main machine I ran a piece of software called Hercules, if you do not know it then find it, it's a very useful tool, whatever, Hercules allows me to test by trying to connect on whatever port I specify to a given address.

I then ran wireshark on the laptop to see what was coming through the firewall.

I have to say, all the port forwards worked. I don't know what's going on with others, but on my test unit  - perfect.

This was create the port alias(es) then create the port forward, apply.

Note, before someone says, I had to turn of the block private networks as the WAN network was 192.168.1.0
and the LAN network was 192.168.3.0 - but it worked.

[frank_p]

Probably it has to do with "translated NAT rules" from V17 -> V18 during update?
If yes, it can be the reason, that a fresh installation works and an updated installation not.

[marjohn56]

More than likely, I had issues when bouncing 17.7.11 to 18.1.rc1 & rc2.

I've drawn the conclusion that when doing a major upgrade for me it's best to do the configuration from scratch anyway. In the past, with pfS**** I've also had issues so now I just bite the bullet and get on with it.

I know it should not happen, but these things do, and I end up with less down time in the long run.

I got bitten by the ICMP - ICMP6 issue too, so there was a lot of swearing going on.

[ssachse]

Well actually the upgrade did not work for me .... So I reinstalled and imported the config .... but sill the same with the aliases

[marjohn56]

Try doing it with a fresh install and MANUALLY create the config. I know it's a PITA but see if that works, obviously something is not right, but I suspect its in converting the config.

[slackadelic]

Probably it has to do with "translated NAT rules" from V17 -> V18 during update?
If yes, it can be the reason, that a fresh installation works and an updated installation not.

Then the question becomes this:  Do we have to delete all NAT-related rules, even for Outbound bypass rules for say, a VPN, then re-enter from scratch?

[marjohn56]

Sadly there is only one way to prove it. My NAT and Aliases work on a fresh install.

I don't have time at this minute, but in a while I will compare my old 17.7.11 config to my 18.1.rc2 and see if there are any differences, I will also bounce my live firewall to 18.1 and see what happens... but as I said earlier, that needs to be after 17:30 GMT.