Aliases dosen't work(?)

[marjohn56]

Well I've just had a severe hour or two, going round in ever decreasing circles...

I had trouble with getting my system to work everytime I pulled in the config from 17.7.11, running a ping against google failed after every reboot. The only way to get it back was to disable all the rules except the default ones, apply it and back would come the ping, re-apply, all works.... reboot, lost pings again.

looked at rules debug, ahah... the gateway is different on a reboot... it was, it jumps between different gateways on boot, but that was not the issue...

No, it was the rules, namely the IPV6 ICMP rule, which now needs to be IPv6 ICMP.v6

I'm going for a pint.... or several!

[franco]

This doesn't sound so good, something in the code to fix or add compat for in the rules generation?


Cheers,
Franco

[nivek1612]

I see you snuck out 17.7.12 when I was testing 18.1r2

thought my eyes where going for a minute when I looked in the System:Firmware 

[marjohn56]

This doesn't sound so good, something in the code to fix or add compat for in the rules generation?


Cheers,
Franco

If you make  it compatible the you dont need the option in the drop down list, it is a bit misleading, you. Select ipv6 then ICMP,  that's what gets you, you type Ic and up comes ICMP, and it is, but for v4. I wonder how many that will catch. 

[franco]

@nivek1612: keeping the 17.7.x folk happy hopefully.

@marjohn56: Ah so a user-config error? It's true that ICMP and ICMP6 are different IANA numbers. I thought it was something transcending the worlds between 17.7 and 18.1 causing an incompatibility. Discussing ways forward, the ICMP could be appended with 4 or v4 to make it more clear and cleanly sidestep the issue of ambiguity?

[marjohn56]

Or just select ICMP and let the backend work out which, v4 or V6 has already been selected or the drop down list should be empty. Failing that, start both labels with ICMP and add V6 v4 to the end of the label. At present if you enter 'Ic' you only get ICMP for v4.

[franco]

Enter the guy who reported this and said he would have a CVE assigned:

https://github.com/opnsense/core/commit/ae677059d

The story behind it was that although pf accepts these values, it cannot filter them. The CVE was never assigned in the end, though.

Moral of the story: don't try to outsmart 99% of the users for their own benefit, the 1% will try assign a CVE for when a security-related option does not do what it says it should. Since we can't be sure, we should simply make the choices less ambiguous.


Cheers,
Franco

[cardins2u]

After running the two patch my alias still doesn't work.



root@OPNsense:~ # df
Filesystem      1K-blocks    Used    Avail Capacity  Mounted on
/dev/gpt/rootfs  92421240 4125852 80901692     5%    /
devfs                   1       1        0   100%    /dev
devfs                   1       1        0   100%    /var/dhcpd/dev
root@OPNsense:~ #

[marjohn56]

Was this with a clean install of 18.1.rc1?

[cardins2u]

yes - clean install and restored configurations.

[marjohn56]

are the aliases showing in rules.debug?

[marjohn56]

yes - clean install and restored configurations.

Did you do just the two patches mentioned here or three patches? There is one more that MIGHT affect you.

653651046fda533983bfc818d087fee5f073c7f6

That was one to make sure the aliastables folder is there and behaving.