OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of REB00T »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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.

  • Messages
  • Topics
  • Attachments

Topics - REB00T

Pages: [1]
1
24.7 Production Series / [SOLVED] Port Forward rules do not respect the "Interface" field
« on: November 12, 2024, 10:11:32 pm »
When adding a port forwarding rule for a certain interface or set of interfaces, the expected behaviour would be for that rule to apply only for the interface(s) selected, even if the source field contains a "superset" of the subnets of those interfaces. In essence, the rule should apply to the "intersection" of the "source" and "interfaces" fields, assuming I understand the meaning of the "interfaces" field correctly.

Currently, the interfaces field seems to be ignored when applying said rules, leading to unexpected results.

There is an issue reported on GitHub (https://github.com/opnsense/core/issues/7952) that has, erroneously in my opinion, received the "support" label. Since it does not seem to be getting any attention, I assume because of that, I thought posting this here would help in bringing some much wanted attention, or at the very least acknowledging, said issue.

2
24.7 Production Series / [SOLVED] 24.7.4 Erratic PPPoE IPv6 Problems
« on: September 14, 2024, 01:37:20 am »
The setup I was using before was a PPPoE interface on top of a plan specified by my ISP. I would then configure IPv6 for that interface with DHCPv6 with a /56 PD size and use ipv4 connectivity checked. Then I would configure my LAN interfaces using track interface for ipv6. After 24.7.4 none of the interfaces or the devices in their respective subnets receive an ipv6 address. The wan interface itself has a /64 as it did before.

Should also note that clicking "Apply changes" on an interface configuration screen results in a timeout, a behaviour it did not exhibit before. Lastly, the firewall is reachable from the Lan after about 2 and a half minutes of uptime. Before that not even pings are returned. I do not believe that happened before.

Happy to provide more details!

3
24.7 Production Series / Dnsmasq IPset behaviour
« on: September 10, 2024, 11:21:38 am »
I have configured dnsmasq via a custom .conf file to resolve certain domains using a specified server using the `server` directive and to also add the results in an already configured alias of type external via the `ipset` directive. The problem I am facing is that while the first connection will **not** match the rule configured with said ipset as the destination, after resetting the states (or waiting for them to expire, as long as the DNS response's ttl is higher than the connection timeout) the rule will match. It seems to me like dnsmasq is responding with the result before actually appending said result to the configured ipset. Is this intended behaviour or should these actions be happening the other way around? If it is intended behaviour, does anyone have any ideas on how to work around this?

I should note that this especially becomes a problem with very low ttl values as the response after each connection expiry is different.

4
Virtual private networks / [Moved] Dnsmasq wildcard dns based routing woes
« on: September 01, 2024, 03:36:39 am »
I have configured dnsmasq via a custom .conf file to resolve certain domains using a specified server using the `server` directive and to also add the results in an already configured alias of type external via the `ipset` directive. The problem I am facing is that while the first connection will **not** match the rule configured with said ipset as the destination, after resetting the states (or waiting for them to expire, as long as the DNS response's ttl is higher than the connection timeout) the rule will match. It seems to me like dnsmasq is responding with the result before actually appending said result to the configured ipset. Is this intended behaviour or should these actions be happening the other way around? If it is intended behaviour, does anyone have any ideas on how to work around this?

I should note that this especially becomes a problem with very low ttl values as the response after each connection expiry is different.

Edit: Moved to Release as it doesn't explicitly concern VPNs

5
23.7 Legacy Series / Will IPSec-MB be integrated at some point?
« on: December 29, 2023, 01:49:11 pm »
pfSense managed to get some measurable performance improvements by integrating IPSec-MB. Can we expect a similar thing in a future release?

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2