OPNsense Forum
English Forums => General Discussion => Topic started by: Mega32 on October 28, 2023, 11:07:07 am
-
Comming "From the Other side", and finally having had enough of their 180 degrees turns.
Looking forward to use a firewall where one hopefully can trust the promises that has been given."
I'we used "The Other one" for 5+ years, and am working w. enterprise networking daily.
The tech stuff doesn't scare me, but a totally new GUI layout ... It's gonna be steep.
Just installed the latest OPNsense on a Protecli i3 w. 6 IF's.
And am looking around in the gui right now.
Any hints on how2 migrate (import) bits of the "Other" config into OPNsense would be much appreciated.
Especially my IP/Network & Port aliases would be nice to "import"
NB: The below steps are only a suggestion/help in how to migrate a pfSense CE-2.7.0 config into OPNsense
There is absolutely no guarantee, that it will import everything correctly
Always check your migrated OPNsense config manually, and verify your setup, before setting the firewall into production.
Initial preparation of the pfS config file, before importing/restoring sections into OPNsense.
https://forum.opnsense.org/index.php?topic=36683.msg179265#msg179265
First hurdle: Import Aliases
https://forum.opnsense.org/index.php?topic=36683.msg179305#msg179305
Second hurdle: Import Vlans
https://forum.opnsense.org/index.php?topic=36683.msg179400#msg179400
Third hurdle: Import Certs and OpenVPN
https://forum.opnsense.org/index.php?topic=36683.msg179789#msg179789
Fourth hurdle: Import Interfaces
https://forum.opnsense.org/index.php?topic=36683.msg179463#msg179463
Fifth hurdle: Import Nat/Portforwarding
https://forum.opnsense.org/index.php?topic=36683.msg180141#msg180141
Sixth hurdle: Import firewall rules
https://forum.opnsense.org/index.php?topic=36683.msg180003#msg180003
ToDo ...
Move to a Physcical Box (Right now on VBOX) - Moved to Protecli i3 6port - OK
Nat/Portforward - Imported , untested yet
DNS
DHCP
Logging (Rules and Remote syslog)
Packages
-
I think doing an export of PFsense config and than importing it into OPN is not a good option. In order to all the features/things you have its better to configure the new FW from scratch.
I would advise to scope what you have configured on PF and than reconfigure it on OPN. If you dont have a scope done you can do it manualy or use a script for it.
https://github.com/TKCERT/pfFocus
If you have only Interfaces, Rules, Aliases this can be fairly easy and fast.
https://forum.opnsense.org/index.php?topic=21083.15
https://forum.opnsense.org/index.php?topic=28209.0
* backup the config. It is XML so fairly readable
* Make screenshots of changed settings you remember
* Create a pfsense VM restore the mentioned backup so you can easily compare
From my experience OPN is not hard for configuration.
Regards,
S.
-
Hi and welcome,
Unfortunately alias support was rewritten in 2019 which doesn't use the old storage location in the config.xml anymore. I think it would be possible to attempt a migration, but it's a bit tricky and the result may not be as desired.
Consider this just pointers to how this could work. No idea if layout changed too much between 2019 and now on their end. I can't vouch for this and it's not a goal we have as a project to be driven by external changes just to make this work.
Make sure you are on 23.7.7 first, then delete the new structure from the config.xml (it will kill all the aliases currently set up):
# pluginctl -f OPNsense.Firewall.Alias
(but a backup will be created)
Now edit /conf/config.xml to place your old aliases from the pfSense config, I think these were under <aliases/> tag directly below the root node "<pfsense/>".
When done run the migration and see what happens:
# /usr/local/opnsense/mvc/script/run_migrations.php
If not revert to the initial backup for safety.
Cheers,
Franco
-
Hi there!
If you have a lab setup you could try to import bits and pieces, I did it in 2015, when both senses were pretty close. Maybe aliases and FW rules still working? Interfaces, NAT? Or you copy and paste with a text editor and import the .xml afterwards.
The design of the GUI is imho much more intuitive in OPN, but for sure you have to adapt. What I still miss are the separators for FW rules to mark groups of rules, but no way to get that feature out of the devs... ;-) trying for about 6-8 years now.
Enjoy the latest and greatest in OPN, as pfsense patching the CE once a year or so.
-
Hi there!
If you have a lab setup you could try to import bits and pieces, I did it in 2015, when both senses were pretty close. Maybe aliases and FW rules still working? Interfaces, NAT? Or you copy and paste with a text editor and import the .xml afterwards.
The design of the GUI is imho much more intuitive in OPN, but for sure you have to adapt. What I still miss are the separators for FW rules to mark groups of rules, but no way to get that feature out of the devs... ;-) trying for about 6-8 years now.
Enjoy the latest and greatest in OPN, as pfsense patching the CE once a year or so.
Personaly In regards of the separators I use the Categories option, they allow to at least to search for the rules with same TAG. I know its not the same, but it came handy the moment I started to have like 5-10 VLANs.
Regards,
S.
-
Yeah but categories can be deceiving. Enabling one in Firewall and going to NAT for example and I was like multiple times "oh no everything is gone" xD, but the category was just still enabled.
-
@all
Thanx for the current answers ... Keep'm comming
I have spend some time setting up a test OPNsense in VBOX.
It took some time as i had to "Bridge Wan" in order to be able to do https to it.
And i then had some issues if i used my Linux , where VBOX was installed.
As the browser (firefox) source to the VB OPNsense fwall....
I had to use another PC in order to be able to browse to the OPNsense (bridged ip) ...
Mega strange ... And i tried to allow "any .. any .. any" still no luck
I have allowed RFC1918 on WAN IF (settings).
I could connect if i did a : pfctl -d , but every time i changed something it "died" (prob enabling pfctl).
My guess would be that this is a VBOX issue ....
Well i'm now ready to play with a device that can do snapshots..
@Franco
I'll try that trick asap (but we have to go to dinner now)
I'll continue tomorrow
PS: I also donated a bit, in the sticky thread
-
Initial Vlan/Vlan-Interface name adapting of the pfS "full config file".
Currently only needed if vlans are present in the pfSense config.
It turns out that pfSense and OPNsense doesn't use the same VLAN and Interface VLAN naming anymore.
And even though the OPNsense importer will import the current CE-2.7.0 Vlan names, the new pfSense naming might create other issues on the OPNsense.
Franco explains:
At a quick glance it's the new (incompatible) way the VLANs are named in CE-2.7.0:
<if>igb1.899</if>
The old compatible way would be igb1_vlan899, but that also requires
changing the VLAN device names as well. This is going to be a manual
process. Otherwise the device will never be fully understood as a VLAN
and it could have more side effects during operation.
Before the pfS config file is being imported to OPNsense:
Vlan and interface names/referrals like the below:
igb1.100
must be changed to
igb1_vlan100
So we have to manually edit the pfS config file, and change some vlan and interface vlan names.
I made a manual search replace of these two combinations, as I only have vlans on em1 and em2
Watch out if you use "Replace All" ...
em1.
em1_vlan
em2.
em2_vlan
pfSense CE-2.7.0 naming of vlans.
<vlans>
<vlan>
<if>em1</if>
<tag>100</tag>
<pcp></pcp>
<descr><![CDATA[inside]]></descr>
<vlanif>em1.100</vlanif>
</vlan>
<vlan>
<if>em1</if>
<tag>110</tag>
<pcp></pcp>
<descr><![CDATA[new_inside]]></descr>
<vlanif>em1.110</vlanif>
</vlan>
<vlan>
<if>em2</if>
<tag>10</tag>
<pcp></pcp>
<descr><![CDATA[inet_only]]></descr>
<vlanif>em2.10</vlanif>
</vlan>
Adapted pfSense naming of vlans, before OPNsense import
<vlans>
<vlan>
<if>em1</if>
<tag>100</tag>
<pcp></pcp>
<descr><![CDATA[inside]]></descr>
<vlanif>em1_vlan100</vlanif>
</vlan>
<vlan>
<if>em1</if>
<tag>110</tag>
<pcp></pcp>
<descr><![CDATA[new_inside]]></descr>
<vlanif>em1_vlan110</vlanif>
</vlan>
<vlan>
<if>em2</if>
<tag>10</tag>
<pcp></pcp>
<descr><![CDATA[inet_only]]></descr>
<vlanif>em2_vlan10</vlanif>
</vlan>
pfSense CE-2.7.0 naming of vlan-interfaces.
<interfaces>
<lan>
<enable></enable>
<if>em1.110</if>
<descr><![CDATA[LAN]]></descr>
<spoofmac></spoofmac>
<ipaddr>192.168.110.1</ipaddr>
<subnet>24</subnet>
</lan>
<opt1>
<descr><![CDATA[inside_em1_VL100]]></descr>
<if>em1.100</if>
<spoofmac></spoofmac>
<enable></enable>
<ipaddr>192.168.17.1</ipaddr>
<subnet>24</subnet>
</opt1>
<opt2>
<descr><![CDATA[mgmt_em1_VL120]]></descr>
<if>em1.120</if>
<enable></enable>
<spoofmac></spoofmac>
<ipaddr>192.168.120.1</ipaddr>
<subnet>24</subnet>
</opt2>
<opt3>
<descr><![CDATA[inet_only_em2_VL10]]></descr>
<if>em2.10</if>
<spoofmac></spoofmac>
<enable></enable>
<ipaddr>192.168.11.1</ipaddr>
<subnet>24</subnet>
</opt3>
Adapted pfSense CE-2.7.0 naming of vlan-interfaces, before OPNsense import.
<interfaces>
<lan>
<enable></enable>
<if>em1_vlan110</if>
<descr><![CDATA[LAN]]></descr>
<spoofmac></spoofmac>
<ipaddr>192.168.110.1</ipaddr>
<subnet>24</subnet>
</lan>
<opt1>
<descr><![CDATA[inside_em1_VL100]]></descr>
<if>em1_vlan100</if>
<spoofmac></spoofmac>
<enable></enable>
<ipaddr>192.168.17.1</ipaddr>
<subnet>24</subnet>
</opt1>
<opt2>
<descr><![CDATA[mgmt_em1_VL120]]></descr>
<if>em1_vlan120</if>
<enable></enable>
<spoofmac></spoofmac>
<ipaddr>192.168.120.1</ipaddr>
<subnet>24</subnet>
</opt2>
<opt3>
<descr><![CDATA[inet_only_em2_VL10]]></descr>
<if>em2_vlan10</if>
<spoofmac></spoofmac>
<enable></enable>
<ipaddr>192.168.11.1</ipaddr>
<subnet>24</subnet>
</opt3>
Remember to do your own adaptations
Ie. I have connected my OPNsense WAN (dhcp) to my "Inside Vlan".
And i have changed the "Inside Vlan ip net" in my pfS config file, that's going to be used for OPNsense.
Else i would have same ip on the OPNsense Inside , as on the OPNsense Wan (connected to my pfS Inside Vlan).
The OPNsense Inside will get the original lan restored, as soon as it goes into prod.
-
Hmm, this has to work one way or the other. Would you mind sharing sample config from your end so I can take a closer look? Best via mail to franco AT opnsense DOT org
Thanks,
Franco
-
Apparently there was an issue in the migration that prevented nested aliases from validating during migration:
https://github.com/opnsense/core/commit/e4c857f0
So here is the full sequence on top of 23.7.7:
The patch will be included in 23.7.8 onwards so no need to run the patching there!
# opnsense-patch e4c857f0
(only apply the patch once otherwise it's going to be removed again)
# pluginctl -f OPNsense.Firewall.Alias
# pluginctl -f aliases
(confirm delete of garbage entries to allow for a migration)
edit /conf/config.xml to add your pFsense <aliases/> section cleanly again -- it should go right above the last line of the file saying </opnsense>
# /usr/local/opnsense/mvc/script/run_migrations.php
Migrated OPNsense\Firewall\Alias from 0.0.0 to 1.0.1
In case there are errors please post them here. They can be seen via the following command when the migration would fail.
# opnsense-log
Cheers,
Franco
-
First hurdle: Import Aliases is done with the help from Franco :D
Couldn't have done it without him 8)
New way to import aliases
Franco did some magic, and with a yet another patch, he made it possible to import the aliases section, directly from the pfS config file.
Apply the patch(es) (if you're on 23.7.xx) - Prob not needed if you're on next release:
NB: Only apply once, or the next apply will revert the patch.
opnsense-patch e4c857f0
opnsense-patch b8bbb00da7
Now yo should be able to import Aliases directly from the pfS config file.
Alias import done ...
The below steps are now obsolete:
I have made a shell script automating the import.
Requires a fully updated 23.7.7:
And a for now a patch - The patch might not be needed on later versions.
Apply the patch:
opnsense-patch e4c857f0
NB: The script will start out by erasing ALL existing aliases in the OPNsense config file - /conf/config.xml
So only use it on a test machine with a "Clean config"
Once the aliases has been imported, you can export the aliases from the test machine as json or as a subset of the full config.
I would expect that file to import "Clean" on any other 23.7 machine.
See attached script, for instructions.
And as usual : Use at your own risk
-
I just "took my own medicine" , and failed :-\
Do you want to flush this config property? [y/N]: y
Done. A backup was created and can be restored if needed.
Cannot find aliases <---- This one can be ignored - It's due to the Alias section delete's performed by the script
*** OPNsense\Firewall\Alias Migration failed, check log for details <---- Import Error
I forgot to apply the patch ::)
root@xxxx-fw-01:~ # opnsense-patch e4c857f0
Fetched 28df2b8fb via https://github.com/opnsense/core
Next run went fine , and my aliases appeared
-
Can you change to patch e4c857f0 in your steps... I found a slightly related bug and that's the actual backport for 23.7.8.
Cheers,
Franco
-
Sure
I just applied it, (wo. removing the other patch) , it applied cleanly
And i corrected the patch# in the steps above.
Thnx
-
I tried the "same patch trick" , on a pfS exported Vlan-section (attached just before the </opnsense> line) .
It didn't barf or output anything.
But no vlans appeared.
Update it does work ... If you remove the "empty" OpnSense "Vlan section" from config.xml
@Franco ... Any trick to do that ??
I mean like this one for Aliases
pluginctl -f OPNsense.Firewall.Alias
-
To my knowledge VLANs could work fine from the GUI configuration backup import. Feel free to send your import bit via mail so I can take a look if it doesn't work out.
Cheers,
Franco
-
Ahh ... I never tried GUI
It's not happy
I fed it a pfS (Vlan-export only section)
Is that ok , or should it be a full config ??
Import Vlan - Success
Success if i feed it a Full pfS config file, and just restore the "Vlan Devices" section
Edit:
Seems like i have used a wrong screen-copy image, that shows error in the top.
Please ignore the error shown .. It works
-
Import Interfaces - Success .... Almost (I lost WAN)
You have to think/plan when restoring the interfaces, it would be quite easy to break your existing IP connection
You are loading new interface definitions ...
Ie. you might want to make sure your pfS (Config file) connect IF has the same IP addr. as current OPNsense firewall connect IF. Else you'll looe yor IP connection after import.
And make sure you have imported Vlans first, if you use them.
Same goes for VPN Client/Servers, and their Certs
On my Prod Box , I have an unused interface. the last interface (em3) on my 4-port fwall.
So i have assigned that as an untagged "Emergency Connect IF"
And HTTP access to the fwall (Mgmt) is permitted on that IF.
So i know i can connect to my em3 IF, and use that if i lose access.
But - I run these migrations on a "Virtual OPNsense",and always have access to the CLI console.
Even if i loose all network interfaces..
That will enable me to copy a previous "good config" to /conf/config.xml , in order to make a "fallback".
On my physical boxes i have a serial port enabling me to do the same access, even if i loose all network interfaces.
On my virtual VBOX OPNsense i connect (IP) to FWall mgmt (HTTPS) via the WAN IF (Only one with physical access).
Importing the pfS interfaces to OPNsense
I just did a restore Interfaces section on the OPNsense, and fed it "a slightly modified" full pfS config file.
It was an "Almost" success , as i "Lost the WAN IF" , but still had IP connection ... ?? ..
All other interfaces seems to have been imported.
I tried fallback & run the import two times, but kept on loosing WAN.
In the end i ended up doing the import, and manually adding (vi editor) the wan interface to config.xml
I had a backup pf the OPNsense config , when wan was present & working.
I "snipped" the <wan> ... </wan> section out of the working backup config.
And pasted that into config.xml , just above the <lan> section.
I then ran : /usr/local/opnsense/mvc/script/run_migrations.php
And now wan was present in the config, along with all the other IF's from the pfS
If/When i find a solution to the disappearing wan during import, I'll update the post.
Tick prevent interface removal isn't needed anymore, after doing the pre-adaptation of the vlan/vlan-interface names, before importing into pfSense
Tick prevent interface removal
After importing IF's go into EVERY IF - Also VPN interfaces's (and maybe others .. LAGG etc ) if present in config.
And tick "Prevent Interface removal"
Else you risk they're removed on next reboot.
When rebooting , some kind of importer is running.
And it (at console) decides "No default interfaces found - Running interface assignments".
This means i would have to assign all interfaces (20).
And if not doing that, after some time it starts some auto detection. That assigns Lan to em0 (first physical) , and wan to em1 (2'nd physical) , and drops the rest of the assignments.
Next - Make sure all interfaces on OPNsense has the same name as on the pfS
By this i mean even if you name your IF DMZ .. It still uses an internal name, usually : optxx
If we should stand a chance of important the pfS firewall rules, then the "internal names" MUST be the same.
I have compared the interface names. And it seems like OPNsense uses the optxx names given from the pfS import.
So i'm a "happy camper" ....
Well after doing the above "Prevent interface removal" .... Lost a few remaining hairs on that one ;)
-
Once you are done with your migration you will be the migration expert :)
I would actually advice as well if you are willing to create a full fledged guide on the Tutorials and FAQs section once you are done with the migration.
https://forum.opnsense.org/index.php?board=24.0
Summarizing all what can be migrated and which way. Would be helpful for others as well.
Regards,
S.
-
Once you are done with your migration you will be the migration expert :)
I would actually advice as well if you are willing to create a full fledged guide on the Tutorials and FAQs section once you are done with the migration.
https://forum.opnsense.org/index.php?board=24.0
Summarizing all what can be migrated and which way. Would be helpful for others as well.
Regards,
S.
Hi Seimus
I doubt i'll be making a document of the conversion.
I'll be describing it in this thread , and make Bold entries in the first post, to relevant posts in this thread.
I'll do the bold entries as a kind of index, so you don't have to scan the full thread.
-
https://www.netgate.com/blog/netgate-pfsense-plus-tac-lite-available-for-129-per-year
What's your opinion on this as former Mother Sense user? It seems like they noticed their actions had adverse effects.
-
I haven't had much faith in CE since they made PLUS
The only reason i didn't switch to OPN back then, was that they made PLUS free for Home+Lab (HL) use.
But now i have "downgraded" my PLUS boxes to CE, as they write HL registered systems won't get any upgrades without a $129/yr subscription.
So i will still convert my home boxes to OPNsense.
Who knows when they do another "CE surprise", or if CE will slowly "obsolete to death" ...
I think the reviving of the TAC-Lite $129/yr subscription, was to keep SMB's on PLUS.
And at least cash in the smaller fee, instead of nothing.
But i think a lot of users have lost trust in them, no matter what broken promises they are reviving.
I feel sorry for the people that might not be capable of migrate to OPN ...
They might be trapped over there.
Maybe OPNsense Tech-Support could offer a "Basic config" conversion to OPN if the customer ie. pays for a 2..3/yr subscription up front. Or maybe if the customer buys a DEC Box ...
-
Import Certificates
My Certs imports wo problems.
Import OpenVPN
My OVPN imports , but when trying to change settings it was giving a: Interface has no ip addr - Error.
Turned out to be : The WAN needs to be up & running (have ip).
Also if using TLS Key ... Check that TLS Key Usage matches the other end ... mine didn't.
I use TLS Enc + Auth on the pfS, and had to change to that on opnSense VPN's
And make sure Compression matches other end. I used "No Preference" (should match Disable compression on pfS)
-
Apparently there was an issue in the migration that prevented nested aliases from validating during migration:
https://github.com/opnsense/core/commit/e4c857f0
So here is the full sequence on top of 23.7.7:
The patch will be included in 23.7.8 onwards so no need to run the patching there!
# opnsense-patch e4c857f0
(only apply the patch once otherwise it's going to be removed again)
# pluginctl -f OPNsense.Firewall.Alias
# pluginctl -f aliases
(confirm delete of garbage entries to allow for a migration)
edit /conf/config.xml to add your pFsense <aliases/> section cleanly again -- it should go right above the last line of the file saying </opnsense>
# /usr/local/opnsense/mvc/script/run_migrations.php
Migrated OPNsense\Firewall\Alias from 0.0.0 to 1.0.1
In case there are errors please post them here. They can be seen via the following command when the migration would fail.
# opnsense-log
Cheers,
Franco
Wanted tot let you know this worked fine ;-) thanks.
-
I wish I had seen this before I started my project to convert a pfSense config file to an OPNSense config file by writing a program.
https://github.com/smccloud/pfSense-to-OPNSense-Config-File-Converter
-
Importing firewall rules
I urgently suggest you to NOT do this with your wan connected to the Internet.
I have my wan configured for dhcp, and connected to an "inside" vlan on my existing setup.
After being 100% sure your Aliases and Interface assignments are imported correctly
See here for Interface import
https://forum.opnsense.org/index.php?topic=36683.msg179463#msg179463
And make sure every interface has same assignment as on the pfS
ALL Interface assignments must match excactly across OPN and pfS configs.
Especially pay attention to the optXX assignments, as they reflect the way (time) they were created on the pfS.
When you are sure the IF's are assigned/numbered the same way.
You could import the - Restore Firewall rules section from the pfS config.
Pay attention to "NOT locking your self out" of the target OPNsense box.
Or make sure you have a console attached, and after restore run temporarily disable the OPNsense firewalling by running a : pfctl -d
And now make a firewall rule allowing you access again.
Then enable the firewall by running a : pfctl -e - Or just reboot.
I have not had time to walk through my rules yet, but at first glance tth result seems "Not bad at all ..." 8)
As a minimum do review the rules on your WAN interface, before connecting it to the internet.
And preferably review rules on all interfaces, before setting the "Box in prod".
ICMP Rules - Reports error
I noticed a red dot here -Statusbar - Top Right
(https://forum.opnsense.org/index.php?action=dlattach;topic=36683.0;attach=30750)
And when clicking on it it showed a firewall rule that had a syntax error.
(https://forum.opnsense.org/index.php?action=dlattach;topic=36683.0;attach=30748)
It turned out that ALL my imported ICMP rules had syntax error.
Solution was easy : Edit the rule , and press "Save"
But i had to do it for every ICMP rule i had made ... Well an easy fix.
It is probably a good idea to edit every rule, and just press save.
Based on a few diffs , it seems like the rules are "rewritten" to fit the OPNsense syntax, when editing, and just presing save.
Ie. All my "Disabled rules" har a strange state , where they were "Geyed out, the the text", but still had color on the icon all the way to the left ... "That should be black" - Editing the rule fixed that, and so did a select & disable.
-
As far as I can tell Mega's issue in interface mismatch and reset is the newer VLAN layout in pfSense which is e.g. em1.444 vs. the compatible one em1_vlan444.
There's no way short of doing a search and replace to fix this properly, because the system will miss that this is a VLAN interface and behave oddly afterwards as well (even with lock being set).
Cheers,
Franco
-
As far as I can tell Mega's issue in interface mismatch and reset is the newer VLAN layout in pfSense which is e.g. em1.444 vs. the compatible one em1_vlan444.
There's no way short of doing a search and replace to fix this properly, because the system will miss that this is a VLAN interface and behave oddly afterwards as well (even with lock being set).
Cheers,
Franco
I have addressed the "Incompatibility here", according to Franco's description ... Thnx again 8)
https://forum.opnsense.org/index.php?topic=36683.msg179265#msg179265
Hopefully the adaptation of the pfS config file , will produce valid vlan names for OPNsense
-
Import Nat/Portforwarding
Importing NAT/Portforwarding seems straight forward.
Just select Restore -> Restore Area : NAT
Ps
I did set OPNsense Outboud NAT mode to match the mode i use in pfS , before the import.
But the mode seems to be included in the pfS config.
PPs:
My NAT is super simple... Two portforward rules , and Outound Nat
So this import might not be tested very well.
-
I have convertes succesfully 2 out of my 3 boxes to opnsense.
However there is still one that is located in a completely different country , anyone knows a good way to set up wireguard site 2 site with PFsense and Opnsense?
-
Just had a "Weird one" ...
All my ICMP rules had a syntax error.
Now i found out that the "Dot" in "Top right" is NOT supposed to be RED :-X :-\
That means there's an error.
Clicking the red dot revealed this:
(https://forum.opnsense.org/index.php?action=dlattach;topic=36683.0;attach=30752)
Solution was "easy" : Edit the ICMP rule , and press save.
But i had to do it for every ICMP rule i had... Well easy fix.
Now there's no more "Red - DOT"