Messages

Cannot confirm. Use VLANs (internal and to the ISP) and IPS.

Code Select Expand

em0@pci0:13:0:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = '82574L Gigabit Network Connection'
    class      = network
    subclass   = ethernet


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.

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.

Status update:

Indeed, with the last revision (24.1.4, 31cd002eb), there is no error with DHCP relay through VPN tunnels, but: it is not working. I assume that it sends the requests with the virtual tunnel IP (couldn't troubleshoot this branch office any more). The current workaround is a local DHCP server. I'm doing more tests with the next branch office.

On the long run, I'm looking forward to 24.7 with the new implementation. In case of pre-production tests, I have to change the software channel to type=Development in the WebGUI, right?

Thanks team for your excellent work.

Though what I don't understand is why you would select "ipsec1" for the relay. You want to relay a physical network to a server address routed somewhere, but not add a tunnel which doesn't have any directly attached clients?

To be more precise, I do not choose ipsec1, the OPNsense does. I choose "LAN" to listen to DHCP broadcasts, but a route lookup to the DHCP Server seems to yield ipsec1 as outgoing interface. ipsec1, by the way, is a route-based ESP tunnel interface. Maybe, it can try to change it to an policy based IPSEC tomorrow. The route lookup yields interface WAN in this case, which should be good for the relay. But I assume it is done for the source IP, which should not be the WAN IP in my case, but a local IP.

In general, it is a common requirement for small offices to catch DHCP requests on LAN side and send it through a VPN tunnel to a central DHCP server.

In the worst case I have to install RPis in the local networks with an ISC DHCP to relay through the tunnel.

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?

Actually, it was @pmhausen :-)

But, after you clarified your request, I would also recommend to add a rule with the desired SRC/DEST/PORT combination, log it, but untick "Apply the action immediately on match."

The rule is used and logged, but it is not taken as the last resort of action and is processed also by the following rules.

Additional question: may it be helpful in this case to change the tunnel into a route based tunnel instead of a policy based tunnel?

Hi,

I'm not sure, if I understand you correctly. If your question is that specific rules get a marker or flag in the log file to filter for, the answer is no.

But, every rule has its own rule id (watch the row "rid", here it is like "02f4bab03..."). This id will be also transmitted to a syslog server.

But yes, it would be great, if the description/label would be sent along with syslog/plain view.

encore:
You can label your rules (it is called "Description" in the rule's definition page). Put in "**SUSPECT** some other description" and filter in the live view with "label contains **SUSPECT**"

Hope that helps

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 ??? ?

Then set the type on start immediate on one site in addition to this

Unfortunately that didn't work either.

But news about this: today we installed version 22.7.7 on a remote OPNsense. We also had to reboot the remote firewall to do this.
Since the update, the tunnel has been running as desired, we have also downconfigured the config attempts bit by bit in order to destabilize the tunnel again for the purpose of finding the cause - nothing. Currently it runs with the default IKEv2 settings, but with DPD. I can delete the SAs and stop/start the daemons, the tunnels are recreated immediately (respectively after the DPD timeout).

Theory 1: the software update to 22.7.7 did something
Theory 2: certain IPSec config changes only become active after a reboot

Next weekend I'll try to update a machine with an untouched config to 22.7.7, maybe I'll get a clue, if it related to the software version.

What is your close action set to?

Per default to None, but we tried every single option of this parameter, but no luck so far.

We also had issues with the IPSEC Tunnels not re-establishing even with DPD setup. We ended up using Monit to monitor the IPSEC tunnels and restart if the tunnel ping failed.

Good workaround. Unfortunately, we have no host on the far end to monitor the tunnel and to reset it. And to be honest, there must be an out-of-the-box solution based on the OPNsense IPSec configuration. There can be always a wire interruption, a firmware upgrade, you name it, which yields into a tunnel termination. There has to be a solution based on StrongSwan.

Set keyingtries to -1 does the trick

It sounded promising, but neither setting it on the far end, nor on both ends brought back the tunnel. Only hitting the start button at the page "Status overview".

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)?