Messages

I was able to do this although not being an expert the procedure was not perfect in the sense that some space would not grow and I cant really explain why.

What I did was the following.
I had a 10GB disk. I wanted to grow it to 20GB. In KVM/Your choice of Hypervisor I increased the disk allocation to 20GB with OPNsense turned off.

Now after booting OPNsense I typed "gpart show"
This displayed 2 areas for me. An MBR section (vtbd0) and a BSD device (vtbd0s1) both 10GB in size.
Under vtbd0 I had one partition labelled '1' which is 10GB right before the free space.
Similarly under the BSD section I had one partition labelled '1' right before the free space.

I could also see 10 GB of free unallocated space in each.

First I typed

"gpart resize -i 1 -s 19G vtbd0"

When I tried 20G it said there was not enough space and I did not know how to extend it to the last GB so I just used 19G. In my case I was using a dynamic disk so the hypervisor only grows the disk as used anyway. I imagine you could spend more time here getting every last byte but I did not need to.

This grew the MBR section to 19G. The -i 1 signifies the partition number. I wanted partition 1 to increase. the -s 19G is the size to grow to.

I then typed

"gpart resize -i 1 vtbd0s1"

This grew the BSD section to fill the space I had allocated within the MBR (I think).

'gpart show' now showed both sections grown to 19GB.

I then typed 'df -h' to list my mountpoints and the current size (not grown yet).

I then wanted the specific mount point of my choosing to take up the new space.

"growfs /dev/ufs/OPNsense"

This grew the partition. i got some warnings but all seemed fine (would recommend you have a backup obviously).

Then 'df -h' now showed disk was bigger. However for some reason I only got a 18GB as the size listed by df -h.

I could not explain this discrepancy, however everything seemed to be working.

I then rebooted into single user mode and did an fsck /dev/ufs/OPNsense and let it run. It didnt find any issue.

I rebooted OPNsense into normal mode and it seemed to be fine, however as I mentioned it displays I have a partition of 18GB despite growing it to 19GB and allocating 20GB.

So the procedure was possible and I dont have any issues, all is working normally and I did get extra space but somehow couldnt allocate all the space I wanted and lost 1GB and 1GB again during the procedure. This is no doubt due to my ignorance of the perfect settings to type when performing the procedure.

In terms of stability and functionality all seems totally fine, no errors, no problems, rebooted multiple times without an issue. As I mentioned its a dynamically expanding virtual disk so Im not really worried that the last 2GB couldnt be grown, and probably I can just grow it again if I need but seems like the procedure would need a bit of tweaking before its perfect. This was what I managed on my own just reading the man pages for freebsd.

Pete

Your solution was acceptable, I am not able to determine if Sensei will continue to ask for the record or not as I added the answer to domain overrides in unbound which bypasses my DNS blocker I was seeing the requests on.

The DNS override section is configured as follows:

Host Overrides

Host    Domain    Type    Value    Description    
251    0.0.224.in-addr.arpa    A    224.0.0.251    ptrmdns    
mdns    mcast.net    A    Alias for 251.0.0.224.in-addr.arpa    mdnsptrrecord    

The second line is an alias.

As the server itself now knows an answer to the DNS request
251.0.0.224.in-addr.arpa ----> 224.0.0.251 ----> mdns.mcast.net

I do not see this query hit my other DNS server. So it is resolved. I am not able to determine if Sensei continues to ask as I mentioned as unbound does not log the queries against it (unbound can only be accessed by the firewall and the DNS server and other PC's on my network are prohibited to query it so logging is unneeded in my use case).

Kind regards
Peter

It's not a false answer, it's the official FQDN for this multicast address set in RFC 6762. But your choice ...

A fair point. I was unaware this was the official stance. I checked the wiki you posted and it did not mention this and this was the first time you had stated this.

I dont agree with the logic of providing a false answer to a DNS query. Why would I tell a computer that an IP can be reached on a DNS name of mdns.mcast.net. This is a public DNS name.

You can ask any question you like to a DNS server, it does not mean the question is valid or makes sense to ask.

My preference will be to disable Sensei asking this question. The question is not meaningful. For now I will disable real time DNS enrichment as there is not an alternative. Will revisit in the future if this changes.

Pete

Why don't you make your DNS server answer for that PTR record?

My network range is 192.168.2.0/24. All computers have a 192.168.2.x address on my network.

What machine name and answer is valid to the request for the ptr record of 251.0.0.224.in-addr.arpa on my network? I do not know the answer.

It seems like a broadcast request. Why would 1 single machine name be the answer to a broadcast? What exactly am I 'fixing' by providing a false reply? I already block this record on the DNS server, Sensei simply keeps requesting that record continuously. I have no idea what answer it wants, or if providing an answer - even a fake one - would make any difference to that.

Kind regards
Peter

@allebone, thanks for the reply.

@sy, I guess @allebone wants multicast communication to be excluded from realtime local domain queries. I think we should provide this as an option.

Hello,

Yes I am asking to exclude mdns only, as it is querying my dns server for a record I cannot provide an answer to.

Hello,

Thank you for your reply.

I have checked and yes I do have this option, are you suggesting I disable it?

Kind regards
Peter

Sensei continuously asks my DNS server to resolve 251.0.0.224.in-addr.arpa every 20-30 seconds.


What answer is Sensei expecting to this? I ended up adding 251.0.0.224.in-addr.arpa to the denylist but it still queries. If I stop Sensei from running the queries stop so I know for sure its Sensei.

I dont understand what answer it is expecting to receive to this query and it fills the logs of my DNS filter. Can I prevent Sensei from querying this record continuously? I dont really need sensei to be mdns aware as i have all my DNS records correctly published normally on my DNS server.

Kind regards
Peter

Thank you :)

