Topics

1

General Discussion / [Solved] Configuration import verification

« on: November 28, 2024, 03:33:42 am »

I've been running a virtualized proxmox for a few weeks now (very nice upgrade coming from TP-link).

I saw a recent post from @meyergru about recommended settings and thought I'd check them out.
If anything, that would be a good practice for future recovery...

I used scp to download the entire /conf folder (got some errors on ssh keys that I ignored).
I searched/replaced the passthrough NICs with bridge equivalents in the config.xml only (i.e. not the files in /conf/backup).
I made an iso out of the updated downloaded content that I made available to a new VM.
Creating the bridges over the NICs that used to be passed through was not fun (stopping the original VM was not sufficient. I had to reboot proxmox).

Anyway, I reran a full install and imported the configuration.
I'm reasonably confident that my core config was imported (VLANs, users, ISC DHCP, FW aliases and rules, Unbound block lists...).

But I was under the impression that:
* DHCP leases should have been imported too. By now most (if not all) devices have renewed with their existing IP but I checked right after the first boot and the list appeared small. Machines that I haven't booted since the install don't show up.
* The full history of configuration changes should be available as well. A bunch of files have been imported (confiXXX.xml naming scheme) but the only history that shows in the GUI is just 2 "new" files (config-1732751930.5814.xml and another).

So I now wonder how much I'm missing.
Is there a log of what the config importer did?

2

General Discussion / [Solved] How is the guest FW blocking access to the host management?

« on: November 09, 2024, 11:04:27 pm »

I've been slowly migrating my network away from an EOL TP-link router to OPNsense.
Today, I made the final switch. Almost everything seems to have gone according to plan.
But I've managed to lock myself out of the proxmox host...

Configuration:
* 4-port mini-PC with new proxmox install (I suspect most is default)
* 1 port dedicated to management with an IP (10.1.1.12) in my default LAN (10.1.1.0/24)
* OPNsense VM setup with 2 PCI passthrough adapters for WAN and LAN, MGMT assigned to the proxmox bridge (10.1.1.100/32).
* I used VLANs in my primary network to isolate WAN (10.2.2.2/24) and LAN (192.168.1.1/24) from existing traffic, then slowly moved my VLANs over from legacy to OPNsense router.

As of this morning, the only devices left in the legacy LAN were: managed switches, APs, controller, proxmox host, OPNsense management and a PC. It looked like it was time for the final switch.
I updated the OPNsense LAN IP to 10.1.1.1/24 (which caused loss of connectivity).
I then just replugged cables going into my old router into OPNsense, got back into OPN and adjusted the DHCP range.
All seemed well until I tried to access the proxmox host (SSH, HTTPS) for the PC (10.1.1.10). Both fail. Ping works though...

The fact that the LAN IP range on the OPN guest is now encompassing the proxmox host MGMT interface seems to be the trigger.
I removed the MGMT interface of OPNsense (since I can now access it from LAN). No change.

