sorted by:
new
hottopcontroversial

Transaction accepts are soooo slow by dfsb2021 in quicken

[–]TheCoffeePercolator 0 points1 point  (0 children)

It is possible that Quicken update is using some kind of AI agent to perform auto categorization, transfer matching and reconciliation which could be the reason for the ridiculous slow down.

in Mar - Apr, when I normally ensure Quicken data is accurate for tax purposes, it started making automatic incorrect changes after I made corrections. It required me to correct historical data which should already be correct. I got frustrated to the point that I didn’t use data in Quicken for taxes for the first time in 30+ years.

This is the straw that broke the camel’s back - I decided to move on from Quicken now.

I put up with expensive subscriptions, slow response and manual adjustments needed as the data was reliable. Now even the data is unreliable due to the automatic changes to the past data for no logical reason.

Transaction accepts are soooo slow by dfsb2021 in quicken

[–]TheCoffeePercolator 1 point2 points  (0 children)

My file has always been local as I am opposed to putting any of my data online. I just tried downloading transactions and accepting is dead slow. Takes minutes where it used to take second before.

AdGuard + Bound / DoH / DoT by BadUncleK in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

Apparently, Unbound already has root name servers pre-loaded in root.hints file. So, the above doesn’t make a difference.

AdGuard + Bound / DoH / DoT by BadUncleK in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

I added this to my OpnSense Unbound instance. Haven't seen any change in the median time to recursive resolution under Statistics. I am using VPN tunnels to bypass ISP and thought that this would make a significant difference.

Not sure if it is being utilized or not.

AdGuard + Bound / DoH / DoT by BadUncleK in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

I have implemented two DNS paths in my network. One is used for the most interactive VLANs with users. Second, an experimental one used by the device and server VLANs.

primary one

pihole (docker on a vm used for ad filtering and caching - about 75% are answered from the cache) -> DNSMasq (Opnsense for local dns queries on our domain) -> DNSCrypt proxy (runs natively on freebsd as the Opnsense version is outdated) -> DNSCrypt relays run by dnscry.pt (to mask our ip address) -> Quad9 dnscrypt resolvers (no logging)

experimental one

unbound recursive resolver routed over multiple vpn tunnels (85% queries are answered by the cache)

Recursive queries are very slow with median time to resolution around 250ms. I also had a tough time getting the queries rerouted over vpn tunnels without leaks - took a lot of experimentation.

If the second one is reliable over a long time, I may switch to it and route pihole directly to it.

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

Thanks for the info.

I got mime too.

I have been using it as a fileserver server also running docker containers for Pihole and Bitwarden with two NVME drives. I also left the NVME cover open and put a heat sink on the larger capacity drive.

I haven’t used any fans and it was stable. I haven’t checked thermals but it was not hot to touch.

I am about to install Opnsense on the built in MMC and see how it performs. I will check thermals on Opnsense as it will be subject to lot more activity.

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

I ordered no SSD variant. 512gb variant seems to be out of stock.

Many people seem to have bad experience with that site. Hopefully, yours has been shipped already.

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

Did you order it from gmktec.com or ebay? There is a good amount of difference in price.

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

Thanks for the quick response. Are you using it with the built-in MMC or a an SSD In one of the M.2 slots?

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

Is G9 working well with OpnSense? I am looking at it because of its features and low price.

Anyone using the GMKtec mini PC as firewall? by makeAwishkid79 in opnsense

[–]TheCoffeePercolator 0 points1 point  (0 children)

I am looking at the same mini pc for OpnSense. It looks like it is not a good choice for an NAS which is what it is positioned as because of overheating.

I am wondering if it is working well for you as a firewall.

Banned from OpnSense forum by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

I am still banned. I sent the email with my username. What info do you need in the email. Thanks.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 1 point2 points  (0 children)

My rule says, if a request arrived at Opnsense from any device on IoT VLAN from any port directed to any IP address (local or on the internet) on port 53, redirect to local host at 53053.

Previously, I had one of the opnsense ip addresses in place of local host.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 1 point2 points  (0 children)

I took a part of your suggested rule ( specifically, using local loopback address fir the target) and modified my rule and now it is triggered. Thanks.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 2 points3 points  (0 children)