This is very interesting. Thank you. This information is very valuable to me and appreciate the time you took to reply.

Can I also ask what tcpflags   PA (I have a P in my packet).

Kind regards
Peter

Thank you for your reply. I do not understand why this is an answer. Can you help me to understand what you are pointing out and in addition how you know the example packet I posted relates to this? I am not able to do this on my own.

Kind regards,
Peter

System: Settings: Logging

Hi,

Unsure why sometimes the firewall logs show that packets are blocked when I have a rule that allows these packets outbound (443 is allowed outbound from any source on my network, and indeed i can browse https sites :) )

I have attached a screenshot of an example. I have a rule that allows 443 outbound and am 100% sure it is working as this only happens very infrequently that I see these packets. I dont detect anything not working and can browse sites on https anytime without issue so am not clear what it is blocking.

Here is the detail of 1 of the packets in the below screenshot:

__timestamp__   Nov 25 09:27:05
ack   3986972122
action   [block]
anchorname   
datalen   1395
dir   [in]
dst   13.107.42.12
dstport   443
ecn   
id   0
interface   vtnet1
interface_name   lan
ipflags   DF
label   Default block LAN to any rule
length   1435
offset   0
proto   6
protoname   tcp
reason   match
rid   da7b834f8d727a70d52f48cc6b111da3
ridentifier   0
rulenr   324
seq   3973428692:3973430087
src   192.168.2.53
srcport   56922
subrulenr   
tcpflags   PA
tcpopts   
tos   0x0
ttl   64
urp   4096
version   4

Yup good luck thats the best way to learn, slowly add more and more as you find a need to do so and remove things that you thought you needed but found that actually you did not when experimenting on your home network :)

Yes the domain override is telling the unbound server where to go and query for that specific domain, in this case the domain is a ptr reverse lookup domain, so without the override unbound will simply query whatever is configured in your forwarders section or use root hints if you query that way, both which cannot provide an authoritative answer to your query of an internal record.

Edit : if you set your forwarder or dns server for opnsense to be pihole then it would work without an override but I would advise against such a setup as the firewall should be able to resolve dns without pihole working to ensure services that rely on dns (sensei etc) to function in the event of an outage with pihole or error and also because blocking these services from accessing domains by way of a filter may have undesirable effects. You should trust the firewall to not need filtering or alternatively use a product you do trust. The firewall should be able to sort itself out essentially without relying on a piece of internal equipment to be working perfectly.

Just fyi on my network I have opnsense unbound set to use 1.1.1.1 as a forwarder and an internal DNS server that client nodes use and provides dns filtering - that dns server gets its answers from unbound running on the opnsense. On opnsense I redirect any queries on port 53 using outbound nat to the internal dns server except for the source ip of the firewall and the ip of the internal dns server, so their queries do not get looped back. This means anyone changing their dns server to either the opnsense firewall or any external IP are silently having their requests directed back to the internal dns filter server. An alert is then flagged on my opnsense. Currently I have found it n my network a roku tv and an ip camera that had hardcoded dns servers trigger this alert. I also block outbound traffic to known doh servers. Currently the only app that has triggered an alert to try bypass dns filtering by querying hardcoded external doh servers is the app 'tiktok' which I then subsequently blocked all of bytedances servers on the dns level so the apps do not function.

Final thing I will say is that I dont agree with the general consensus that using 1.1.1 or some other public dns is a privacy concern if your alternative is to use toot hints with unbound. Or what I mean is using root hints does not solve the privacy concern imo. If you obscure your DNS and then turn right around to your ISP and say 'please connect me to this IP' then you have not solved the privacy issue and have simple made your dns queries take longer. For this reason I dont use root hints and use 1.1.1.1 which is very fast.

To obscure your traffic a vpn provider who does not log would be required but I dont know how to ensure that a vpn provider is actually doing what they say. For this reason I believe its better to simply know all you do on the internet is logged and there is no real privacy unless you are illegally compromising servers on the internet and proxying your traffic through them and clearing all the logs automatically yourself and somehow making sure you dint get caught. I dont see any solution as really viable in the real world so it seems better to me to simply understand that public internet = public space. People are allowed to look at what you do in public when you walk to the shops. Same on the internet.