I looked at FW logs in OPNsense and see the replies from proxmox RECEIVED on the LAN interface of OPNsense where they are blocked (likely because the request didn't flow there).
The proxmox management port is on the same switch as the machine I'm trying to access!!!
I used wireshark to capture mirrored traffic out of the proxmox management port.
Sure enough, the MAC in the replies from proxmox is the MAC of the LAN interface of OPNsense...
A reply from 10.1.1.12 to 10.1.1.10 (on the same switch) is being sent to 10.1.1.1 (the gateway for that network)...

I see no ARP who has 10.1.1.10 during that interaction.
After couple retries, the PC doublechecks who has 10.1.1.12 though. And then the proxmox interface checks who has 10.1.1.1... Both of these were correct all along.

I could understand some of this behavior if the proxmox interface had been on a separate VLAN at some point.
The right way to contact the PC was to go through the GW. But that was never the case.

As for fixing this... I still have physical access to the host. I guess I'll start with a screen and keyboard. It's going to be fun in that closet.
Since I seem to have messed this up from the guest, does someone have an idea for fixing it from there?
Or any idea what mistake I made earlier?

3

Intrusion Detection and Prevention / The IDS rules management has a learning curve

« on: October 30, 2024, 10:10:00 pm »

I started experimenting with IDS/IPS yesterday and it didn't take long until I thought I was losing my mind.

I've now figured out why: The Admin->Rules page is what I would call a Resultant Set of "Policies" page.
I put policies in quotes because they include manual adjustments on the policy page.
And these adjustments have priority -1. IOW, once you've made an adjustment, no actual policy can affect it.
If you've made any changes directly on the rules page, an adjustment has been created for you and until you delete the adjustment from Policy->Rule-adjustments, no policy will affect that rule.

That behavior tripped me up big time because I KNEW I had never visited that adjustment page, so I didn't bother to look after my test policy behaved unexpectedly.
I would suggest a 'delete adjustment' alongside the enable/disable/alert/drop buttons...

On a side note, I've found filters on matched policy useful.
I 've had some surprises but they could be due to missing an apply...
Apparently, the filtering yields the rules that were affected by the policy (based on initial state and adjustments, not current view).
For example, with a single alert rule and a policy to swap alert to drop, the result is drop (as expected) and filtering by that policy shows the altered rule (even though the policy criteria is not a match based on what is displayed).

In any case, I'm going to keep my policies simple (not specifying old action, pri 0 for exceptions, pri 1 for large sets, no overlaps of sets)...

HTH

4

General Discussion / Trying to fully understand an ISC DHCP behavior

« on: October 26, 2024, 12:47:26 am »

I'm in the process of swapping out my existing prosumer router over to OPNsense.
I'm also trying to do this in stages (I might post about the end-to-end experience) so as to minimize potential disruptions. So far, I haven't messed up (at least not visibly).
I've inserted an OPNsense (virtualized if it matters) in my existing network and made use of VLANs to segregate traffic from my current setup. 1 VLAN for the OPN WAN, another for the native OPN LAN. So far so good.

I then did the following:

• tested the new setup with a test machine (Ubuntu), got an expected IP in the default 192.168.1.0/24 network.
• brought that machine back in a TEST VLAN handled by my current router, got proper IP right away.
• updated my current router to forget that TEST VLAN and created the same VLAN in OPN, including DHCP and FW rules

That's when things got weird. I gained internet connectivity right away but then tried to renew the DHCP lease (just ran dhclient).
The IP looked correct client side but still showed up in ISC lease list with the old 192 IP & offline!
There was also a correct entry in the OPN TEST VLAN but it showed expired but online!!!

Per the attached Log, I concluded that:

• the client still knew about its old 192. IP and requested it.
• Somehow, although the IP was not in the network range, ISC ACKed
• Sending the packet failed (either on the OPN side because of the bogus IP, or not picked up by the client because its current IP was already a 10. IP).

Is this the correct interpretation?

Reading a bit about the linux DHCP client, I cleaned up the leases file and removed all mentions of the 192 IP.
I also cleaned up some of the leases on the OPN sense side, and I ended up where I was expecting.

I'm a little anxious about moving forward, although I don't expect many clients to have stale IPs (they'll have other OSes too).
Did I do something wrong in my dry run?

Note that in the meantime, ISC has NACKed the .2 address seen in the log and issued a new one .3 (for the same MAC and hostname)...
[Update:] That Ubuntu test client now has both .2 and .3 IP active... One of them assigned to enp0s25:avahi
I have no clue why I'm getting one of these zeroconf IP when the machine already gets IP via DHCP...
[Update2:] I may have caused that last bit by setting up OPNsense in the local domain.
I guess I need another dry run with another VLAN...

5

General Discussion / <Interface> address in transparent filtering bridge mode

« on: October 09, 2024, 02:42:16 am »

Still experimenting with OPNsense until I get more memory and storage.
I set it (virtualized) between my router and my main bridge.
LAN and "WAN" are bridged (correct tunables set) and since I use a third interface for management, neither LAN or WAN have an IP address.
If I screw up, I just bypass the bridge and everything falls back in place...

At this point, I'd like to move my existing rules from my router (TP-link) to OPNsense.
At least I'd get some logging (TP-link ACLs produce none!).
Am I correct assuming that 'LAN address' (and similar) is undefined since the interface has no IP?

In a more standard setup, with OPNsense acting as the router and gateway for the LANs, then 'LAN address' would be the IP of the OPNsense LAN interface (the gateway IP). Correct?
 

6

General Discussion / Identifying APIPA hosts from firewall logs

« on: October 06, 2024, 11:12:14 pm »

I've been experimenting with OPNsense for a few days.
It's refreshing to get a firewall that provides logging... Compared to TP-link ACLs.

I use OPNsense as a transparent filtering bridge between my router and main switch.

Anyway, I've got couple questions related to entries in the logs for hosts with APIPA addresses.

The first set corresponds to an internal address of my router. The packets seem to be replies to DNS requests (source port is 53 and destination is a random port on a PC). I found one entry corresponding to a request from PC:random to router:53. I assume that connection can be reused for multiple DNS queries.
Question #1: It's normal that I don't see replies from router:53 to PC:random, right?
And that's because everything exchanged over that allowed and established connection is not only allowed but not subject to logging.
But I might see traffic router:53 to PC:random if it happened after the connection closed or was idle too long (from the firewall's perspective)?
I see APIPA:53 to PC:random within a minute of PC:random to router:53.
And that traffic would get blocked and logged anyway because it doesn't match any allow rule.

Question #2: I have discovery queries from another API address.
I suspect a device that failed to get IP via DHCP.
Is there a way to extract a MAC address from what's logged?
Maybe I can identify the source from info in my DHCP server...
I'd rather not resort to captures to find it. And if it's wireless, I'm toast.

7

General Discussion / Spurious default deny despite allow all rule

« on: October 02, 2024, 09:02:52 pm »

Hi,
New to OPNsense and first impressions are pretty good.
I may not have started with the easiest configuration but I'm running OPNsense as a transparent filtering bridge, virtualized on a N100 mini-PC with 4 ports, installed between my router and my main switch.
I followed a few different guides, and apart from the FW on OPT1 (management) and the lack of gateway by default (which prevented me from updating OPNSense before I connected the bridge), I'm at the stage where I verify that the bridge does what it is supposed to do before I enable IDS/IPS.

The only IPv4 rule I have is as simple as it gets:


Yet, here and there, it doesn't seem to apply to some packets and the default deny rule fires:


I can't really figure out what's special about these requests because some very similar ones seem to go through just fine.
All the failed requests I've seen while observing the live view have the following in common:

• HTTP or HTTPS
• Originating from wireless clients (never seen one from a wired client)

Nothing is obviously wrong on the clients themselves, possibly because of successful retries.

My existing network is all TP-link managed via Omada, if that matters.
Apart from a few VLANs to isolate clients, the configuration is standard.
Traffic going through the bridge is limited to Internet and inter VLAN plus basic DHCP/DNS/Discovery.

The OPNsense VM was given 2 cores and 4GB of RAM (waiting for a stick to double it) and 32GB of disk space (SSD).
At this point, CPU usage is low.

I'd like to understand what's going on before I enable IDS/IPS.
BTW, kudos for the logging. It's refreshing compared to the TP-link useless logs...
I may end up controlling inter VLAN traffic at the bridge instead of the router/gateway!