Question on ICMP Behavior

[rhkg]

Hello all,

Just getting started with OPNsense and trying to make sense of something I am seeing. I am sure this is just a misunderstanding on my part, but I would like to make sure I do not have something set up wrong.

My setup has LAN (192.168.10.*), GUEST (192.168.20.*), IoT (192.168.30.*), and NoT_CAM (192.168.40.*) networks set up with nothing other than the automatically generated rules and the allow LAN to any rules on the LAN network.

Using IoT as an example (all non-LAN networks have this behavior, though), If I first ping from IoT to LAN, I get no return, as would be expected. If I then ping from LAN to IoT I get responses, also as expected. Now, if I immediately go back to IoT and ping LAN I get responses. This is what I was not expecting to happen. If I let the connection sit idle for about 30 seconds, and try the ping from IoT to LAN again, I get no responses.

So, I think this has to do with the stateful nature of the firewall, but I am not sure. Could someone please clarify what is going on here? Also, is there any way to keep this from happening?

Thanks in advance for helping out a newbie.

[Monviech (Cedrik)]

Hey there,

here is a big thread where this is also explained a few posts in. It's a really interesting read: https://forum.opnsense.org/index.php?topic=36152.0

[CJ]

What you're seeing is just hole punching.  It's how things work.  You're calling someone so of course they're allowed to talk back to you.

https://en.wikipedia.org/wiki/ICMP_hole_punching

[meyergru]

That type of hole punching is limited to NAT, which comes not into play in the depicted scenario as I understand it.
Something like that could apply, but it does not need to because even if ICMP is stateless, the firewall could let through only ICMP reply messages when it sees an ICMP request message.

Whatever, matter-of-fact, I do not see this behavior with my setup. I can only ping in the desired direction(s).

However, I have an explicit "deny all" rule to the LOCAL_VLANS net for any but the LAN interface before the "allow all" for any (i.e. internet access). LOCAL_VLANs is the interface group for all my VLANs. One could achieve the same effect by using RFC1918 as destination.

[rhkg]

meyergru,

I tried adding an block all protocols from my other VLANS to the LAN rule set ahead of the allow LAN to any rule, and I still get the same behavior.

I guess I am going to have to back-step on my configuration and rule out my switch setup. I guess it could be causing this, but I am pretty sure I have it correct. Oh, the joys of trying of trying to figure out where the problem lies.

[meyergru]

I tried adding an block all protocols from my other VLANS to the LAN rule set ahead of the allow LAN to any rule, and I still get the same behavior.

This sentence makes me think you did not quite get it right.

The "LAN allow any" rule is a rule that is usually situated in the LAN interface rules section and it is for "in" traffic on the LAN interface. You would not put any rules originating from other interfaces above that, would you? Or if you did it that way, you would need "out" rules. However, these are uncommon and hard to understand, exspecially if you mix them with "in" rules (bad practice).

What you want is a rule that blocks incoming traffic on another VLAN interface, so you would put that rules either into that interfaces rule section or maybe in an interface group section or into floating rules, depending on how you structure your rules.

Are you sure that you understood the concepts of:

1. "in" vs. "out" rules
2. "first" vs. "last" matching
3. priorities of applicable firewall rules (see this).

Rule ordering is just one detail of the whole concept.

[rhkg]

meyergru,

Well, I thought I understood it all. I created a new interface T1_LAN to test some of this. Attached is what I have for rules on this interface right now (one with auto-generated rules shows, one without). The PrivateNetworks source is the RFC1918 private network addresses. This did not fix the situation. I am getting the same exact behavior.

I have watched so many videos and read so much on this. I though I had the in/out concept down, but obviously that might not be the case. As far as first/last match, I have that. I also think I pretty much have the priorities down.

I know this is something that I just don't understand or something that I am overlooking. I appreciate the help in looking at this and attempting to educate me on the concepts.

[meyergru]

