Recent posts

#1
Quote from: mrzaz on Today at 03:12:56 PMAnd is using the exact IP/PSK and similar in my IPSec legacy working totally fine and is up
and could reach network on the other side of IPSec.
For testing the new connection you have to disable the legacy, however.

Quote from: mrzaz on Today at 03:12:56 PMI'm a little puzzled about the Local and Remote Authentication screens.
The are the authentication settings.
In local you define, how your server authenticates on the remote site.
And in remote you define, how the remote site has to authenticate on your server.

I think, it's necessary to state a local and a remote identifier in the pre-shared key settings. And then use the same in the local and remote settings of the connection. This is the only way, IPSec can select the proper PSK in case, you've multiple.
This means, you will have to enter the respective ID from the PSK in the authentication settings.

Quote from: mrzaz on Today at 03:12:56 PMReqid = <blank>    This one I am not sure if needs to be populated with anything if not using manual certificates ?
Recent versions set a unique requid automatically, as I've read. This didn't work in the past, however. So I've stated a unique one (above of 10) for each tunnel.

Quote from: mrzaz on Today at 03:12:56 PMESP proposals = default
You should remove the check at default and select a proper for your needs here. The same is true for the phase 1.
According to your screenshot of the legacy settings, you need aes256-sha256-modp1024[DH2].

Quote from: mrzaz on Today at 03:12:56 PMIn Legcay IPSec you are manually defining "My identifier" and "Peer identifier"
where in my legacy setting I could not find that setting !?
You mean in the new connections?
As mention, you have to state in the PSK  and authentication settings.


Quote from: mrzaz on Today at 03:12:56 PMPs. I have using OpnSense for many years and pfSense (before they stagnated and I moved to much better OpnSense and never looked back. :-)
Me too. :-)
#2
General Discussion / Re: Opnsense DOSing upstream D...
Last post by gardener - Today at 08:42:37 PM
I disabled the conditional forwarding from pihole to opnsense as a "solution".
#3
Zenarmor (Sensei) / Re: Zenarmor performance @ Int...
Last post by Seimus - Today at 07:06:22 PM
@meyergru many thanks for all of this awesome info.

Personally I use OpenWRT for APs.

If I already had some Unifi HW the decision would be simpler :D.
Anyway, I will consider all the great info you provided into my decision making.

Regards,
S.
#4
General Discussion / Re: Unbound-control and SNMP e...
Last post by cweakland - Today at 05:39:26 PM
In Servcies > Unbound > Advanced > Enable Extended Statistics

Then create this script, hopefully this lasts across a upgrade (need to test this). I did test a reboot, and it does persist.

vi /usr/local/etc/rc.syshook.d/start/99-snmp-unbound-extend.sh

---BEGIN SCRIPT---

mkdir -p /usr/local/share/snmp_extends

echo "#\!/bin/sh" > /usr/local/share/snmp_extends/unbound
echo "/usr/local/sbin/unbound-control -c /var/unbound/unbound.conf stats" >> /usr/local/share/snmp_extends/unbound

chmod +x /usr/local/share/snmp_extends/unbound

if ! grep -q "extend.*unbound" /usr/local/share/snmp/snmpd.conf; then
    echo "extend    unbound   /usr/local/share/snmp_extends/unbound" >> /usr/local/share/snmp/snmpd.conf
fi

service snmpd restart

---END SCRIPT---

chmod +x /usr/local/etc/rc.syshook.d/start/99-snmp-unbound-extend.sh

Run the script and then in LibreNMS enable the Unbound app under the firewall.
#5
What is the log output? Something like: no matching peer config found? The ID fields in "Edit local" and "Edit Remote" are part of the strongswan config (/usr/local/etc/swanctl/swanctl.conf)
#6
General Discussion / Re: Crashing after upgrading t...
Last post by bigdog420 - Today at 04:39:19 PM
Quote from: newsense on Today at 04:52:05 AMYou can start by posting a health check and the output of this command

ls -ltrh /var/crash/

Looks like it comes up empty

I did have something though from my previous search engine searches:
Fatal trap 12: page fault while in kernel mode
Similar to this topic: https://forum.opnsense.org/index.php?PHPSESSID=bjvl1u7vtsaeu670pfvni5gvk5&topic=28302.15

I guess I'll need to wait for the crash to happen again to grab the info needed. I'll update this thread once that is done.

Thanks!
#7
26.1 Series / Re: tunables set to unknown va...
Last post by mr.aksu - Today at 04:31:08 PM
Hm, no change in 26.1.5, "System: Settings: Tunables" still showing random things for "Value" and "Default".
#8
26.1 Series / Rule migration: Inverting dest...
Last post by szotsaki - Today at 03:22:17 PM
I followed the migration wizard steps and after importing the rules I was given four "lines" in a pop-up window without further explanation. Whether they are errors or just warnings, or whether the said rules were migrated or not were not clear.

These are two examples:
destination_net Inverting destinations is only allowed for single targets to avoid mis-interpretations bf920f1c-a9ab-4383-8dd7-9ca5e9b8c2f7;1;keep;;371;pass;1;0;lan;in;inet46;any;;;;;0;1;0;0;0;;;;;;;;;;;;;;;;;;;;;;;"Allow access to WAN";0;lan;;1;PrivateIPv4,PrivateIPv6;
destination_net Inverting destinations is only allowed for single targets to avoid mis-interpretations 2ace6415-7b35-4c42-9bb8-ee5415de71ec;1;keep;;451;pass;1;0;opt1;in;inet46;any;;;;;0;1;0;0;0;;;;;;;;;;;;;;;;;;;;;;;"Block access to other internal networks but allow access to the Internet";0;opt1;;1;PrivateIPv4,PrivateIPv6;

