Messages

Hi!

(On an appliance being the http(s) and SOCKS proxy bastion) I'm bombarded by "default deny/state violation" entries in my log. As the system is basically running on a permit any to any rule the cause should be the state violations. To understand where/how they are generated I would need a way to see them first so

does anyone have a tcpdump filter expression that will select all the relevant traffic?


Achim

I'm a bit confused here.

Goal: Add SlackHQ/Nebula (final goal: set it up as lighthouse and router) to OPNSense.

First obstacle: OPNSense is ignoring tunx (for very good reasons, but there is no way to override it)

Obstacle 1.5: Nebula insists on using tun* interfaces with fixed names in its configuration. Remedied by modifying the code a bit. Nebula also does not destroy an interface before quitting or trying to use it. If you put a shell script renaming an interface after creating it, nebula will fail to (re)start.

Now I'm ending up with interfaces nebulaX like

Code Select Expand


nebula0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1300
        options=80000<LINKSTATE>
        inet 172.31.255.3 --> 172.31.255.3 netmask 0xffffff00
        inet6 fe80::4e52:62ff:feb9:5bb6%nebula0 prefixlen 64 scopeid 0x10
        groups: tun
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
        Opened by PID 46890


and OPNSense is at least recognizing them:

https://router.rhb.bnc.net/status_interfaces.php shows it as

Code Select Expand


Unassigned interface (nebula0)
Status up
MAC address 00:00:00:00:00:00 - XEROX CORPORATION
MTU 1300
IPv4 address 172.31.255.3/24
IPv6 link-local fe80::4e52:62ff:feb9:5bb6/64
In/out packets 0 / 2 (0 bytes / 232 bytes)
In/out packets (pass) 0 / 2 (0 bytes / 232 bytes)
In/out packets (block) 0 / 0 (0 bytes / 0 bytes)
In/out errors 0 / 0
Collisions 0


(wait... didn't ifconfig claim it was a  POINTTOPOINT -- what is the MAC address doing there and where iis the /24 netmask coming from?)

So: Is there a way to mark this as general purpose point-to-point interface inside OPNSense or is that not even necessary? Nebula is carrying rudimentary firewalling capabilities as part of client configuration and authorization as part of the authentication material (a certificate) that will restrict routeing but I would have liked adding this information to OPNsense even if it is just for reference and there are a few other new VPN/mesh tools out there that are intended to let  the endpoint make routing decisions. In these cases it would be necessary to assign addresses by the user (i.e. OPNSense) and deal with the routing table, too.


Achim

Please provide a way to generate different descriptions (e. g. "Interface/List (autogenerated): xxx") instead of just "default deny rule". As the live log view does not show which of the lists a rule is from and my clients are able to write about two more "default deny rule" descriptions than I even thought would be possible reading their firewall logs is already giving me cramps without automatic rules giving away that said client did not mess them up by hand... Being able to change their descriptions manually would of course be even better.

[do not apply changes]

Version 18.7.7 (and probably in all versions before because nobody ever looked at it)

Try:

1) Set up a set of paired OPNsenses.
2) Start adding CARP interfaces on the master but do not apply changes (e. g. because you want to have them created all at once as you are working in a live environment).
3) Take a look at Firewall->Virtual IPs->Status on the backup machine.

You will find it to be master for all the new interfaces you created.

This thoroughly cramped my style... I wanted to set up the final pieces on the replacement router by adding all the CARP interfaces to take over the router IP addresses across a collection of separate network segments at once and suddenly around me chaos broke out because the backup machine started messing up ARP tables by becoming active.

If this is an intentional feature it should be documented in a highly visible place... And if this is the intention what is the "Apply changes" button intended for?


Achim

We need more information about the alias, type, contents, if this applies to existing rules or only editing/creating rules.

Existing rules didn't work after upgrading, new rules neither. The alias was of course a port number and contained exactly one port. So: Create an alias for a port number (e. g. HTTP_proxy as 3128, create a rule (e. g.  from port 10080 on the local host to HTTP_proxy on the local host) and check the pf rule generated and you will find the destination port missing.

If a NAT forwarding rule is using an alias as "Redirect target port" instead of entering it directly the port is not added to the generated pf rule. It was still working in 10.7.3...

noses.