Hi, I am pfsense user, but i kept having problems so I decided to give opnsense try. I span up an opnsense firewall vm, spent the last few days on learning it and today I come across this "Automatically generated rules". Which stopped me dead on my tracks and not going to switch to opnsense anymore.
However, i still would like to know why? Its mind boggling to why you would force firewall rules on people who want to use your product?
And to the people who will say dont use it, thats not the point. The point is you spend so much effort and time to make opnsense a contender on the firewall market and shot yourself on the foot by forcing your rules on people.
Is there a way to disable this non-sense? Automatically generated rules.
To add irony to insult: we've inherited automatic rules from pfSense where you couldn't even even see them. We've fixed that problem in 2019 (19.7) and added reference links to the settings pages where available to be able to disable them one by one. For newer components we've also stopped automatic rules as is the case with IPsec connections and OpenVPN instances.
I understand your concern but it's fundamentally misplaced with your conclusion in mind.
Cheers,
Franco
Hi Franco, to start with thank you for taking the time to respond. Also, I am not insulting opnsense no. I have been using pfsense for years and always had a heart to migrate to opnsense, but never got round to it. But now i decided to take the plunge, its disappointing to see somethings are forced in opnsense.
Also, I am suprised that is also the case in Pfsense, altough i did not see it in practise. I just dont understand why i can not control what firewall rules added, why do you need those automaticaly genereated ones? this adds to the complexity of having to cater for the automatically added ones when you configure your rules.
As an example:
I was testing inter vlans comms, i added a rule to vlan 200 to allow ping but not to vlan100, so in practise you would expect vlan200 to be able to ping vlan100, but vlan100 should not be able to ping back vlan200. however to my suprise both pcs can ping each other. So i assume the reason ping is working is due to this auto rule?
Therefore, when PING is working you dont know if that firewall rule is kicking in, you could use logs for that i guess but you see the irony in here? anyone who takes on a project like opnsense will have at least some basic IT skills. so making some rules mandotory is confusing and uncessary.
And to the million dollar question: even if they were in pfsense, why did they keep them in opnsense? what is the purpose of this auto generated rules anyways? I am baffled to why they are there forcing the firewall to only work certain way?
Did i understand you correctly that you can disable this rules? even if its one by one? if thats the case great, can you please point me to the link where it shows how to disable these rules?
TIA
Ping only works for the initial LAN interface (incoming to firewall) where there is a "pass all" rule. All other interfaces created do not have this shortcuts.
> And to the million dollar question
Because people have relied upon them for years, even a decade and suddenly removing them would have left everyone stranded. Couple with with the fact that pfSense tried to say OPNsense is just a buggy pfSense it would have discouraged even more people in the beginning. ;)
As I said we worked on this topic in the scope that we could. Made improvements and removed some of those automatic rules. But the ping issue you describe is not possible to my knowledge for anything but the default LAN interface. And that's not even an automatic rule -- it's explicit and can be removed from the rules screen just like in the other project.
Cheers,
Franco
Hi Franco, i feel like i am missing something obvious here.
Is there a way to remove/disable the auto generated rules?
Strictly talking about "automatic rules" in the rules listing you can expand "Automatically generated rules" bit to the right and the ones that have a GUI switch will show with a magnifying glass beside it leading to the page where the setting can be turned off. Some automatic rules may not have a GUI option or directly depend on turning off a service like DHCP in order to get rid of them.. but these are really basic rules that ensure functionality.
Talking about your VLAN ping issue I'd suggest you redo your test consciously, because as I said none of the automatic rules will allow ping from interface to interface in the default except if you repurpose the LAN interface where these rules exists: "Default allow LAN [IPv6] to any rule".
It's imperative that you don't mix up these two things going forward. I don't think you will have much beef with either standard behaviour described here.
Cheers,
Franco
Here is a quick and dirty diag to explain. (//) Any idea on how is this ping from VLAN190 working?
It might not be going over the firewall at all. You can do a packet capture on the OPNsense to see if that is true.
I'd still doubt the firewall will even let this through. Try to ping the firewall IP from the VLAN on the right?
Cheers,
Franco
I can ping the IP Address of opnsense, also if i do trace route to the destination IP it tells me it uses the opnsense as a gateway as .253 is the test opnsense. This is why i was baffled before. I first thought this was due to the auto rules, but from your reaction it seems thats not the case and something else is happening?
New to opnsense trying to figure out how to do capture. If i can get it to work will post it too.
Sorry for butting in but maybe this can help:
When you install the OPNsense the first time, it will create two interfaces by default:
- WAN
- LAN
There will two predefined rules in "Firewall: Rules: LAN" after installation which allow:
"IPv4" proto "ANY" from Source "LAN net" to Destination "ANY"
"IPv6" proto "ANY" from Source "LAN net" to Destination "ANY"
If you create any additional interfaces (for example OPT1), there won't be any automatic predefined rules in "Firewall: Rules: OPT1".
- If you ping from a LAN client to an OPT1 client, the packet is received by the LAN interface. The matching rule in "Firewall: Rules: LAN" - "IPv4 proto ANY Source LAN net to Destination ANY" is found, and the ping will be delivered directly to its destination. Due to the statefulness of the firewall, the reply is allowed back from OPT1 to LAN.
- If you ping from an OPT1 client to a LAN client, the packet is received by the OPT1 interface. No matching rule in "Firewall: Rules: OPT1" is found, and the Firewall will drop the packet with a "Default Deny - State Violation".
Hi Monveich, thank you for chiming in. Hopefully we will get to the bottom of this.
The issue is both of this interfaces are VLANS. VLAN 160 is opt7 and VLAN 190 is opt10. So according to what you said above i should NOT be able to ping in between the VLANS in from both sides, but the results is different.
I also noticed something else. you said only the (original) LAN should have the auto rules, but not any opt interface you create afterwards. i just checked, and all the extra VLANs i created and somehow all have the auto rule already on them. Any idea who that might have happened? and how to disable/delete them if possible?
Can you post an output of:
Firewall: Diagnostics: Statistics: rules - filter rules
Maybe that way it's easier to see whats wrong with the opt7 and opt10 interface rules.
Since the output might be pretty long, use the code
code
> somehow all have the auto rule already on them
Man, I just explained this multiple times. Automatic rules are not the default allow all rule from the default LAN configuration. And automatic rules are not automatic allow all rules. Please do not mix those up.
Can you just do the capture or turn on rule logging to confirm that packets flow through the firewall or not. Since we only have evidence that blocking doesn't work the likeliest outcome is traffic is not going through the firewall.
Cheers,
Franco
In response to Monviech: Filter rules:
I could not find a way to export it, instead i attached a screeshot for the firewall rules. Does this help?
In response to Franco:
I think i got it now what you mean they are different. The LAN contains two rules from the get go whereas any new interface you create wont have this two rules, but all the interfaces will have the auto rule.
although i think i got it, i am still not clear on why my ping works, anyone got a clue what is happening?
TIa
I mean... you could have just copy pasted them... it's text.
filter rules
@0 scrub on vmx0 all fragment reassemble
@1 scrub on vlan0.100 all fragment reassemble
@2 scrub on vlan0.110 all fragment reassemble
evaluations
:
244699
packets
:
38898
bytes
:
0
states
:
0
inserted
:
uid 0 pid 79126
state_creations
:
0
@3 scrub on vlan0.120 all fragment reassemble
@4 scrub on vlan0.130 all fragment reassemble
@5 scrub on vlan0.140 all fragment reassemble
@6 scrub on vlan0.150 all fragment reassemble
@7 scrub on vlan0.160 all fragment reassemble
@8 scrub on vlan0.170 all fragment reassemble
@9 scrub on vlan0.180 all fragment reassemble
@10 scrub on vlan0.190 all fragment reassemble
@11 scrub on vlan0.200 all fragment reassemble
@12 scrub on vlan0.210 all fragment reassemble
@13 scrub on vlan0.220 all fragment reassemble
@14 scrub on vlan0.230 all fragment reassemble
@15 scrub on vlan0.240 all fragment reassemble
@16 scrub on vlan0.250 all fragment reassemble
@17 scrub on vlan0.260 all fragment reassemble
@18 scrub on vlan0.270 all fragment reassemble
@19 scrub on vlan0.280 all fragment reassemble
@20 scrub on vlan0.290 all fragment reassemble
@21 scrub on vlan0.300 all fragment reassemble
@22 scrub on vmx1 all fragment reassemble
@23 scrub on ovpnc1 all fragment reassemble
@24 scrub on ovpnc4 all fragment reassemble
@25 scrub on ovpnc3 all fragment reassemble
@26 scrub on ovpnc2 all fragment reassemble
@0 block drop in log on ! ovpnc1 inet from 10.8.3.0/24 to any
@1 block drop in log on ! ovpnc3 inet from 10.8.3.0/24 to any
@2 block drop in log on ! vmx0 inet from 10.10.95.0/24 to any
@3 block drop in log inet from <__automatic_cc423130_0:26> to any
@4 block drop in log on ! vlan0.100 inet from 10.0.1.0/24 to any
@5 block drop in log on ! vlan0.110 inet from 10.10.10.0/24 to any
@6 block drop in log on ! vlan0.120 inet from 10.10.20.0/24 to any
@7 block drop in log on ! vlan0.130 inet from 10.10.30.253 to any
@8 block drop in log on ! vlan0.140 inet from 10.10.40.0/24 to any
@9 block drop in log on ! vlan0.150 inet from 10.10.50.0/24 to any
@10 block drop in log on ! vlan0.160 inet from 10.10.60.0/24 to any
@11 block drop in log on ! vlan0.170 inet from 10.10.70.0/24 to any
@12 block drop in log on ! vlan0.180 inet from 10.10.80.0/24 to any
@13 block drop in log on ! vlan0.190 inet from 10.10.90.0/24 to any
@14 block drop in log on ! vlan0.200 inet from 10.20.0.0/24 to any
@15 block drop in log on ! vlan0.210 inet from 10.20.10.0/24 to any
@16 block drop in log on ! vlan0.220 inet from 10.20.20.0/24 to any
@17 block drop in log on ! vlan0.230 inet from 10.20.30.0/24 to any
@18 block drop in log on ! vlan0.240 inet from 10.20.40.0/24 to any
@19 block drop in log on ! vlan0.250 inet from 10.20.50.0/24 to any
@20 block drop in log on ! vlan0.260 inet from 10.20.60.0/24 to any
@21 block drop in log on ! vlan0.270 inet from 10.20.70.0/24 to any
@22 block drop in log on ! vlan0.280 inet from 10.20.80.0/24 to any
@23 block drop in log on ! vlan0.290 inet from 10.20.90.0/24 to any
@24 block drop in log on ! vlan0.300 inet from 10.30.0.0/24 to any
@25 block drop in log on ! vmx1 inet from 10.0.0.0/24 to any
@26 block drop in log on ! ovpnc4 inet from 10.8.0.0/24 to any
@27 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
@28 block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"
@29 pass in log quick inet6 proto ipv6-icmp all icmp6-type unreach keep state label "1d245529367b2e34eeaff16086aeafe9"
@30 pass in log quick inet6 proto ipv6-icmp all icmp6-type toobig keep state label "1d245529367b2e34eeaff16086aeafe9"
@31 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state label "1d245529367b2e34eeaff16086aeafe9"
@32 pass in log quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state label "1d245529367b2e34eeaff16086aeafe9"
@33 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@34 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type echoreq keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@35 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@36 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type echorep keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@37 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@38 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type routersol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@39 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@40 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type routeradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@41 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@42 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type neighbrsol keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@43 pass out log quick inet6 proto ipv6-icmp from (self:2) to fe80::/10 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@44 pass out log quick inet6 proto ipv6-icmp from (self:2) to ff02::/16 icmp6-type neighbradv keep state label "acdbb900b50d8fb4ae21ddfdc609ecf8"
@45 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
@46 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state label "42e9d787749713a849d8e92432efdfaa"
@47 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
@48 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state label "42e9d787749713a849d8e92432efdfaa"
@49 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
@50 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state label "42e9d787749713a849d8e92432efdfaa"
@51 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
@52 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state label "42e9d787749713a849d8e92432efdfaa"
@53 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
@54 pass in log quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state label "42e9d787749713a849d8e92432efdfaa"
@55 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state label "8752fca75c6be992847ea984161bd3f1"
@56 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state label "8752fca75c6be992847ea984161bd3f1"
@57 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state label "8752fca75c6be992847ea984161bd3f1"
@58 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state label "8752fca75c6be992847ea984161bd3f1"
@59 pass in log quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state label "8752fca75c6be992847ea984161bd3f1"
@60 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state label "71dd196398b3f1da265dbd9dcad00e70"
@61 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state label "71dd196398b3f1da265dbd9dcad00e70"
@62 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
@63 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state label "71dd196398b3f1da265dbd9dcad00e70"
@64 pass in log quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state label "71dd196398b3f1da265dbd9dcad00e70"
@65 block drop in log quick inet proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@66 block drop in log quick inet proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@67 block drop in log quick inet6 proto tcp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@68 block drop in log quick inet6 proto udp from any port = 0 to any label "7b5bdc64d7ae74be1932f6764a591da5"
@69 block drop in log quick inet proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@70 block drop in log quick inet proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@71 block drop in log quick inet6 proto tcp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@72 block drop in log quick inet6 proto udp from any to any port = 0 label "ae69f581dc429e3484a65f8ecd63baa5"
@73 pass log quick inet6 proto carp from any to ff02::12 keep state label "3b14fa6f8072123bf7a59d2fd29cbec3"
@74 pass log quick inet proto carp from any to 224.0.0.18 keep state label "8203357325e6f08a501a6dec36b19112"
@75 block drop in log quick proto tcp from <sshlockout:0> to (self:26) port = ssh label "669143f420c3ab4118bcb0bf4b5fd823"
@76 block drop in log quick proto tcp from <sshlockout:0> to (self:26) port = https label "6baefc2a9cf2536834c092a51134a45c"
@77 block drop in log quick from <virusprot:0> to any label "8e367e2f9944d93137ae56d788c5d5e1"
@78 pass in log quick on vmx0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "5168be2cca1e130b1ef2ac18161356a8"
@79 pass in log quick on vmx0 proto udp from any port = bootpc to (self:26) port = bootps keep state label "0b032d1bab91fc97e4a7faf03a7f17c3"
@80 pass out log quick on vmx0 proto udp from (self:26) port = bootps to any port = bootpc keep state label "5039e43005a9aa50eb032af274cc9aad"
@81 pass in log quick on vmx0 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
@82 pass in log quick on vmx0 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "fef3d333d96a8d3558956de1fffc61cc"
@83 pass in log quick on vmx0 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "d2bd536587a9f5680c1f850b2d346839"
@84 pass in log quick on vmx0 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "3420206ced96c01ef73fbc4ac9deb745"
@85 pass in log quick on vmx0 inet6 proto udp from fe80::/10 to (self:2) port = dhcpv6-client keep state label "0fd202708c326aebbe44ab710b6d3652"
@86 pass out log quick on vmx0 inet6 proto udp from (self:2) port = dhcpv6-server to fe80::/10 keep state label "83f6c28de8efae9b444094e4a5bf898c"
@87 pass in log quick on vmx1 proto udp from any port = bootps to any port = bootpc keep state label "f994f615e00b8be0042263f86c79913f"
@88 pass out log quick on vmx1 proto udp from any port = bootpc to any port = bootps keep state label "5cf7ab808da1fcbca1ddb9ba9b46b669"
@89 block drop in log quick on vmx1 inet from <bogons:10> to any label "b7cd97a164650b538506fb551a0369e7"
@90 block drop in log quick on vmx1 inet6 from <bogonsv6:76> to any label "f140a48ddade668b9d6f5259669a1d5c"
@91 block drop in log quick on vmx1 inet from 10.0.0.0/8 to any label "1eb94a38e58994641aff378c21d5984f"
@92 block drop in log quick on vmx1 inet from 127.0.0.0/8 to any label "1eb94a38e58994641aff378c21d5984f"
@93 block drop in log quick on vmx1 inet from 100.64.0.0/10 to any label "1eb94a38e58994641aff378c21d5984f"
@94 block drop in log quick on vmx1 inet from 172.16.0.0/12 to any label "1eb94a38e58994641aff378c21d5984f"
@95 block drop in log quick on vmx1 inet from 192.168.0.0/16 to any label "1eb94a38e58994641aff378c21d5984f"
@96 block drop in log quick on vmx1 inet6 from fc00::/7 to any label "45afd72424c84d011c07957569151480"
@97 pass in quick on lo0 all no state label "7535c94082e72e2207679aadb26afd92"
@98 pass out log all flags S/SA keep state allow-opts label "fae559338f65e11c53669fc3642c93c2"
@99 pass in log quick on vmx0 proto tcp from any to (self:26) port = http flags S/SA keep state label "fc644ddefed1dc33844f7142cb756947"
@100 pass in log quick on vmx0 proto tcp from any to (self:26) port = https flags S/SA keep state label "fc644ddefed1dc33844f7142cb756947"
@101 pass out log route-to (vmx1 10.0.0.254) inet from (vmx1:1) to ! (vmx1:network:1) flags S/SA keep state allow-opts label "d70281046ba3974025350c5d8da4f133"
@102 pass out log route-to (ovpnc1 10.8.3.1) inet from (ovpnc1:*) to ! (ovpnc1:network:*) flags S/SA keep state allow-opts label "a164ec9a5d3709134b7b5e44ba923a1c"
@103 pass out log route-to (ovpnc4 10.8.0.1) inet from (ovpnc4:*) to ! (ovpnc4:network:*) flags S/SA keep state allow-opts label "6d88f54aa9de84ef076a457714eeb76f"
@104 pass out log route-to (ovpnc3 10.8.3.1) inet from (ovpnc3:*) to ! (ovpnc3:network:*) flags S/SA keep state allow-opts label "23993926179df54d470f26fbd1f31db5"
@105 pass in quick on vmx0 inet from (vmx0:network:1) to any flags S/SA keep state label "06dffb3e75f145a93fec873d7a40bcab"
@106 pass in quick on vmx0 inet6 from (vmx0:network:*) to any flags S/SA keep state label "18e5297df4bdcfe5310a1ff8fff0513f"
@107 pass in quick on vmx0 inet6 from fe80::/10 to any flags S/SA keep state label "18e5297df4bdcfe5310a1ff8fff0513f"
@108 pass in log quick on vlan0.100 inet proto tcp from (vlan0.100:network:1) to any flags S/SA keep state label "4a1ae6f37e26333f95f6ab5ede4aec74"
@109 pass in log quick on vlan0.100 inet proto udp from (vlan0.100:network:1) to any keep state label "4a1ae6f37e26333f95f6ab5ede4aec74"
@110 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_DNS_Server:1> port = domain flags S/SA keep state label "a8edaca1d7de7c58ad92856fcba9a634"
@111 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_DNS_Server:1> port = domain keep state label "a8edaca1d7de7c58ad92856fcba9a634"
@112 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_NTP_Server:0> port = ntp flags S/SA keep state label "6e4c11415d0b524c0fb500998ac4d814"
@113 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_NTP_Server:0> port = ntp keep state label "6e4c11415d0b524c0fb500998ac4d814"
@114 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32400 flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@115 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = ssdp flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@116 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32410 flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@117 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32412 flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@118 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32413 flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@119 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32414 flags S/SA keep state label "bfc71631e10051c599bd217509098a2c"
@120 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32400 keep state label "bfc71631e10051c599bd217509098a2c"
@121 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = ssdp keep state label "bfc71631e10051c599bd217509098a2c"
@122 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32410 keep state label "bfc71631e10051c599bd217509098a2c"
@123 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32412 keep state label "bfc71631e10051c599bd217509098a2c"
@124 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32413 keep state label "bfc71631e10051c599bd217509098a2c"
@125 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_PLEX_Server:0> port = 32414 keep state label "bfc71631e10051c599bd217509098a2c"
@126 block drop in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to <Aliase_ALL_Int_Subnets:3> label "f01942ec52167b5d1d80bb1385ff0526"
@127 block drop in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to <Aliase_ALL_Int_Subnets:3> label "f01942ec52167b5d1d80bb1385ff0526"
@128 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = netbios-ns label "d67d8e39143a2b775b1f0bd0acd42d77"
@129 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = netbios-dgm label "d67d8e39143a2b775b1f0bd0acd42d77"
@130 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = netbios-ssn label "d67d8e39143a2b775b1f0bd0acd42d77"
@131 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = epmap label "d67d8e39143a2b775b1f0bd0acd42d77"
@132 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = telnet label "d67d8e39143a2b775b1f0bd0acd42d77"
@133 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = snmp label "d67d8e39143a2b775b1f0bd0acd42d77"
@134 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = snmptrap label "d67d8e39143a2b775b1f0bd0acd42d77"
@135 block return in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any port = tftp label "d67d8e39143a2b775b1f0bd0acd42d77"
@136 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = netbios-ns label "d67d8e39143a2b775b1f0bd0acd42d77"
@137 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = netbios-dgm label "d67d8e39143a2b775b1f0bd0acd42d77"
@138 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = netbios-ssn label "d67d8e39143a2b775b1f0bd0acd42d77"
@139 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = epmap label "d67d8e39143a2b775b1f0bd0acd42d77"
@140 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = telnet label "d67d8e39143a2b775b1f0bd0acd42d77"
@141 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = snmp label "d67d8e39143a2b775b1f0bd0acd42d77"
@142 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = snmptrap label "d67d8e39143a2b775b1f0bd0acd42d77"
@143 block return in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any port = tftp label "d67d8e39143a2b775b1f0bd0acd42d77"
@144 pass in log quick on vlan0.110 inet proto tcp from (vlan0.110:network:1) to any flags S/SA keep state label "f88edceafb900272eeec4ad509568953"
@145 pass in log quick on vlan0.110 inet proto udp from (vlan0.110:network:1) to any keep state label "f88edceafb900272eeec4ad509568953"
@146 pass in log quick on vlan0.110 inet proto icmp from (vlan0.110:network:1) to any keep state label "6a42b74c5f094f53780344a5fa9386b7"
@147 pass in quick on vlan0.190 inet all flags S/SA keep state label "33bdb49cf3ed631fee86930d96e7e374"
I don't see any allow rules related to vlan0.160. So pinging from vlan0.160 to vlan0.190 shouldn't work.
There's an explicit drop rule:
@10 block drop in log on ! vlan0.160 inet from 10.10.60.0/24 to any
I see this rule:
@147 pass in quick on vlan0.190 inet all flags S/SA keep state label "33bdb49cf3ed631fee86930d96e7e374"
It allows vlan0.190 to send any traffic to any destination, including vlan0.160. So ping works.
thank you.
thats baffling than.
to be 100% sure the traffic is being routed through the opnsense. I shut it down and the second the opnsense was down the ping stopped. So we can safely say the ping is traversing trough the opnsense.
But the baffling question remains of how this is posisble?
I just showed you how it is possible.
There are default block rules without "quick", so they match last and block all traffic in those vlans that don't have an allow rule. They're the default deny rules:
@10 block drop in log on ! vlan0.160 inet from 10.10.60.0/24 to any
@13 block drop in log on ! vlan0.190 inet from 10.10.90.0/24 to any
And there has to be a user generated "allow rule" in the GUI with "quick", so it matches before the block rules:
@147 pass in quick on vlan0.190 inet all flags S/SA keep state label "33bdb49cf3ed631fee86930d96e7e374"
Due to this rule, any client in vlan0.190 can ping anywhere.
The rule has to be either in:
Firewall: Rules: vlan0.190
or
Firewall: Rules: Floating
Can you list your interface definitions? What do you have assigned to WAN and LAN? What is the parent interface for each VLAN?
Quote from: Monviech on September 26, 2023, 01:46:04 PM
I just showed you how it is possible.
There are default block rules without "quick", so they match last and block all traffic in those vlans that don't have an allow rule. They're the default deny rules:
@10 block drop in log on ! vlan0.160 inet from 10.10.60.0/24 to any
@13 block drop in log on ! vlan0.190 inet from 10.10.90.0/24 to any
And there has to be a user generated "allow rule" in the GUI with "quick", so it matches before the block rules:
@147 pass in quick on vlan0.190 inet all flags S/SA keep state label "33bdb49cf3ed631fee86930d96e7e374"
Due to this rule, any client in vlan0.190 can ping anywhere.
The rule has to be either in:
Firewall: Rules: vlan0.190
or
Firewall: Rules: Floating
Hi Monviech, yes you explained how VLAN190 can ping VLAN 160, but not how VLAN160 can ping VLAN190. Thats what is baffling. I have a rule in VLAN190 so it can ping VLAN 160 i understand that. But i have NO rules on either the floating page nor VLAN 160. So its NOT clear how VLAN160 can ping VLAN 190? there is NO rule to allow it? AM i missing something here? Is the rules not supposed to work like that? if you have no rule defined all blocked?
Please see the attached pic, it shows VLAN160, VLAN190, their rules and the floating rules. no where i can see a config which would explain why VLAN160 can ping VLAN190?
Quote from: CJ on September 26, 2023, 04:01:45 PM
Can you list your interface definitions? What do you have assigned to WAN and LAN? What is the parent interface for each VLAN?
WAN is using vmx1 and LAN is using vmx0. All the VLANs are attached to the LAN interface vmx0.
please see the attached:
Can you tell me if in Firewall: Settings: Advanced
"Disable Firewall" - "Disable all packet filtering" is enabled?
Quote from: Monviech on September 26, 2023, 05:06:12 PM
Can you tell me if in Firewall: Settings: Advanced
"Disable Firewall" - "Disable all packet filtering" is enabled?
No its looks like disabled:
Can you please take a couple screenshots with the auto generated rules expanded in each vlan ?
My only guess left would be that the hosts can find themselves directly via layer 2. Maybe the vlan setup isnt working right.
The arp table would be interesting.
Interfaces: Diagnostics: ARP Table
Also the arp tables and mac address of both clients so it can be seen if they prefer a direct route.
EDIT: Thats really grasping at straws though, I'm not that firm at layer 2. So I give up here at this point.
Quote from: Monviech on September 26, 2023, 07:05:08 PM
My only guess left would be that the hosts can find themselves directly via layer 2. Maybe the vlan setup isnt working right.
The arp table would be interesting.
Interfaces: Diagnostics: ARP Table
Also the arp tables and mac address of both clients so it can be seen if they prefer a direct route.
EDIT: Thats really grasping at straws though, I'm not that firm at layer 2. So I give up here at this point.
Thank you all for the support and effort. Windows will not even attempt to contact the other PC directly over layer 2. layer 2 is only mac add. As they are communicating over IP they need to use layer 3.
In any case to test this thoery i moved the firewall and the PCs all to different esxi hosts but that did not make a difference. So we can rule out an esxi issue. Also if that was the case and PCs communicating directly you would expect for the ping to continue when i shutdown the opnsense vm. but they stop as soon as i shutdown the vm.
at this stage i think you are right i am also giving up.
Are you are running opnsense virtualized?
I think you have your Virtual Host configured incorrectly to support vlans. Either that or your external smart switch is incorrectly set up. The symptoms you are describing is exactly what happens when vlans are not configured correctly on the external switch and they are getting combined. This is external to opnsense.
Quote from: IsaacFL on September 26, 2023, 10:30:25 PM
Are you are running opnsense virtualized?
I think you have your Virtual Host configured incorrectly to support vlans. Either that or your external smart switch is incorrectly set up. The symptoms you are describing is exactly what happens when vlans are not configured correctly on the external switch and they are getting combined. This is external to opnsense.
Yes its virtulised. When i first read your input in the first instance it did seem to make sense. But as i thought it through i thought otherwise. Let me explain why i think its not the case.
Suppose i misconfigured ESXi and/or the switch. opnsense should still block the ping when it passes through it. we know it passes through it because if i shut it down both vms stop being able to ping each other. Therefore althought its always a possiility due to misconfiguration i think its unlikely?
Did you create the VLANs in OPNsense? It looks like it. How is the parent interface passed into the VM? If this is all virtual, the common approach is to define all VLANs on ESXi and pass a matching number of virtual interfaces into the firewall VM. Possibly alle your VLANs are not really VLANs at all?
Quote from: newjohn on September 26, 2023, 11:11:09 PM
Therefore althought its always a possiility due to misconfiguration i think its unlikely?
Only one statement CAN be true: You discovered a major security bug/flaw in PF and/or OPNSense OR you have issues in your virtual environment, network topology, firewall config etc.
Because your issue is quite simple, allowing ICMP echo request / reply between two interfaces, I suggest you create a more simple setup to debug and report on with a basic and easy to understand topology and ruleset. Your virtual so deploying an extra VM should be an easy task for such a potential high impact security bug/flaw (not only impacting OPNSense).
So a default setup with LAN + WAN and after that creating an extra OPT interface to introduce a second LAN segment. Keep EVERYTHING default just configure the interface IP's and DO NOTHING else. To make it super transparent, don't mess with VLAN interfaces YET. If you need just create static mappings between your OPNSense interfaces and your existing VLANs by creating VLAN port groups in vSphere VDS or Open vSwitch on KVM or whatever you are using.
Now if you can confirm that in this DEFAULT setup you can ping from a host in the OPT network to a host in the LAN network it's time to get scared. The other way around, ping from _DEFAULT_ LAN network to OPT network, will work as explained in previous posts.
I couldn't bother to plow through your ruleset (too much noise), but I did check your statement at a system here with ten's of raw interfaces, bridges and VLANs (both LAGG and non-LAGG) and couldn't reproduce it on any.
From my perspective a misconfiguration is VERY likely, but I'm eager to hear about the issues you find in the above "test" setup.
Quote from: newjohn on September 26, 2023, 11:11:09 PM
Quote from: IsaacFL on September 26, 2023, 10:30:25 PM
Are you are running opnsense virtualized?
I think you have your Virtual Host configured incorrectly to support vlans. Either that or your external smart switch is incorrectly set up. The symptoms you are describing is exactly what happens when vlans are not configured correctly on the external switch and they are getting combined. This is external to opnsense.
Yes its virtulised. When i first read your input in the first instance it did seem to make sense. But as i thought it through i thought otherwise. Let me explain why i think its not the case.
Suppose i misconfigured ESXi and/or the switch. opnsense should still block the ping when it passes through it. we know it passes through it because if i shut it down both vms stop being able to ping each other. Therefore althought its always a possiility due to misconfiguration i think its unlikely?
No, you definitely have the virtualization misconfigured. Basically you have cross connected multiple layer 3 ip subnets onto the same layer 2 Ethernet segment. Virtually or via your external switch.
Quote from: netnut on September 27, 2023, 12:01:03 AM
Quote from: newjohn on September 26, 2023, 11:11:09 PM
Therefore althought its always a possiility due to misconfiguration i think its unlikely?
Only one statement CAN be true: You discovered a major security bug/flaw in PF and/or OPNSense OR you have issues in your virtual environment, network topology, firewall config etc.
Because your issue is quite simple, allowing ICMP echo request / reply between two interfaces, I suggest you create a more simple setup to debug and report on with a basic and easy to understand topology and ruleset. Your virtual so deploying an extra VM should be an easy task for such a potential high impact security bug/flaw (not only impacting OPNSense).
So a default setup with LAN + WAN and after that creating an extra OPT interface to introduce a second LAN segment. Keep EVERYTHING default just configure the interface IP's and DO NOTHING else. To make it super transparent, don't mess with VLAN interfaces YET. If you need just create static mappings between your OPNSense interfaces and your existing VLANs by creating VLAN port groups in vSphere VDS or Open vSwitch on KVM or whatever you are using.
Now if you can confirm that in this DEFAULT setup you can ping from a host in the OPT network to a host in the LAN network it's time to get scared. The other way around, ping from _DEFAULT_ LAN network to OPT network, will work as explained in previous posts.
I couldn't bother to plow through your ruleset (too much noise), but I did check your statement at a system here with ten's of raw interfaces, bridges and VLANs (both LAGG and non-LAGG) and couldn't reproduce it on any.
From my perspective a misconfiguration is VERY likely, but I'm eager to hear about the issues you find in the above "test" setup.
I agree it would be good to get to the bottom of this.
Really busy day at work so have not had the chance to do the test you asked yet. But I did some thinkering and think I figured it out. I need another pair of eyes to confirm if this is the case.
VLAN190 has permit all rule
VLAN160 has NO rule
If i start the ping from vlan190 to vlan160 (vlan190 has permit all statement) it works ok (as expected).
If i reboot both PCs and the firewall so there is no established connection as far as the firewall is concerned and try to ping from vlan160 (which does not have any firewall statements), it fails (as expected).
So far the firewall does what its expected.
However, the point it gets unexpected is as follows:
After the reboot all connections states is cleared. so if i start the ping from vlan160 to vlan190, it fails as expected.
However, I noticed the second i start pinging from vlan190 back to vlan160 naturally vlan190 works ok, but because the firewall now has established an open state between this two IP Addresses it allows vlan160 to ping back vlan190.
if i stop the ping from vlan190 and reset the state table the ping stops which supports my findings?
Whats is your take on this please?
Please see the attached screenshot.
Quote from: Patrick M. Hausen on September 26, 2023, 11:48:35 PM
Did you create the VLANs in OPNsense? It looks like it. How is the parent interface passed into the VM? If this is all virtual, the common approach is to define all VLANs on ESXi and pass a matching number of virtual interfaces into the firewall VM. Possibly alle your VLANs are not really VLANs at all?
How is the parent interface passed into the VM?
I use esxi and its virtual interface, not passed through.
If this is all virtual, the common approach is to define all VLANs on ESXi and pass a matching number of virtual interfaces into the firewall VM.
I think thats would not be posisble as ESXi have limit of 10 NICs max per VM. so if you want to have more than 10 vlans which i do that approach wont be posssible.
Possibly alle your VLANs are not really VLANs at all?
The same Infrastructure works ok with pfsense, but pfsense has a bug i hate hence the adventure to opnsense :)
Did you configure a vswitch, and added a port group with the VLAN ID of 4095? And connected this Portgroup with 4095 as E1000 or vmxnet3 nic to the Opnsense so its a trunk port (accepting all vlan tags)?
And then created port groups on that vswitch with all additional vlan IDs 100-190... you have and connected those to your VMs?
I only configure Opnsenses on ESXi with PCIe passthrough when they need VLANs, I tested it and they don't have problems with states as described above. I can't replicate it there. I also run a few opnsenses that have one vnic per portgroup for different networks. It also doesn't happen there.
So, if anybody has a setup that uses portgroups with VLANs...
Quote from: Monviech on September 28, 2023, 08:01:40 AM
Did you configure a vswitch, and added a port group with the VLAN ID of 4095? And connected this Portgroup with 4095 as E1000 or vmxnet3 nic to the Opnsense so its a trunk port (accepting all vlan tags)?
And then created port groups on that vswitch with all additional vlan IDs 100-190... you have and connected those to your VMs?
I only configure Opnsenses on ESXi with PCIe passthrough when they need VLANs, I tested it and they don't have problems with states as described above. I can't replicate it there. I also run a few opnsenses that have one vnic per portgroup for different networks. It also doesn't happen there.
So, if anybody has a setup that uses portgroups with VLANs...
Did you configure a vswitch, and added a port group with the VLAN ID of 4095?
Yes.And connected this Portgroup with 4095 as E1000 or vmxnet3 nic to the Opnsense so its a trunk port (accepting all vlan tags)?
Yes.And then created port groups on that vswitch with all additional vlan IDs 100-190... you have and connected those to your VMs?
Yes.=======================
However, as some people raised concern about the setup being virtual and possibly causing the issue I dug up a mini PC did fresh baremetal opnsense install and run the tests, to my suprise i got the same results.
So virtual or baremetal does not make a difference, as soon as you start pinging from vlan190 to vlan160, vlan160 can start to ping vlan190 back.
Just so it does not get lost in the conversation, vlan160 only gets response to pings if i start pinging from vlan190. If i start the ping on vlan160 the pings does not work, It only get response when i start the ping from vlan190.
Therefore anyone wants to test this scenario suggest you clear the firewall states or better reboot if possible and start pinging from the vlan that has NO config and watch the result give it 10-15 seconds and
only than start pinging from the VLAN has the permit statement.
as for your tests, i am suprised in a sense that you did not get the same results. In your setup do both vlans have rules on them configured? perhaps this behaviour only happens when there is no config on one of the vlans?
Just for information purpose:
Iam using proxmox and multiple VLAN interfaces configured like this:
LAGG Interface0 -> VLAN0 -> Bridge NOT vLan aware
To
LAGG Interface0 -> VLANx -> Bridge NOT vLan aware
Single Interface -> Bridge VLAN Aware (iam thinking to change that)
And for OPNsense I added all VLAN bridges to the VM and do not make any VLAN inside opnsense (except pppoe/wan which I might to change today)
With this setup, i had another issue (multiple RAs reaching a windows client, due to Realtek driver behavior in windows*) but I can't confirm the issue the OP has.
* configured a VLAN ID in the driver but because the port was a trunk port with a default VLAN, some packages from the not configured default VLAN where still reaching my PC. The same was not visible under macOS or Linux ...)
Here's my final test with all tcpdumps and all pf rules attached:
Opnsense:
hn5 10.16.1.254/24 - PF rules: none, only the "Automatically generated rules"
hn7 10.0.0.254/24 - PF rules: @418 pass in quick on hn7 inet proto icmp all keep state label "420257620b64c28d62b138a1f0bb8329"
VM1:
Ubuntu 20.04 LTS - 10.0.0.203
VM2:
Windows 10 - 10.16.1.254
Packet Captures:
Here you can see that the Windows VM2 already sends pings to the Ubuntu VM1 since a while (id 1, seq 256... id 1, seq 257) but there is no ICMP echo reply with the same ID.
Then I start a ping from the Ubuntu VM1 to the Windows VM2, which works (ICMP echo request, id 13... ICMP echo reply id 13)
But, there are still no ICMP echo replys with the id 1 after the ICMP echo request and echo reply with id 13 start.
Opnsense hn5:
root@opn01:~ # tcpdump -i hn5 proto ICMP and host 10.16.1.101 or proto ICMP and host 10.0.0.203 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on hn5, link-type EN10MB (Ethernet), capture size 262144 bytes
09:19:51.937928 IP 10.16.1.101 > 10.0.0.203: ICMP echo request, id 1, seq 256, length 40
09:19:56.931815 IP 10.16.1.101 > 10.0.0.203: ICMP echo request, id 1, seq 257, length 40
09:19:57.017238 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 1, length 64
09:19:57.017385 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 1, length 64
09:19:57.017807 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 1, length 64
09:19:58.018376 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 2, length 64
09:19:58.018559 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 2, length 64
09:19:58.019178 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 2, length 64
OPNsense hn7:
root@opn01:~ # tcpdump -i hn7 proto ICMP and host 10.16.1.101 or proto ICMP and host 10.0.0.203
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on hn7, link-type EN10MB (Ethernet), capture size 262144 bytes
09:19:57.017180 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 1, length 64
09:19:57.017841 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 1, length 64
09:19:57.017927 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 1, length 64
09:19:58.018352 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 2, length 64
09:19:58.019209 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 2, length 64
09:19:58.019321 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 2, length 64
VM1:
administrator@vm1:~$ sudo tcpdump -i any proto ICMP and host 10.16.1.101 or proto ICMP and host 10.0.0.203 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
09:19:57.044829 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 1, length 64
09:19:57.045816 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 1, length 64
09:19:58.045987 IP 10.0.0.203 > 10.16.1.101: ICMP echo request, id 13, seq 2, length 64
09:19:58.047248 IP 10.16.1.101 > 10.0.0.203: ICMP echo reply, id 13, seq 2, length 64
You can see at every step that only ICMP echo request id 13 and ICMP echo reply id 13 comes through, and ICMP echo request id 1 gets filtered out by the firewall, even if states are established.
I can't replicate the behavior. Maybe somebody else can? I can't spend more time on this.
Until we see a packet trace this discussion is not very useful.
This is not an opnsense issue.
It is an issue with the external network misconfigured on either the external switch or on his virtualization.
Would probably be better if the OP went to a support group on how to setup vlans on his smart switch as he said he saw it on his bare metal install.
Quote from: newjohn on September 28, 2023, 12:55:44 AM
Whats is your take on this please?
Please see the attached screenshot.
I explained my take extensivily in previous post:
- Go back to the drawing board
- Simplify your setup
- From here proof your initial statement that "Automatically generated rules" allows traffic that isn't expected to be allowed (ICMP or whatever.)
So a default install, 1 WAN, 1 LAN and 1 OPT interface, no VLAN's, no manual config except for 3 interface IP configs. If in this setup you can proof your statement many people are willing to look into your issue. Should take you less time than posting screenshoits of state reset buttons.
For me, I'm too old to look into virtualised infra's with VLAN trunk ports without a detailed low level design and not knowing if basic network skills are in place.
Below is what I tested so far and to be honest I am concerned with the results.
I realise some users spent some valuable time on this and I appriciate it, however i think for the benefit of everyone who is using opnsense I believe we need to get to the bottom of this.
If my tests are not flowed somehow, and i dont see how thats posisble as its simple ping test, when all baremetals now, than we are looking at a bug or a bigger issue.
I know some will dismiss this without even looking into it, but I am concerned. Something is not right with opnsense.
To remove any possibility that this is vmware issue I used two win11 baremetal PCs for testing and also moved the opnsense to baremetal pc.
The current test setup:
PC-S1 - Source PC - win 11 (baremetal) - VLAN140
PC-S2 - Source PC - Ubuntu (VM) - VLAN210
PC-D1 - Destination PC win 11(baremetal) - VLAN190
Opnsense (baremetal)
Test results:
VLAN140 disabled all the rules. (NO rules on floating or on vlan140 - all disabled)
Test results -
Started pinging from - PC-S1 - Ping did NOT work -however as soon as i started pinging back form PC-D1 both source and destination can ping each other.
Than i though maybe this is a windows issue, so i tested with an ubuntu (vm) and the same results.
following that, i thought maybe because there are some config on VLAN140 causing the issue even though its disabled. So moved the test to VLAN210 which has no config at all. And again the resutls are the same.
Some of you requested more basic testing, but i already (I know not the brightest move) switched to opnsense baremetal thinking this is happening due to the FW virtual issue and i wont get the same problem on baremetal, so its not easy to remove all the config again as the household will probably not be happy. Therefore i did the testing while also trying to keep the home internet working.
Are you still using LAN as the parent of all of the VLANs?
Quote from: CJ on September 30, 2023, 02:32:46 PM
Are you still using LAN as the parent of all of the VLANs?
Yes.
However, I come across this question couple of times now. Is that not how we supposed to do it?
Quote from: newjohn on September 30, 2023, 02:39:12 PM
Quote from: CJ on September 30, 2023, 02:32:46 PM
Are you still using LAN as the parent of all of the VLANs?
Yes.
However, I come across this question couple of times now. Is that not how we supposed to do it?
The default LAN rule allows all. I know there is a recommendation not to mix tagged and untagged traffic on the same interface but I forget the exact details for why. If you change your VLANs to use something other than LAN as the parent, you may see things work as you expect.
That all said, why not try testing with separate interfaces and no VLANs. That way you eliminate all of the variables of incorrect VLAN setup, etc. It will help isolate if the problem is truly OPNSense or not.
Quote from: CJ on September 30, 2023, 03:01:56 PM
Quote from: newjohn on September 30, 2023, 02:39:12 PM
Quote from: CJ on September 30, 2023, 02:32:46 PM
Are you still using LAN as the parent of all of the VLANs?
Yes.
However, I come across this question couple of times now. Is that not how we supposed to do it?
The default LAN rule allows all. I know there is a recommendation not to mix tagged and untagged traffic on the same interface but I forget the exact details for why. If you change your VLANs to use something other than LAN as the parent, you may see things work as you expect.
That all said, why not try testing with separate interfaces and no VLANs. That way you eliminate all of the variables of incorrect VLAN setup, etc. It will help isolate if the problem is truly OPNSense or not.
Ahh now I understand. I will dig out some 4 ports NIC cards. Ok for this i need to swap from 2 port NIC to 4 port NIC so i can use the 3rd port as VLANs parent interface.
So the new setup will look like this:
Port 1 = WAN
Port 2 = LAN
Port 3 = Parent Interface for all VLANS. - This needs to be Trunk/Tagged Ports for all VLANS?
TIA
Quote from: CJ on September 30, 2023, 03:01:56 PM
I know there is a recommendation not to mix tagged and untagged traffic on the same interface but I forget the exact details for why.
Because in many cases you get weird (and hard to debug) behavior depending on the underlying infrastructure. Take the example below, nothing to do with OPNSense itself, but if you plug your firewall into this (trunk) port you get three different results (mind the minor differences). This is "just" configuration, I'm not even opening the can-of-worms of your $5 vlan aware "smart-switch"....
VLAN RED = 100
VLAN BLUE = 200
# Trunk
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan members [ RED BLUE ];
}
}
}
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan members [ RED BLUE ];
native-vlan-id 100;
}
}
}
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan members [ BLUE ];
native-vlan-id 100;
}
}
}
Quote from: netnut on September 28, 2023, 04:13:27 PM
Quote from: newjohn on September 28, 2023, 12:55:44 AM
Whats is your take on this please?
Please see the attached screenshot.
I explained my take extensivily in previous post:
- Go back to the drawing board
- Simplify your setup
- From here proof your initial statement that "Automatically generated rules" allows traffic that isn't expected to be allowed (ICMP or whatever.)
So a default install, 1 WAN, 1 LAN and 1 OPT interface, no VLAN's, no manual config except for 3 interface IP configs. If in this setup you can proof your statement many people are willing to look into your issue. Should take you less time than posting screenshoits of state reset buttons.
For me, I'm too old to look into virtualised infra's with VLAN trunk ports without a detailed low level design and not knowing if basic network skills are in place.
As they say in the famous movie "
Houston we have a problem"I kept drilling down as I kept getting replies to my pings.
In the end to remove any middleman issues and confirm once and for all
this is opnsense issue, I removed the switch, the virtualization and went baremetal.
Testing env: Two baremetal win11 PCs.
4 port fresly installed Opnsense.
PCs: Both baremetal:PC1 - connected directly to LAN port on the opnsense firewall = IP add 10.1.1.1
PC2 - connected directly to OPT1 port on the opnsense firewall = IP add 10.2.2.2
Opnsense:Fresh install, the only config I added was to enable OPT1 and assing IP Address 10.2.2.254.
Nothing else changed.Test result, I still get a response to the ping.Steps:
Issued the ping command form PC2, at first dont get a response
However, as soon as you issue the ping command on PC1, both PCs can ping each other.
Please see the screenshots.
Note: The system due to the size does not allow me to attach all the screenshots in one go. I will add them one by one.
Image addition:
Image addition:
Image addition:
Image addition:
Image addition:
I have actually confirmed this behavior in OPNsense 23.7 now since the test methology was specified properly.
I live booted a opnsense VM (latest ISO from the website), put 3 virtual private switches on it in hyper-v, configured lan and opt 1 with the TUI Wizard in the shell.
Booted up two Ubuntu 22.04, one in LAN and the other in OPT1, and yes I could ping between the VMs.
Ping from OPT1 to LAN was possible after the first ping from LAN to OPT1. I have looked into pfctl and there were only allow rules for LAN loaded.
VM1 192.168.2.3 <----> OPT1 192.168.2.1/24 OPNSENSE 192.168.1.1/24 LAN <----> 192.168.1.101 VM2
Will post packet captures soon here as edit:
- Both ICMP echo request and ICMP echo reply have the same ID. There is no new ID generated, which must means it all happens in the same stateful session.
PACKET CAPTURE:
root@pc07:/home/administrator# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:00:c9:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.101/24 metric 100 brd 192.168.1.255 scope global dynamic eth0
valid_lft 4933sec preferred_lft 4933sec
inet6 fe80::215:5dff:fe00:c976/64 scope link
valid_lft forever preferred_lft forever
root@pc07:/home/administrator# ping 192.168.2.3
PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data.
64 bytes from 192.168.2.3: icmp_seq=1 ttl=63 time=0.653 ms
64 bytes from 192.168.2.3: icmp_seq=2 ttl=63 time=0.602 ms
64 bytes from 192.168.2.3: icmp_seq=3 ttl=63 time=0.666 ms
64 bytes from 192.168.2.3: icmp_seq=4 ttl=63 time=1.01 ms
64 bytes from 192.168.2.3: icmp_seq=5 ttl=63 time=0.673 ms
64 bytes from 192.168.2.3: icmp_seq=6 ttl=63 time=1.38 ms
^C
--- 192.168.2.3 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5085ms
rtt min/avg/max/mdev = 0.602/0.829/1.377/0.278 ms
root@pc07:/home/administrator# tcpdump -i any proto ICMP -n
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
08:32:25.001798 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 1, length 64
08:32:25.002434 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 1, length 64
08:32:26.012412 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 5, length 64
08:32:26.012453 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 5, length 64
08:32:26.022547 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 2, length 64
08:32:26.023114 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 2, length 64
08:32:27.036417 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 6, length 64
08:32:27.036456 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 6, length 64
08:32:27.046642 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 3, length 64
08:32:27.047275 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 3, length 64
08:32:28.060402 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 7, length 64
08:32:28.060440 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 7, length 64
08:32:28.070543 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 4, length 64
08:32:28.071518 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 4, length 64
08:32:29.071726 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 5, length 64
08:32:29.072363 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 5, length 64
08:32:29.084260 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 8, length 64
08:32:29.084279 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 8, length 64
08:32:30.086534 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 6, length 64
08:32:30.087880 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 6, length 64
08:32:30.108482 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 9, length 64
08:32:30.108501 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 9, length 64
08:32:31.132446 eth0 In IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 10, length 64
08:32:31.132479 eth0 Out IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 10, length 64
root@pc08:/home/administrator# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:00:c9:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.3/24 metric 100 brd 192.168.2.255 scope global dynamic eth0
valid_lft 5305sec preferred_lft 5305sec
inet6 fe80::215:5dff:fe00:c977/64 scope link
valid_lft forever preferred_lft forever
root@pc08:/home/administrator# ping 192.168.1.101
PING 192.168.1.101 (192.168.1.101) 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=5 ttl=63 time=0.736 ms
64 bytes from 192.168.1.101: icmp_seq=6 ttl=63 time=0.777 ms
64 bytes from 192.168.1.101: icmp_seq=7 ttl=63 time=0.713 ms
64 bytes from 192.168.1.101: icmp_seq=8 ttl=63 time=0.500 ms
64 bytes from 192.168.1.101: icmp_seq=9 ttl=63 time=0.706 ms
64 bytes from 192.168.1.101: icmp_seq=10 ttl=63 time=0.717 ms
^C
--- 192.168.1.101 ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 9211ms
rtt min/avg/max/mdev = 0.500/0.691/0.777/0.088 ms
root@pc08:/home/administrator# tcpdump -i any proto ICMP
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
08:32:21.920856 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 1, length 64
08:32:22.940118 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 2, length 64
08:32:23.964114 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 3, length 64
08:32:24.988127 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 4, length 64
08:32:25.002180 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 1, length 64
08:32:25.002212 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 1, length 64
08:32:26.012097 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 5, length 64
08:32:26.012802 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 5, length 64
08:32:26.022956 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 2, length 64
08:32:26.022974 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 2, length 64
08:32:27.036133 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 6, length 64
08:32:27.036881 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 6, length 64
08:32:27.047092 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 3, length 64
08:32:27.047108 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 3, length 64
08:32:28.060130 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 7, length 64
08:32:28.060810 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 7, length 64
08:32:28.071295 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 4, length 64
08:32:28.071311 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 4, length 64
08:32:29.072085 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo request, id 8, seq 5, length 64
08:32:29.072121 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo reply, id 8, seq 5, length 64
08:32:29.084096 eth0 Out IP 192.168.2.3 > 192.168.1.101: ICMP echo request, id 8, seq 8, length 64
08:32:29.084573 eth0 In IP 192.168.1.101 > 192.168.2.3: ICMP echo reply, id 8, seq 8, length 64
I couldn't replicate that behavior with a TCP session though. If I create a TCP SSH session from LAN to OPT1, I CAN'T SSH back from OPT1 to LAN.
So there is no real security risk here right now.
What I know is that ICMP doesn't have states. It's a stateless protocol. So what we are seeing might be... normal?
Quote from: newjohn on October 01, 2023, 08:58:25 AM
As they say in the famous movie "Houston we have a problem"
I kept drilling down as I kept getting replies to my pings.
In the end to remove any middleman issues and confirm once and for all this is opnsense issue, I removed the switch, the virtualization and went baremetal.
Testing env:
Two baremetal win11 PCs.
4 port fresly installed Opnsense.
PCs: Both baremetal:
PC1 - connected directly to LAN port on the opnsense firewall = IP add 10.1.1.1
PC2 - connected directly to OPT1 port on the opnsense firewall = IP add 10.2.2.2
Opnsense:
Fresh install, the only config I added was to enable OPT1 and assing IP Address 10.2.2.254. Nothing else changed.
Test result, I still get a response to the ping.
Steps:
Issued the ping command form PC2, at first dont get a response
However, as soon as you issue the ping command on PC1, both PCs can ping each other.
Please see the screenshots.
Note: The system due to the size does not allow me to attach all the screenshots in one go. I will add them one by one.
Isn't this just ICMP hole punching? https://en.wikipedia.org/wiki/ICMP_hole_punching
The ping was correctly blocked until you opened up the return by starting from the other way. It's the whole way a lot of zero config apps work.
Quote from: CJ on October 01, 2023, 03:09:20 PM
Quote from: newjohn on October 01, 2023, 08:58:25 AM
As they say in the famous movie "Houston we have a problem"
I kept drilling down as I kept getting replies to my pings.
In the end to remove any middleman issues and confirm once and for all this is opnsense issue, I removed the switch, the virtualization and went baremetal.
Testing env:
Two baremetal win11 PCs.
4 port fresly installed Opnsense.
PCs: Both baremetal:
PC1 - connected directly to LAN port on the opnsense firewall = IP add 10.1.1.1
PC2 - connected directly to OPT1 port on the opnsense firewall = IP add 10.2.2.2
Opnsense:
Fresh install, the only config I added was to enable OPT1 and assing IP Address 10.2.2.254. Nothing else changed.
Test result, I still get a response to the ping.
Steps:
Issued the ping command form PC2, at first dont get a response
However, as soon as you issue the ping command on PC1, both PCs can ping each other.
Please see the screenshots.
Note: The system due to the size does not allow me to attach all the screenshots in one go. I will add them one by one.
Isn't this just ICMP hole punching? https://en.wikipedia.org/wiki/ICMP_hole_punching
The ping was correctly blocked until you opened up the return by starting from the other way. It's the whole way a lot of zero config apps work.
Thank you for the input. Although I understand and agree in a sense on what you saying, although not 100% sure I know the answer to that.
If someone with definite knowledge can confirm its not a security issue I am happy with that although at the beginning I thought it was the auto generated rules was the cause.
Also in the link you shared it shows that an attacker can pretend to be replying to your ping request in return causing the remote PC to respond and we have an open connection ready to be exploited. But i guess thats a conversation for another day.
I guess the question now is is this a security issue or is it expected as you and
Monviech mentioned.
I dont think its a security risk because you can simply mitigate it by not allowing the ICMP protocol if you don't need it in your network.
If or of not ICMP (v4) is a security issue is widely discussed.
I would be more worried about some smart home devices that connect directly to a cloud and they can get into your network through the stateful TCP return connection.
Quote from: Monviech on October 01, 2023, 05:08:51 PM
I dont think its a security risk because you can simply mitigate it by not allowing the ICMP protocol if you don't need it in your network.
Nein, Nein, Nein!!! Please don't be "security aware" by disabling ICMP, there are many good reasons why this protocol exists next to UDP/TCP. You allow ICMP in general or filtering it down to _at_ least Destination Unreachable, Time Exceeded and Parameter Problem and NDP. There are things like PMTU discovery and IPv6 to name a few.
Quote
If or of not ICMP (v4) is a security issue is widely discussed.
If a packet filter allows whatever packet that it _should_ have filter by policy, you have a security bug. You could technically tunnel out traffic with ICMP reply packets which don't have a fixed data length. You can use Suricata to detect these kind of anomalies. But back to OP...
You should see a "no response found!" message in your packet capture when pinging "back" from the OPT interface to LAN, which you probably don't.
What if you re-run the test but now first go to:
INTERFACES: SETTINGS and check the "Hardware CRC Disable hardware checksum offload" box, while you there you could possible check also the two other ones AND disable VLAN Hardware Filtering. You might want to reboot, just to be really sure...
Quote from: netnut on October 02, 2023, 12:34:11 AM
Quote from: Monviech on October 01, 2023, 05:08:51 PM
I dont think its a security risk because you can simply mitigate it by not allowing the ICMP protocol if you don't need it in your network.
Nein, Nein, Nein!!! Please don't be "security aware" by disabling ICMP, there are many good reasons why this protocol exists next to UDP/TCP. You allow ICMP in general or filtering it down to _at_ least Destination Unreachable, Time Exceeded and Parameter Problem and NDP. There are things like PMTU discovery and IPv6 to name a few.
You misinterpreted what I said. Maybe I should have added an "but I don't believe in it." at the end. I generally allow most ICMP and ICMPv6 types because they are quite essential to have the network running well. You're right about that.
Thank you everyone for your input and support.
I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls. But two firewalls behaving in the same way kind of support the idea that this is normal.
In the end i like what I am seeing on Opnsense, so I am sticking with it even through the title says othwerwise :)
Quote from: newjohn on October 02, 2023, 11:18:43 AM
I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls.
Well, that's rather funny don't you think, looking at your initial statement ;)
Quote
But two firewalls behaving in the same way kind of support the idea that this is normal.
That's because the underlaying issue is still there (it's _not_ normal), did you test with hardware offloading disabled as mentioned in my last post ?
Quote from: netnut on October 02, 2023, 01:55:26 PM
Quote from: newjohn on October 02, 2023, 11:18:43 AM
I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls.
Well, that's rather funny don't you think, looking at your initial statement ;)
Quote
But two firewalls behaving in the same way kind of support the idea that this is normal.
That's because the underlaying issue is still there (it's _not_ normal), did you test with hardware offloading disabled as mentioned in my last post ?
===============
Yeap, it is funny :). I originally thought the auto generated rules were the cause, but since they are not, its not relevant anymore.
As for testing with the hardware offloading disabled, I think this is disabled by default, so any tests carried out had this disabled by default.
Also, if this is not normal and confirmed by more than one user, isnt this a priority issue?
I am now back again sitting on the fence on whether we should be concerned about this or not?
Quote from: newjohn on October 03, 2023, 12:08:39 PM
Also, if this is not normal and confirmed by more than one user, isnt this a priority issue?
Because it isn't an OPNSense issue, which you already discovered after installing an alternative fw.
Your problem is visible in the Wireshark capture screenshot where you can see _all_ your ICMP echo/reply's with "id=0x0001". There are no states in ICMP, but to decide/relate which reply matches which echo is normally based on this unique id. So your pings from the OPT network should have an other id than the initial ping from LAN.
For some reason there isn't much creativity in the uniqueness of this id, so all ICMP echo/reply will match. Could be a client NIC, driver, bad or inferior hardware (Realtek?), funky IP stack, etc
As a new OPNsense user, and recently retired developer/system architect, I fully thank the OPNsense crew for putting the bare minimum of protection in place so we can then move on to adjust/create/demolish what we want from that point. Random new users have no idea what to do first and the generated rules gets us setup and then we can screw ourselves up all we want, but that is not your fault.
Again, thank you!
Hi Team,
Adding my problems to here, that every opnsense action such as route , interface or rules edits gives gui/ping loss and suspecting that automatically rules are plays to deny the traffic. Therefore post pfctl -d cmd execute that allow to another changes.
Is any one help here that why every action on opnsense trigger pf enables and loss the gui/pings drops. Is there way to delete the automatically rules from opnsense.
I'm using opnsense as vm on kvm.
Thanks,
Athisesan
Quote from: athisesanr on March 16, 2024, 08:07:26 AM
Adding my problems to here...
Don't do that, if you have an question or issue open a topic in a relevant sub forum
Quote
...and suspecting that automatically rules are plays to deny the traffic...
Suspecting ? This is a five page topic explaining that whichever "problem" you (can) have with OPNsense it's NOT RELATED to "Automatically Generated Rules". So what makes you think or suspect these rules do ?
Besides an (industry standard) _last_ match deny any/any rule _nothing_ is blocked in this ruleset. These rules are there to help you to give you at least an initial reasonable firewall default. Ok, it's also blocking all traffic on port 0, which shouldn't happen anyway (again to help you). They're even nicely commented.
Make it your mantra: Automatically generated rules aren't my problem! You could even hum in "Wolf of Wallstreet" style while repeating this!
Quote
I'm using opnsense as vm on kvm.
Wild guess (99,9% sure), check your (virtual) topology & configuration.
Quote from: athisesanr on March 16, 2024, 08:07:26 AM
Hi Team,
Adding my problems to here, that every opnsense action such as route , interface or rules edits gives gui/ping loss and suspecting that automatically rules are plays to deny the traffic. Therefore post pfctl -d cmd execute that allow to another changes.
Is any one help here that why every action on opnsense trigger pf enables and loss the gui/pings drops. Is there way to delete the automatically rules from opnsense.
I'm using opnsense as vm on kvm.
Thanks,
Athisesan
Sounds you are connected via WAN and everytime you change rules you get kicked out cause of missing accept rule and need to pfctl again.
100% your setup, not a general issue
Quote from: newjohn on September 28, 2023, 12:55:44 AM
Quote from: netnut on September 27, 2023, 12:01:03 AM
Quote from: newjohn on September 26, 2023, 11:11:09 PM
Therefore althought its always a possiility due to misconfiguration i think its unlikely?
Only one statement CAN be true: You discovered a major security bug/flaw in PF and/or OPNSense OR you have issues in your virtual environment, network topology, firewall config etc.
Because your issue is quite simple, allowing ICMP echo request / reply between two interfaces, I suggest you create a more simple setup to debug and report on with a basic and easy to understand topology and ruleset. Your virtual so deploying an extra VM should be an easy task for such a potential high impact security bug/flaw (not only impacting OPNSense).
So a default setup with LAN + WAN and after that creating an extra OPT interface to introduce a second LAN segment. Keep EVERYTHING default just configure the interface IP's and DO NOTHING else. To make it super transparent, don't mess with VLAN interfaces YET. If you need just create static mappings between your OPNSense interfaces and your existing VLANs by creating VLAN port groups in vSphere VDS or Open vSwitch on KVM or whatever you are using.
Now if you can confirm that in this DEFAULT setup you can ping from a host in the OPT network to a host in the LAN network it's time to get scared. The other way around, ping from _DEFAULT_ LAN network to OPT network, will work as explained in previous posts.
I couldn't bother to plow through your ruleset (too much noise), but I did check your statement at a system here with ten's of raw interfaces, bridges and VLANs (both LAGG and non-LAGG) and couldn't reproduce it on any.
From my perspective a misconfiguration is VERY likely, but I'm eager to hear about the issues you find in the above "test" setup.
I agree it would be good to get to the bottom of this.
Really busy day at work so have not had the chance to do the test you asked yet. But I did some thinkering and think I figured it out. I need another pair of eyes to confirm if this is the case.
VLAN190 has permit all rule
VLAN160 has NO rule
If i start the ping from vlan190 to vlan160 (vlan190 has permit all statement) it works ok (as expected).
If i reboot both PCs and the firewall so there is no established connection as far as the firewall is concerned and try to ping from vlan160 (which does not have any firewall statements), it fails (as expected).
So far the firewall does what its expected.
However, the point it gets unexpected is as follows:
After the reboot all connections states is cleared. so if i start the ping from vlan160 to vlan190, it fails as expected.
However, I noticed the second i start pinging from vlan190 back to vlan160 naturally vlan190 works ok, but because the firewall now has established an open state between this two IP Addresses it allows vlan160 to ping back vlan190.
if i stop the ping from vlan190 and reset the state table the ping stops which supports my findings?
Whats is your take on this please?
Please see the attached screenshot.
This is exactly what happens to me in a similar scenario.
Open a console Ping -t from vlan160 to vlan 190 all fail as expected, but if I ping even once from vlan 190 to vlan160 then the ping-t flow from vlan160 to vlan 190 activates and remains active until I close the state.
An additional traffic blocking rule from vlan160 to vlan 190 is also ignored.
Analyzing the logs shows that OPNSense sees this as ping return traffic from vlan 190 to vlan160 even though it originated from vlan160. So you can't block it with any rule that references vlan160 as the source.
I wonder if it is possible to get this information to the developers as it seems like a bug or security hole
Quote from: GrilliIAL on June 18, 2024, 04:39:59 PM
I wonder if it is possible to get this information to the developers as it seems like a bug or security hole
No it isn't, as already explained in this thread. No need to cross post this...
Quote from: netnut on June 18, 2024, 07:42:44 PM
Quote from: GrilliIAL on June 18, 2024, 04:39:59 PM
I wonder if it is possible to get this information to the developers as it seems like a bug or security hole
No it isn't, as already explained in this thread. No need to cross post this...
I do not agree. There is a case where the firewall confuses ICMP traffic generated by network B to A as response traffic from A to B making any blocking rules useless. This behavior is easily reproducible and independent of particular implementations of the OPNSense machine. It probably has deeper origins in how FreeBSD's PF (Packed Filter) works, but it still represents a problem, if only because it makes PING unreliable in testing the rules, unless you know exactly what to expect.
I would add that I have worked with other firewalls including the glorious Microsoft TMG which in a similar scenario were able to manage ICMP traffic without any confusion
Quote from: GrilliIAL on June 19, 2024, 09:28:31 AM
I do not agree.
You are free to have your own opinion...
You got redirected multiple times to a thread (this particular one) that explains what's happening which has nothing to do with a "security" issue, confusion or what so ever. If you refuse to read that thread (or trying to understand the underlying cause), it's not about freedom anymore but just ignorance.