Messages

Hello Franco,

Shame on me. that is JS and obviously it was simple. I installed burp community and hop solved.

However, this raises an issue for OPNsense: API documentation is incorrect. For example API doc refers group_membership data is 'GroupMembershipField', same for OpenVPN server. Following the API doc, format should not simply be the number of the object (Group 2000 or VPN 3 for example).

I would suggest to correct the API doc to simply tell to use the gid or vpnid.

Thanks for suggestion anyway, solved my issue !

Brgrds

SoloS, everyone,

I am facing the same situation and appreciate any feedback, especially because I found *no help* anywhere on Internet but also because such situation appears each time of a 'special field': GroupMembershipField, OpenVPNServerField etc.

I tried with obvious information, complied with requested, extracted details of these 'special fields', tried everything possible, without debugging info from the API functions + just that 'option list' message, hard to find out by myself.

OPNsense guys, what is painful to us might be comical to you. Some help ? :-)

Thanks !

Brgrds

Please notice I found a link to this issue. Each incoming flow rules was having a defined gateway (side effect of the import).
When this gateway is removed, opnSense behaves much better...

Dear all,

Please notice I am a newbie on opnSense.
Until now I was using a competitor no longer free since a few months ;-)

I exported my ruleset from this competitor to import it in opnSense, did a few manual changes so import behaves the same. Apparently all is fine.

HOWEVER:
- My design is a FW serving 2 different netblocks, each with its gateway.
- In my design, I want to open SSH from WAN (opensense naming). So I disabled the lock out rules.

- But in real, despite the 2 WAN has exactly the same ruleset but the target IP (different subnets), opensense behaves differently:
  - On the WAN1 (WAN for opnsense), ssh keeps being blocked
  - On the WAN2 (OPT1 for opnsense), ssh is managed by my ruleset (normal).

I sense 2 possible issues:

- antilockout cant be disabled or edited. Painful when for example you dont have IPv6 and want a clean ruleset without any IPv6 pass anywhere.

- antilockout applies only on WAN (opnsense naming), making admin believe all its "WAN" are protected. There should be a way to ensure 2 WAN interfaces with the same ruleset will behave *exactly* the same.

Feel free to ask for any detail, my english might not be great :-)

Thanks

Brgrds