Messages

The first SYN packet never arrives the server. If I do not make a logical mistake, there is no RDR entry for source=VPN dest=1.2.3.4, but there are entries from internal clients.

Is the RDR rule not bound to VPN interfaces? Where is it defined?

A secret technique is to put the reverse proxy on the OPNsense itself which will cut out all the NAT issues just like that.

There are quite a few to choose from.

To be honest, I am not a fan of such an architectural approach. Furthermore, it is not good security practice to do all tests on one system.
With a reverse proxy in a DMZ I can filter and analyze the incoming traffic to the RP, the outgoing traffic from the RP AND the content in the RP.

* - replace RP with any other kind of application gateway like DNS, MTA, etc.

It is good to know for smaller installation (SOHO) that you do not have to install an entire data center, but use some features with OPNsense. In general, it should be avoided, if it is possible.


BUT, this is not the question: why is this kind of traffic not possible?

Hello.

(network diagram is attached)

Due to limited public IPs, we use Port Forwarding from outside to inside. The NAT points in most cases to some servers in the DMZ. Let's assume, we have an URL like app.acme.com, which resolves to our public IP 1.2.3.4 . You can access https://app.acme.com from the internet as expected. In order to reach app.acme.com also from inside, the OPNsense does NAT Reflection. This works also fine (you can see blue RDR rules in the log).

But: it doesn't matter, if you use OpenVPN or Wireguard, Road Worriors can not access https://app.acme.com. If they disable VPN, they can use it immediately. But then, they cannot access pure internal applications anymore. Rules and routing are double and triple checked.

It is no routing issue, since I am able to follow the traces, if you access the Reverse Proxy directly. One work around may be that app.acme.com is resolved direct to the Proxy instead of the public IP. But we have also a general purpose DNS name and the OPNsense decides which destination is the right one based on the port.

In general, why is it a problem to do NAT reflexion and through a VPN tunnel? Or is there a tick I missed to set? There are already some related topics here in the board, but they are in most cases unanswered and damn old. I would like to investigate this.

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.