Topics

1

24.1 Legacy Series / Prefetch update packages

« on: November 06, 2024, 11:15:35 am »

Hello everyone.

I wanted to update a remote box from 24.1 to 24.7 today. The download of the large package was in the kilobyte/sec range on the first attempt, the second attempt was initially in the megabyte/sec range and then it was in the kilobyte range again. Then I was out of the maintenance window agreed with the team.

Question: can I download the packages (the large one of 800MB) beforehand and then apply them, comparable to an "apt install ./local-pkg.deb"? Something with a cache directory? As I said, it is an upgrade of a remote box.

2

23.7 Legacy Series / After upgrade: administrative not reachable

« on: May 17, 2024, 11:19:09 am »

Hey there,

today, I updated an OPNsense box (DEC hardware).

What is not working:

• the web interface is not reachable anymore (no connect)
• SSH login is not possible anymore (auth failed)

What is working:

• Traffic in general (luckily!!)
• IPSec site2site, OpenVPN dial-in incl. authentication
• SNMP requests, SNMP info states 13.2-RELEASE-p7 FreeBSD 13.2-RELEASE-p7 stable/23.7-n254871-d5ec322cffc SMP amd64
• shutdown and start via hardware buttons

The overall goal was to get to 24.1

Do you have any approaches to troubleshoot this? The box is 180 kilometers away, the local access should be the last resort.

3

Virtual private networks / DHCP Relay through VPN (ISC DHCPv4)

« on: March 20, 2024, 06:19:39 pm »

Hey there,

we have to roll out a handful branch offices. There is nothing IT related stuff, clients only. They wish to control the clients from the DHCP server in the data center. I hardly try, but everytime I set a DHCP Relay IP, which is routed via VPN, it throws: "Unsupported device type 131 for "ipsec1"". If I take a DHCP server in "the internet" or locally, it works. I cannot see the purpose of an device type for an DHCP relay... 

The new KEA DHCP as alternative lacks the relay option or I cannot find it.

Do you have any idea?

4

General Discussion / Source Interface of OPNsense initiating traffic

« on: February 24, 2023, 12:38:16 pm »

We usually configure a loopback management interface with an management IP for remote sites. This IP is used for HTTPS, SSH and SNMP from the main site to the remote device. This works well through the VPN tunnel.

However, this does not work well for the reverse way. The use case is: the OPNsense initiates a connection to the syslog server. The expectation is: the OPNsense box takes the MGMT interface as source interface. The reality is, that the WAN IP is taken.

I attach an image to make that more clear. How can I achieve the goal ?

5

22.7 Legacy Series / IPSec tunnels do not re-initiate

« on: November 10, 2022, 03:44:02 pm »

Situation:
main location: dns name to IP, OPNsense 27.7
remote location 1: dynamic IP, Juniper SRX
remote location 2&3: dynamic IP, OPNsense 27.7

If we restart the StrongSwan service at the main location or boot the OPNsense (because of updates, etc.), the remote OPNsenses do not re-establish IPSec connections, the SRX location does.

Looking to the remote machines: under VPN > IPsec > Status Overview there is a red cross in the P1 status. Only by clicking on the play button (on the right side) does the tunnel come back immediately or by a reboot.
We have now tested different configs in the connection method and with DPD, but did not have the desired success.

What does the IPSec config have to look like in order to automatically try to establish a connection again after the tunnel has been aborted/terminated? Any ideas (we have an temporary access to the remote machines, even if the tunnel are down)?

6

Intrusion Detection and Prevention / OPNsense IPS syslog triggers IPS

« on: December 20, 2021, 12:59:04 pm »

Our central OPNsense does IPS. During the Log4Shell analysis I realized that some JSON datagrams are not received by the syslog server (I guess to large for UDP, will try it with TCP).

But, the other point creates more concerns: if external hosts send Log4Shell http requests to my targets, Suricata finds the patterns (great) and block the requests. The OPNsense creates a syslog message with the malicious request for Splunk/Graylog. The outgoing syslog message is blocked, since Suricata finds the pattern again and blocks the request, which generates a new syslog message.

We have also a Reverse Proxy in the DMZ. The unencrypted local requests are blocked by Suricata (also great). If it catches log4shell https requests and puts it into the access log, the Splunk Forwarder sends the request to Splunk. Suricata finds the patterns, blocks them and generate a new syslog message. 93% of all log4shell connections are done by OPNsense->Syslog or RP->Syslog.

Isn't the pattern "1 request yields to 3 requests" a melting pot for DoS scenarios.

Don't get me wrong, Suricata does its job very well, but I have to find a way to exclude/trust connections. How do you solve this problem at your side?

7

Virtual private networks / How to establish a routed IPSec Tunnel

« on: October 15, 2020, 06:46:37 pm »

How can I establish a IPSec-VPN-Tunnel with an interface I can set routes to?

Code: [Select]

(10.10.0.0/16, 192.168.5.0/24) SRX --- INTERNET --- OpnSense (192.168.20.0/24, 192.168.255.1/32)

With the mode "Tunnel IPv4" I can reach either 10.10.0.0/16 or 192.168.5.0/24, based on the configuration of phase two's remote network. If I use "Manual SPD entries" the connection can be used for some time, but after some hours I have to swap the entries "remote network" and "manual SPD entries" two times to be able to reach both remote networks for a while.

Coming from Juniper VPN world I am used to create a tunnel interface and simply route the desired networks through the IPSec tunnel. But all my tries with the "route-based" mode in combination with a gateway were hopeless cases. Does someone have a good guide to create a tunnel interface I can use to route to?