After the import, I see them in the new rule set table, but I cannot edit them:



I can look up for the "reference" for these rules with the button, but will they be gone after I remove the old rule set? Currently, I assume so.

Could you please handle these kind of rules during import gracefully?

Additionally, I find the old rules editor a lot better from UX perspective:
  • Physical keys (up, down, PgUp, PgDn) work on the page right away, no need to click around
  • Having two scrollbars next to each other (page in page) is weird, just to have an Apply button in the bottom.
  • Restricting a huge table on a huge monitor into a small area with many borders feels very cluttered.
#9
Virtual private networks / Re: Issues with new "IPSec" ve...
Last post by mrzaz - Today at 03:12:56 PM
Hi,
Thanks for answering.

The "Local addresses" is my public WAN IP address that is static, not DHCP or DHCP reserved.
My WAN is not double-NATed but real public static IP. Internet reaches my WAN directly.
I even have recursive DNS lookup on two of my three IPs I "own" (helps running my mailserver as more legit)

The "Remote address" is a domain-name the resolves to a A-record in DNS.

And is using the exact IP/PSK and similar in my IPSec legacy working totally fine and is up
and could reach network on the other side of IPSec.

From what I could see, both local and remote accepts "single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges."

I do not use pools so that is switched off.

I'm a little puzzled about the Local and Remote Authentication screens.
The connection is the only one selectable in the drop down menu and auth = PSK
but don't know if I need to specify anything in the "Round" and "ID" ?

If I read this correctly it is more to do when using certificates.

"IKE identity to use for authentication round. When using certificate authentication
the IKE identity must be contained in the certificate; either as the subject DN or
as a subjectAltName (the identity will default to the certificate's subject DN if
not specified). Refer to https://docs.strongswan.org/docs/5.9/config/identityParsing.html
for details on how identities are parsed and may be configured."


I have not been needing to create any certificate in the legacy IPSec OpnSense setup.

The Children (aka ~= Phase 2) is having the following:
Connection = <connection name>
Mode = Tunnel
Policies = YES.  (As I am not using VTI in the setup but a straight old fashion IPSec.)
Start action = Start
DPD action = Start
Reqid = <blank>    This one I am not sure if needs to be populated with anything if not using manual certificates ?
ESP proposals = default
Local = 192.168.120.0/24    ; this is my LAN
Remote = 192.168.100.0/24    ; this is remote LAN.

In the PreSharedKey setting i have setup a PSK.
Local Identifier = <my public static IP>
Remote Identifier = a specific DNS A-record domain name
Pre-Shared Key = Our PSK shared key that works in legacy IPSec right now.
Type = PSK

I just realized one thing.

In Legcay IPSec you are manually defining "My identifier" and "Peer identifier"
where in my legacy setting I could not find that setting !?

My identifier = My IP address  (my WAN IP address same as defined in Connections "Local addresses".
Peer identifier = Distinguished name = <a specific domain name like "xxx.yyy.zz" format.

There must be something I'm missing but could not find out what that is.

Firewall is set to following on WAN:
- Allow ESP for IPSec (IPv4)
- Allow IKE port500 for IPSec. (Udp ISAKMP (500)
- I also have "IPSEC-NAT-T (4500)" on WAN. (Allow IPSec IKEv2 MOBIKE NAT-Traversal)

Best regards
Dan Lundqvist
Stockholm, Sweden

Ps. I have using OpnSense for many years and pfSense (before they stagnated and I moved to much better OpnSense and never looked back. :-)
I have been using both legacy IPSec standard but also VTI tunnels (OpnSense<->OpneSense) with at least
3 VTI plus one standard IPSec at the same time.

Anecdote is that I have had my own domain since 2000, and been running a mailserver since late 2002 with at least 1-2
real persons since day one entrusting me as their main email provider for 20+ years. :-)
#10
26.1 Series / Re: Wireguard VPN
Last post by meyergru - Today at 03:07:22 PM
There are two parts of firewall rules (well, actually, it's three):

1. On WAN, you need to allow "in" access on the UDP port that your wireguard instance is running on.
2. On the Wireguard group, you need to create "in" rules to access any of the LAN resources you want external clients to have access to. For starters, you could "allow from any to any".
3. In the wireguard peer, you need to set the "allowed ip" range to those of the wireguard clients that you want to pass. You could use 0.0.0.0/0 here.

All of this is explained for both site-to-site and roadwarrior setups in the official docs.



The order of checks would be outside -> in, so first make sure that the wireguard instance is really contacted by your clients.

That means:

a. the client must be able to connect to your external WAN IP, probably by using its dynamic DNS alias.
b. the client must be allowed to use the wireguard instance's external UDP port.
c. the secrets must be correct, otherwise the packets will be silently discarded.

You can check that via the Wireguard status. It must be green, having a "handshake age" and both sent and received traffic.

The second step would be to verify access from your client to your internal networks.

You can enable firewall logging for the default block rules and watch if there are blocks.