Messages

No it does not and you need not and IMHO should not assign these interfaces.

What's the reason that you think it should not be done? Only because you have 1 (or 2) more (unused) Interfaces?

I'm not sure if I understand your question completley, but a pppoe device is assigned TO an interface. Because this HowTo is about PPPoE in combination with a provider based service VLAN, the pppoe device is assigned to the VLAN interface derived from the physical WAN interface.

...

@netnut: First of all: Thank you for your fast answer!

I think you really did not understand my question completely, but may be my fault.

What I means is:

On this picture: https://forum.opnsense.org/index.php?action=dlattach;topic=21207.0;attach=14911;image

I can see that you created a VLAN named "WAN_1_FTTH" AND you assigned that VLAN to a new interface (unfortunately) also named "WAN_1_FTTH". I tried around for a very long time with the Interfaces in OPNsense, and I think that this second step of creating an Interface for the VLAN is not necessary when you want to use PPPoE.

The layered cake is a good analogy.

• You have a physical adapter called "igb4". It is not necessary to assign that physical adapter to an interface.
• Then you create a VLAN ontop of that physical adapter. It is again not necessary to assign that VLAN to an Interface.
• Then you create a Point-To-Point device (configured as PPPoE) ontop of the VLAN. Only this Point-To-Point device, you have to assign to a (new) Interface.
• OPNsense then automatically detects/creates a Gateway, which is based on that Interface, which is based on the Point-To-Point device.

And now my question is: Does it have any downsides, from a security perspective, if I dont assign/create an Interface for the igb4 (step 1) AND the VLAN (step 2)?

[5 - Assign the configured Service VLAN Interfaces]

5 - Assign the configured Service VLAN Interfaces

Login to view screenshot:

From a security perspective: Is it important to leave one Interface assignment (in your case WAN_1) on the physical and untagged network interface (in your case igb4). Maybe to block untagged traffic or so?!
Or could you also reassign your [WAN] Interface to the pppoe device?

Hello everyone,

I just connected a freshly installed OPNsense via PPPoE to the internet and watched the Firewall Live View a bit. What caught my attention are hundrets of connections to various different IPs, going from and to Port 123. Sometimes the entire page was only "123" connections and a few block inbound ones:

https://ibb.co/9YJV2yC

And indeed, on the Status page of the Network Time Service, I found a lot of these IPs again:

https://ibb.co/x6rS5mc

The configuration of the Network Time Service is completely untouched. Only those [0-3].opnsense.pool.ntp.org servers are configured with the first one being prefered.
Is there something wrong with the default settings:

https://ibb.co/HpQfP2Q

How can I make the Network Time Service only try one server and not connect to so many?

Thank you.

Now Host B can ping Host A. But to my understanding, the ICMP reply of Host A should not reach back to Host B.

pf and consequently OPNsense is a stateful firewall. It operates on "connections" or "flows", not individual packets.

So if an ICMP echo request in one direction is allowed, then automatically the matching reply is allowed, too, because anything else would not make much sense.

The very first generation of packet filters in the nineties did not track connections. So for e.g. TCP you had to unconditionally permit every packet in with the ACK flags set. In Cisco IOS that was done by the "established" keyword in access-list statements. For UDP the gaps you had to open were even wider.

Today once a client "iniside" your firewall sends a TCP SYN packet to e.g. a web server on the Internet, and that is permitted by the rules, OPNsense sets up a state for the complete TCP connection in both directions. Once the final FIN packet passes the firewall the state is deleted again. In case the connection is never correctly torn down, a timeout is applied.

Hope that clears it up a bit,
Patrick

Yes! I have read into the Firewall States and played around with them. Now it makes sense. Thank you.

Hello everyone,

i would kindly ask for help to understand some behavior of OPNsense here. (This is all for learning purposes)

I created a small network:

• Host A (192.168.10.2) - All traffic arrives at the LAN Interface in OPNsense with V_LAN tag 10
• Host B (192.168.20.2) - All traffic arrives at the LAN Interface in OPNsense with V_LAN tag 20
• Host C running OPNsense
• A managed switch, connecting all 3, taking care of the VLAN-tagging

In OPNsense I created two V-LANs "vlan0.10" and "vlan0.20", both having the LAN Interface as parent.
I assigned vlan0.10 as Interface I_10_Test and gave the Interface the static IP 192.168.10.1/24.
I assigned vlan0.20 as Interface I_20_Test and gave the Interface the static IP 192.168.20.1/24.

On Host B I tried to ping 192.168.10.2. Does not work, as expected.

Now I created a First Match Firewall rule in Interface I_20_Test:

