Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - bassopt

#1
Hello.

I've been away from opnsense for a bit trying other solutions. Today I decided to play with the latest version and it seems igmpproxy is not working properly again. It was working fine the last time it tried it (my vm backup was on a early version 25.1) but now my iptv stream stops after 5 minutes, meaning  (I think) that for some reason it's not renewing the multicast stream.
I have a totally similar config in pfsense and it works fine. Same firewall rules, same igmpproxy config and it was working fine before the upgrade.
No clue what is going on.
#2
Quote from: meyergru on December 12, 2024, 11:44:30 PMSome comparison data:

I have OpnSense running baremetal on an N100, definitely slower than your 12th gen i5.

When running iperf3 against my datacenter Proxmox OpnSense with vtnet adapters, I get ~400 MBit/s both upstream and downstream with -P4, which I would expect from the N100. I can run MTU 1500 on my equipment on the WAN interfaces and I have MTU 1400 on my Wireguard instances.

The Proxmox in the datacenter is on an Core i5-13500 and I use "host" CPU type to enable AES-NI with 4 cores assigned.

My uplink is somewhat more than 400 MBit/s, so definitely limited by Wireguard performance here. Ping is 37ms over Wireguard.

P.S.: With "--bidir", speed substantially decreases to ~250 MBit/s up- and downstream with -P4. The tests were conducted on OpnSense itself acting as iperf server and client.



Hi sorry do brig this topic up again, but there's for sure something wrong with WireGuard on opnsense. ( which also affects tailscale ).
I have a 1gb symmetrical conecction with my isp. I've just tried an iperf3 test from my house to an oracle vps in Spain ( I'm in Portugal ) with similar pings to yours and on pfsense ce 2.8.0 I get 820mpbs and with -R aroud 910, while on opnsense it doesn't go higher than 400mpbs and around 600 with -R This with a single thread. P-4 makes no difference. I'm also using a n100 with 16gb of ram. The VPS is an Ampere 4core vcpus running Debian. ( results using openwrt are similar to pfsense).
The test was made with pure WireGuard, although tailscale produces similar results on all situations with only 5-10% lost in pfsense.
#3
Quote from: Drinyth on May 11, 2025, 12:10:25 AM
Quote from: bassopt on May 10, 2025, 10:34:34 PMIve been plating with new dnsmasq implementations and i have huge issues with dchp clients! Some never get an ip others take forever or very slow to do so. Not sure if it's related  DHCP register firewall rules option
I've read the documentation a dozen times and followed it strictly and still have these issues.
Dns works more or less ok.
 


Hmmm I have rebooted pfsense many times what do you mean reload firewall rules? That doesn't make much sense even less pratical.
Does the DHCP register firewall rules really necessary.
To be honest the DNSMasq instructions are a bit confusing at the time.

After you check the register firewall rules option, be sure to reload your firewall rules. I think I read someplace that it does not do this by default for you.
#4
Ive been plating with new dnsmasq implementations and i have huge issues with dchp clients! Some never get an ip others take forever or very slow to do so. Not sure if it's related  DHCP register firewall rules option
I've read the documentation a dozen times and followed it strictly and still have these issues.
Dns works more or less ok.
 
#5
General Discussion / Kea implementation.
February 28, 2025, 12:39:16 PM
Hello.

Maybe someone can enlighten me on this , but ... why is the implementation of kea going so slow and barely any changes since it was originally added to opnsense?

A lot of features missing unless you configure them manually using cli
DHCPv6 still missing (I know dhcpv6 ) is not exactly a standard for ipv6 but it's still handy

Other features like pxe boot still missing.. etc.. these are just a few exemples.
I don't like to compared senses but how did pfsense magically implemented everything by just clicking one button changing to kea.

Thanks.
#6
Quote from: Monviech on June 26, 2024, 08:07:26 PM
Sorry I have no experience with tailscale. Maybe somebody else can help here.

Thanks anyway :)
I do hope someone can help me figure this out. I moved from pfsense recently and was able to get everything working fine except for this.
#7
Quote from: Monviech on June 26, 2024, 06:29:21 PM
Well you say it does not work, but this is a complex issue.

You have to do some troubleshooting with tcpdump and follow the flow of the packets from source to target and back. Then you can pinpoint where it takes the wrong route, or gets lost.

When you know the exact spot, you can tweak the configuration in order to make it work.

-----

Regarding the port forward and the floating rule, look at this paket flow diagram:

https://forum.opnsense.org/index.php?topic=36326

The NAT rule matches first (Thats your port forwarding)
Afterwards you need a firewall rule to allow that traffic. You can do that with either a floating rule that has multiple interfaces selected (the same as in the port forwarding rule), or you create seperate rules manually on each interface that allow that traffic.