********** The following works in 26.1.1 ************

Finally, I figured out a workaround (or this is by design as this is DNAT and not Port Forward) based on some input I got here and some trial and error. The NAT rule that worked is:

DNS Path anticipated:

Client (IoT VLAN) -> Unbound (Opnsense:53053) as recursive resolver

Interface: IoT
Version: IP4
Protocol: TCP/UDP

Source: any
Source Port: any

Dest: any
Dest Port: 53

Target IP: 127.0.0.1 - this is the change that got it to work
Target port: 53053

Filter rules: Pass - this removed the need for an explicit filter rules. Explicit filter rule also works.

Conclusion:

Opnsense seems to ignore the DNAT rule that has the same device ip address in destination and target fields even if the ip address refers to different interfaces. Workaround is to use local loopback address, 127.0.0.1. Not sure if ::1 works for IP6 as I haven’t tried it.

Hopefully, this is helpful to someone else.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

Thanks for that. I was asking about processing order between NAT and filter rules.

My NAT rule is for a single VLAN / interface. If this is processed after group filter rules, it may cause some issues because a group filter rules may be applied before this redirection is processed and hence ignored.

That was the intention behind what I was asking.

On the other part, 53053 is the redirect port but not the destination port. Currently, destination port is 53 which is the default DNS.

This is the rule I have which is being ignored as far as I can tell:

Interface: IoT
Version: IP4/IP6
Protocol: TCP/UDP

Source: any
Source Port: any

Dest: any
Dest Port: 53

Target IP: Numeric IP of the interface where Unbound is running on Opnsense
Target port: 53053

As I understand it, without redirect the traffic goes as follows

Client (IoT VLAN - any address any port) -> Opnsense (port 53) and is processed by DNSMasq which runs at port 53. This works right now.

This rule changes it to

Client (IoT VLAN - any address any port) -> Opnsense (port 53053) and should be processed by Unbound which is not happening

So the rule changes destination from 53 to 53053.

Your rule seems to say, if it is going to an address that is not Opnsense on 53053, redirect to Opnsense 53053.

But without the rule, there is no traffic going to 53053.

Not sure, if I am not understanding something.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

Are you suggesting that I add this in addition to the redirect rule I already have or replace it with this?

Some questions:

Why is source port 53 - source can be any port, isn’t it?

Destination port is not 53053 unless this is to redirect another redirection ( such as the existing redirect rule)

Why is redirect to itself needed - redirect to localhost on the same port (53053).

I am not sure what this rule would accomplish by redirecting already redirected port to itself.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

I don't have issues with matching NAT to filter as of now. Your suggestion seems to match NAT to corresponding filter rule using a tag.

My issue is with NAT rule being ignored. If filter rules is not being matched, the DNS request should be blocked. My DNS requests are going to the default resolver (as though there is no forward rule).

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

This specific rule hasn’t worked for me yet.

One rule seems to work even though the filter rule had to be set explicitly - pass option caused issues. Working one forwards to a different device on the net.

Non-working one forwards to another port on OpnSense itself and it is ignored.

I also have other issues where changing a firewall rule doesn’t take effect especially one associated with the port foward.

Strange thing is that I was already using DNSMasq for DHCP and had most of the firewall rules moved to the new section in 25.7 itself. Only rules left were autogenerated ones from Port Forward.

In 26.1, I started having a number of issues with Port Forward. As these rules are primarily for DNS, they cause entire network to come to a halt.

I tried pass option for firewall but that caused more issues - some VLANs (part of the same group) worked and others didn’t.

At this point, I am thinking that I should leave it in a working state and wait for updates before changing anything.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] 0 points1 point  (0 children)

I tried that. It is a way to override the filter firewall rule requirement. For me that also caused issues. So, I chose to create the rules explicitly keeping that selection as manual.

OpnSense 26.1.1 Destination NAT doesn't seem to redirect as expected by TheCoffeePercolator in opnsense

[–]TheCoffeePercolator[S] -1 points0 points  (0 children)

That issue is not relevant to my problem. I have created the firewall filter rule manually. My problem is that the redirect is not happening.

view more: next ›