• Action: Pass
• Direction: IN
• TCP/IP Version: IPv4
• Protocol: any
• Source: I_20_Test net
• Destination: I_10_Test net

Now Host B can ping Host A. But to my understanding, the ICMP reply of Host A should not reach back to Host B.

My first thought was that there is an automatic NAT rule, allowing the ICMP reply to reach back to Host B. So I set Firewall > NAT > Outbound > Disable outbound NAT rule generation (outbound NAT is disabled). But the ICMP replies could still reach back to Host B.

Next I tried to create a First Match rule on I_10_Test:

• Action: Block
• Direction: IN
• TCP/IP Version: IPv4
• Protocol: any
• Source: I_10_Test net
• Destination: any

But even with that, Host B can still receive the ICMP replies of Host A.

As a last try, I disabled the automatically created rule "Default allow LAN to any rule" on the LAN Interface, but still no success in blocking the ICMP replies.

Could you please help me to understand what I am doing wrong or whats my misconception here?

Thank you.

I would like to pick up on this thread https://forum.opnsense.org/index.php?topic=33436.0, which unfortunately never received an answer.
The question however seems to be still valid/relevant today. Can someone answer it (nowadays)? Or explain why not?

When checking the automatically generated rules I observed the rules for CARP.

Just for the sake of simplicity, I was  wondering if it would be possible to remove them?

The firewall rule lookup link that was expected to lead to the setting is linking to a "page not found" (firewall_virtual_ip.php). And no setting in interfaces>vip seems to match. I was wondering if someone knows which setting should have been referred to?

In pfsense you see under LAN the antilockout rule. As the default behaviour of both senses is (by and large) comparable, the remaining rules have to be present under the hood imho.

Thank you for your answer. But it does not reply to any of my questions.

The firewall that I used to swear by before I switched to OPNsense was Secure Computing's Sidewinder. There were no visible rules for ARP, NDP and the like, yet IPv4 and IPv6 worked, so there must have been rules in place permitting these.

I see. So you want to say there are little to no firewalls which don't use "hidden rules"? That would be somewhat dissapointing.

I am fine with having the fundamental working of protocols enabled automatically. I doubt anyone here is intimate enough with e.g. SLAAC to write down a working and minimal rule set to have that work from memory on a blank sheet of paper.

That is exactly what I mean. I am not fine with it. I want that nothing works and nothing is let through what I don't know. And you might deem it a bold statement, but I think that allows everything important in a homelab to still work.

Blocking IPv6 in 2024 does not make much sense to me, given that IPv6 is the Internet and IPv4 is legacy, now. But you do you  :)

That is completely wrong in my eyes. IPv6 is now over 12 years old and has little to no adoption. My ISP provides me with an exclusive, publicly routable IPv4 address, like he does to any other of its customers. I understand, that, at some point, we will need IPv6 because we run (resp. already ran) out of IPv4 addresses, but from my experience, no one needs IPv6 at the moment. You will never (in the foreseeable future) need anything more than 10.0.0.0/8 in a LAN.
And your statement "IPv6 is the Internet" is objectively false. There is not a single (useful) website, which is reachable only by a/its IPv6 address. Those few websites which are IPv6-only belong to experimenters. IPv4 is the Internet.
However, this is not the topic of this thread.

The automatic rules are there to enable services that you have enabled.

There are rules, so that CARP works.
There are the RFC4890 ICMPv6 rules.
There are rules that allow outbound traffic from the firewall itself.
There are some rules blocking invalid traffic.

I do not disagree with a single one of those rules. I also do not want to have to configure them manually.
I also do mikrotik, where you have to do those yourself, and it is not fun.

So I do disagree with the OP.

I don't think that is true, but I would like to be convinced of the opposite.
I disabled everything about IPv6, yet I have >12 rules especially about IPv6. There seem to be now dedicated services, which are using these rules.
Yet I think I know what you mean. When I enable DHCP, I get automatically generated DHCP rules. And I can get rid of them by disabling DHCP.
Yet there are many rules which dont seem to belong to any service.

Edit:
Maybe to clarify what I mean, I attach a screenshot to this post.
The rules in the upper red box, are completely useless to me, but I can't get rid of them
The rules in the lower red box allow traffic, which I don't want. But I can't get rid of them. Nor can I overrule them with my own firewall rules.

[above]

Hello everyone,