the all show basically the same execpt that nat reflection is on all packets show tcp 0 in the end

This is nat reflection on
IPv4, length 74: 10.50.3.1.61906 > 10.50.3.243.22: tcp 0
IPv4, length 74: 10.50.3.243.22 > 10.50.3.1.64608: tcp 0

This is nat reflection off

IPv4, length 66: 10.50.3.243.22 > 10.50.3.1.59791: tcp 0
IPv4, length 1274: 10.50.3.1.59791 > 10.50.3.243.22: tcp 1208

This is the only difference.

the taiscale interface shows nothing with tcpdump and the origin on both situations shows the ip from my firewall because i assume thats how tailscale works? all traffic is seen as comming from the FW it self and not the other side of the tialscale tunnel?

Thanks.
#8
Sounds quite incredible that no one here, apart from pointing me to the obvious documentation , doesn't have any thoughts of what might be wrong with my issue.
Note that in pfsense I had the exact config and it all works fine. I know tailscale is not officially supported by opnsense but there's not reason for a port forwarding rule with nat reflection on to kill acesss to that machine from it.
Anyway...

P.S why does a port forward rule needs a separate floating rule anyway ? I really don't understan
#9
So I did a few more tests and it seems to be an issue with tailscale alone.

If I turn on nat reflection on port forwarding rules I can no long access  anything on that host ip except for ping from the tailscale clients / machines except for ping. No ssh noting...all the other hosts on my lan and vlans that don't have a a port forwarding rule , it works fine.
#10
Quote from: Monviech on June 24, 2024, 01:20:52 PM
Maybe this tutorial can help you to build the proper NAT from the ground up.

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

I've read that countless times. Doesn't work! I think the issue is something do with tailscale no clue what could be
#11
I wish someone could help with this.

It's driving me nuts.
#12
Ok.
So I partially solved the issue by selecting my internal network interfaces as well as tailscale and WireGuard in the port forwarding rules and not only wan ( this is very different from pfsense hahaha )

But I still have a problem with one port forward rule I have for ssh with a custom port on the wan for a bit of obfuscation. Basically wan port  xxxxx to internal ip port 22. With nat reflection enable I can ssh into that machine fine from all my internal networks / vlans but not from WireGuard devices or tailscale. For example I have a vps I connect to my pfsense via tailscale and I can ssh into all my lan IPs except for the one with this rule.
If I edit the rule and select nat reflection - disable. It works fine. ( i would like to keep nat reflection on because I have a FQDN accessing that machine and would like to solve this without host override.  It also works fine if I disable the rule

I'm clueless at this point.
#13
Hi.
I was playing with opnsense a bit last night. For the most part I managed to replicate what I had on the other sense. Except for issues with port forwarding and NAT reflection.
When I configure port forwarding I can't access either FQDN I'm forwarding (externally) or the machines internal IP addresses from my networks (rules are properly configured )

If I configure host override it works but IP address doesnt. Which is a problem because I have a tailscale tunnel configured to a remote VPS from which I need access my local IP addresses

If I disable NAT reflection on the portforwarding  rules  I can access the internal IP addresses from my internal networks and the remote tailscale VPS but not from external FQDN from within my network. I need as before to override hosts

External connections work fine with both configs

Is there any way to properly configure this? I mean... The second option works ok but adding host overrides is a bit annoying

I tried to read documentation but I found it a bit confusing tbh

Thank you :)
#14
Haha. Thanks for disclaimer.  ;) and the clarifications

I didn't mean to Insult  your product or anything but my experience with opnsense hadn't been the best, although I admit probably because I didn't dedicate as much time to it as I should. ( I'm just a musician of trade and a home laber of passion)
At the time the video you mention made sense to me ... but certainly not anymore specially after Mr gonzopancho (lol ) replies and specifically his interactions with me.  ( as of the time of me writing this post  I'm apparently blocked from replying at the subreddit

Keep up the good work. I've deleted all my pfsense backups and VMs and restored an old openwrt config until I have time to dig into opnsense in July hopefully when 24.7 is released !   ;) Morally i can't continue to use pfsense anymore after this.  Free or not. ;)
#15
Honest question.
Why did you choose FreeBSD 14.1 and not 15?
It seems that pfsense is using version 15 now on their latest plus version and will on their next CE too, wouldn't it make more sense for Opensense to go for verson 15 too, since netgate still contribues with quite a bit of code to mainstrean Freebsd, avvoiding the need of backports.
I'm  probably beeing a complete ignorant on this, but it just makes sense in my head.