The automatic rules look as they should and your first rule basically blocks anything, provided that the interface network is from the private networks range. If it is, you could as well say "any" as source, since this rule applies only to T1_LAN anyway. If you enable logging for that rule and ping (or in fact do anything that is not explicitely allowed in the the automatic rules) from T1_LAN to, say, your LAN, you say this gets through and it is not logged?

Also, there are no rules in the floating section? No NAT rules that accidentally apply?

[rhkg]

Ok, attached are the only NAT rules that are in place and the floating rules. In both cases, I have added nothing, just the default configuration.

I enabled logging on the T1_LAN interface block local networks rule, and when I ping from a machine on that interface, I see nothing in the log with a source IP address matching the computer that I pinged from.

Thanks again

[meyergru]

I have no idea how this should happen. The packets should not pass and that fact should be logged.

I see that igb0 is your WAN interface, which are the other ones? VLANs by any chance?

If yes:
Do you use both tagged and untagged VLANs on the same interface? FreeBSD has problems handling that.
Could it be that a switch incorrectly handles the VLANs, such that the packets do not pass OpnSense at all?

You could try to use tcpdump in order to see the packets.

[rhkg]

It really seems weird to me too.

So, I am running OPNsense bare metal on a ZimaBoard. I had heard that FreeBSD and the native RealTech NICs did not play well together, so I got a dual port PCIe Intel NIC to use. My WAN port is connected to my ISP router, so I am double NATed but my research indicated this should not be a problem. My LAN goes out to a Zyxel GS1900 switch. In testing, I have disconnected both the ISP router and the switch and the problem remain, so those are ruled out as the source.

I am using my LAN is untagged going out igb1 and my other VLANS are tagged going out the same interface. So, I went in and assigned the RealTech NICS to T1_LAN and T2_LAN, both untagged. I setup T1 LAN with a default allow any rule and a block all private networks as shown in a previous screen shot. I set up T2_LAN with a default allow any rule to mimic the LAN interface rules.  I still have the same pinging behavior between the two separate networks that are on completely different interfaces.

So, I guess I could try moving my VLANs over to one of the RealTech NICS so that all VLANS are off the same NIC, but I am not sure that will do anything given my test with T1_LAN and T2_LAN. I could get a 4 port Intel NIC and see if that helps any. As a last resort, I could get an entire different hardware platform to see if that makes any difference.

Again, thanks so much for your help. I am sure I will eventually figure it out.

[GrilliIAL]

Hello all,

Just getting started with OPNsense and trying to make sense of something I am seeing. I am sure this is just a misunderstanding on my part, but I would like to make sure I do not have something set up wrong.

My setup has LAN (192.168.10.*), GUEST (192.168.20.*), IoT (192.168.30.*), and NoT_CAM (192.168.40.*) networks set up with nothing other than the automatically generated rules and the allow LAN to any rules on the LAN network.

Using IoT as an example (all non-LAN networks have this behavior, though), If I first ping from IoT to LAN, I get no return, as would be expected. If I then ping from LAN to IoT I get responses, also as expected. Now, if I immediately go back to IoT and ping LAN I get responses. This is what I was not expecting to happen. If I let the connection sit idle for about 30 seconds, and try the ping from IoT to LAN again, I get no responses.

So, I think this has to do with the stateful nature of the firewall, but I am not sure. Could someone please clarify what is going on here? Also, is there any way to keep this from happening?

Thanks in advance for helping out a newbie.

This is exactly what happens to me in a similar scenario.
Open a console Ping -t from IoT to LAN all fail as expected, but if I ping even once from LAN to IoT then the ping-t flow from IoT to LAN activates and remains active until I close the state.
An additional traffic blocking rule from IoT to LAN is also ignored.
Analyzing the logs shows that OPNSense sees this as ping return traffic from LAN to IoT even though it originated from IoT. So you can't block it with any rule that references IoT 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

[netnut]

I wonder if it is possible to get this information to the developers as it seems like a bug or security hole

https://forum.opnsense.org/index.php?topic=36152.msg201521#msg201521