I have spent the last two weeks trying to get into OPNsense as much as I could. Reading through the manual, reading reddit/forum threads and excessively experimenting with it in my homelab. I also wrote myself a small pcap-based tool to try a bit "hacking" like VLAN-hopping etc.
So far, I had no experience with open source firewalls, but my job is... let's say: Very technical. So I think I have a solid foundation of knowledge in networking.
And since I wanted to improve my homelab, I am in search of a sophisticated open source firewall/router software. And OPNsense is a possible candidate, which I like so far. The manual is very well written, and was super helpful in the last weeks, when I stumbled upon problems. In the future I could even imagine applying as a developer (in case you need one).

What I don't understand are those "Automatically generated rules". And (dear moderator) before you delete my thread and perma ban me, please hear me out first.
Like I said, I read quite some forum posts. Also about this topic. And I understand its a pretty "disliked" topic. But I did not find any real explanation why those rules are implemented in the way they are.

franco said (Funnily to-the-day exactly one year ago), those "Automatically generated rules" are there

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. ;)

Which is a valid claim. But then why not just (in the next version of OPNsense) leave those rules there, but make them deletable? -Maybe show a similar message like the one, which appears when I try to change the listening interface for the webGUI: "Be sure that you know what you are doing by deleting these rules". This would ensure nobody is "left stranded" AND people who want to be in control of all of their firewall rules, can do so as well.

To anticipate another answer: There is no particular "Automatically generated rule", which I dislike. Me, and seemingly a lot of other people, just don't like to have to have them there. (People tend to dislike it, when something is forced on them)
For example, I try to always block IPv6 wherever and whenever I can. Now I know one can disable IPv6 via Interfaces>Settings>Allow IPv6, which adds a "Block all IPv6" "first match"-rule at the top of the firewall rules. Rendering all the other IPv6 rules useless. So having the other rules there doesn't change anything, expect maybe a little bit more CPU load. But why forcing me to have them there? And there are a lot of "useless" IPv6 rules... In my firewall of choice I will often change and adapt my firewall rules, and I will always have to skim over those IPv6 rules, wasting time.

Or another idea: Why not (at least) allow people to put their own firewall rules above the automatically generated ones? This would not solve the problem of having them there, but at least people would be in full control and able to block the automatic "pass" rules. For example, what if I would like to block the "IPv4 CARP" traffic? I have no chance to do so...  :(

If someone (of the developers or others) would like to answer, please don't hesitate to answer in a technical way of why it seems to be so hard to implement a possibility for people to get rid of the auto rules. Gladly also with a link to the affecting code lines in the OPNsense source code.

franco also said:

To add irony to insult: we've inherited automatic rules from pfSense where you couldn't even even see them.

Is this still true? Does pfSense still have the same or similar rules in place and you can't even see them?

Greetings

With "Port Forwarding"-NAT, I could make the message go to 192.186.20.2 on VLAN 20. But the Source IP Address remained as 192.168.10.2.  :(

Hello everybody,

I am playing around with OPNsense since a few days, and I would like to try to realize a local NAT between VLANs. The way I imagine it is the following:

Interfaces:
WAN: em1 - PPPoE
LAN: em0 - 192.168.1.1
VLAN_10 (Parent: em0 - Tag: 10) - 192.168.10.1/24
VLAN_20 (Parent: em0 - Tag: 20) - 192.168.20.1/24

Hosts:
192.168.10.2 (VLAN 10 - Connected via em0 to the OPNsense)
192.168.20.2 (VLAN 20 - Connected via em0 to the OPNsense)

Scenario:
192.168.10.2 sends a UDP packet to e.g. 111.111.111.111.
OPNsense shall realize that a package, which comes from a host in VLAN_10 and which is addressed to the Destination IP Address 111.111.111.111, shall be routed locally. It must never reach the WAN interface. OPNsense shall change the source IP Address of the package from 192.168.10.2 to 111.111.111.111. Shall change the destination IP Address from 111.111.111.111 to 192.168.20.2. And shall obviously change the VLAN tag from 10 to 20. Then sending it out on em0 resp. via the VLAN_20 interface.

Vice versa, if 192.168.20.2 answers to 111.111.111.111, the package shall have Source IP 111.111.111.111, destination IP 192.168.10.2 and VLAN Tag 10.

Question
How can I achieve that as simple as possible? I think I correctly created and assigned the VLANs. So far I created a firewall rule on VLAN10, which lets any traffic coming in from "VLAN_10 net" pass. This already seems to be enough that 192.168.10.2 (on VLAN 10) can talk to 192.168.20.2 (on VLAN 20).
But how do I configure the NAT'ing? Do I need Port Forward, One-to-One or Outbound? Despite playing around with all three of them one by one for a while now, I can't get it working. The manual seems to suggest that NAT reflection is exactly what I need, but it seems to change nothing of what I see in Wireshark.

Can someone help me?

Thanks in advance.