Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - mrzaz

#1
For testing the new connection you have to disable the legacy, however.
Yes, I totally understand that and that was done.

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.


You only have the following in PSK setting:
Local Identifier     Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key       Our joint and unique PSK as set in both ends.
Type                 PSK

There is really no "Id" to specify here apart from Local and Remote identifier.

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.
Ok, I will try that.

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].

Done...

You mean in the new connections?
As mention, you have to state in the PSK  and authentication settings.

In legacy you have
Phase 1 proposal (Authentication)
  Authentication method  Mutual PSK
  My identifier    <WAN IP>
  Peer identifier       Distinguished name    an xxx.yy.xx domain address.

But I kind of have that in PSK settings, just in slightly different way
Local Identifier     Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)

//Danne
#2
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. :-)
#3
Last screenshot.

//Dan Lundqvist
#4
More screenshots.

//Danne
#5
Hello,

I am running 26.1.5 and have a IPSec legacy connection setup working OK to a destination node
an is trying to replace it with the new IPSec Connections but it fails all the time.

I have tried to migrate the settings from old to new at the best of my abilities but it does not come up. :-/
Is there anything specific I need to think about ?

Here is the IPSec settings and will respond to myself with more screenshots of new IPSec and old.

//Dan Lundqvist
#6
Thanks for the reply.
Good that it is not just me then.

Even if the old dashboard is a bit outdated (hower not bad in my opinion) but it was strict sizes and aligning which would make small screens behave better and large screens also behave in a predictable way.

Now it feels cluttered and not well adjusted.
I agree with your statement and think this needs to be revisited with someone having better experience with UX design to get back to what was powerfull with the old dashboard design and structure BUT with a newer more updated and agile design.

Best regards
Dan Lundqvist
#7
Hello,
Not up to start a flamewar but is it more usets than me that agree with me that the new dashboard does NOT play well with mobile devices. But also placement, size and movement of widgets is more problematic than on the old dashboard.

Widgets placed in a three column way, was automatically
stacked 1+2+3 on a mobile display in the old versions
But in the new dashboard mixes the items mishmash
from all stacks and there is no strict discipline that it
stacks column 1,2,3,n in that order.
Another problem also seen is that certain widgets
Is offshifted to the right on mobile display so widgets
is not exactly on top of each other.
This was much better in old dashboard where widget
width was always the same and they was always
left-shifted.

I can agree that some of widgets looks nicer in the new
gui but some works needs to be done to make widget
aligning better and also widget sorting more strict
to the old way of column 1,2,3,n.

That is my 2 cent worth of constructive criticism.
Don't get me wrong,  I really do like Opnsense and
has been running it for many years and have no
plans of swapping.

Best regards
Dan Lundqvist
Stockholm, Sweden
#8
Since upgrade to OPNsense 23.1.1_2, VPN: IPsec: Status Overview shows ALL Remote IP as "%any".
Also the IPSec Widget shows  "%any" in the "(...)

Br Dan Lundqvist

UPDATE: Seems to have been solved in 23.1.3
Now updated with "0.0.0.0/0,::/0" both in IPSec Status and in Widget.
#9
Quote from: EdwinKM on October 01, 2022, 10:00:53 AM
Does Synology has some ACPI options to enable?

Nope, not that I have found.
It is based on a Intel Celeron J4125 2GHz but don't  have access to any BIOS settings as it boots up nativly.
Have not found any settings for it in GUI.

I have even tried "shutdown -p now" from commandline in OPNsense and it still does not shutdown the VM as seen in the VM Manager in Synology. :-/

Have tried both legacy and UEFI....
It is a bit of a bummer. :-|

I am not saying it is a fault in OPNSense, don't get me wrong.

Bst regards
Dan Lundqvist

UPDATE:
Just as a test (to see if FreeBSD could shutdown VM in Synology at all) I installed latest pfSense in a VM.
An then tried to shutdown VM from Synology VM manager and it both started the shutdown in pfSense window also managed to shutdown completly so Synology VM and FreeBSD are able to do it.
I tested with the exact same VM for both installations just to compare apples and apples.

(yes, I know, opnsense vs pfsense battle/flamewar. Don't worry. I made the decision to go away from pfSense to opnsense and have no plans on going in the oposite direction. :-)

I checked the difference in FreeBSD version
OPNSense: FreeBSD 13.1-RELEASE-p5
pfSense: FreeBSD 12.3-STABLE

Conclusion: 
pfSense on FreeBSD 12.3 stable are able to shutdown OK but opnsense on FreeBSD 13.1 p5 is not.
Reason unknown right now.
Same Synology HW/SW, Same VM BIOS, Same VM settings.

UPDATE2:
I have now tested the following to see if any of them works:
OPNsense 21.1   FreeBSD 12.1 (HardenedBSD)          OK, shuts down and power off OK.
OPNsense 21.7   FreeBSD 12.1 (HardenedBSD)            OK, shuts down and power off OK.
OPNsense 22.1   FreeBSD 13-STABLE                  NOK, does not power off.
OPNsense 22.7   FreeBSD 13.1-RELEASE               NOK, does not power off.


Conclusion: Something has changed between FreeBSD 12.1 -> FreeBSD 13 (and/or OPNsense 21.x -> 22.x) causing it to stop working in shutting it down when running in Synology Virtual VM. (QEMU/KVM). :-/

Found the following thread. Will try the settings to see if it helps.
https://forums.freebsd.org/threads/cannot-shutdown-reboot-after-upgrade-to-13-0-release.80199/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253175

Disabling the USB interface seems helping it to get stuck in uhub0: detached indefinetly and is now able to shut down OK.  Also added the tunable "hw.kern.efi.poweroff=0" but that on it's own did not help. Only by disabling USB interface.
Adding the tuneable "hw.usb.no_shutdown_wait=1" but did not help as long as I have USB hub enabled.
Only swithing USB hubb off helps it to truly shut down. Lucky for me I do not need the USB hub in my VM.

I think someone needs to look into this as it seems to be more people having same issue on FreeBSD 13 and it seems to be related to that

Seems like the issue is related to that it won't shutdown the VM. It waits at uhub0: detached indefinetly.
t seems there are situations in which a none USB related issue is at work (referring here to SirDice's post #3), preventing the machine to power off. 

A comment regarding running in VirtualBox VM they stated
"Setting the VM's system chip set to ICH9 (instead of the default PIIX3), with enabled USB controller, and default hw.efi.poweroff=1 the VM powers off immediate after uhub0: detached.
Apparently there is a relation between the chip set in use and a complete power off of the VM."
#10
Hello,

I have an issue that has been going on now for some time that is very anoying and still after 22.7.6 upgrade persists.

BACKGROUND:
I have 4 IPsec tunnels (one standard and 3 VTI) and a OpenVPN Server configured

PROBLEM:
What happens is that every time I reboot the opnsense, two of the static routes configured gets corrupted and selects a different gateway. Happens every time I reboot. If I remove and set them up again the routing table becomes correct and routing starts working OK.

After REBOOT
Destination             Gateway              Flags    Use     MTU     Netif         Netif(name)
192.168.10.0/24     192.168.121.2   UGS     NaN     1500   ovpns1     OVPN_SERVER
192.168.20.0/24     192.168.121.2   UGS     NaN     1500   ovpns1     OVPN_SERVER

After reconfigure 192.168.10.0 and 192.168.20.0
Destination             Gateway              Flags    Use     MTU     Netif         Netif(name)
192.168.10.0/24     link#8                 US        NaN     1400   ipsec1     HENRIK_VTI
192.168.20.0/24     link#9                 US        NaN     1400   ipsec3     HENRIK_MAMMAPAPPA_DIREKT

Have tried all sorts of things but problem still persists and ONLY one these two routes...
Feel it is a bug lurking...

Has anyone else seen this problem and could someone at opnsense have a look.
I have attached some screenshots and logfiles.

Contact me with pm for more screenshots, logs and I could include the config.xml as well.

UPDATE:
I have now found the culprit.

I had a by misstake defined a bunch of networks in OpenVPN Server config "IPv4 Remote Network" which caused it to highjack these nets towards the ovpns1 interface instead of the one I had defined in the routing table. Problem is now solved...




Best regards
Dan Lundqvist
Stockholm, Sweden
#11
Is there no one who has stumbled on to this problem running OpnSense in a Synology VM ?

I do have the OpnSense plugin "QEMU Guest Addon" installed.  Even tried to re-install but same result.

Best regards
Dan Lundqvist (mrzaz)
#12
Hello,

I am trying to run OpnSense in a Synology DS920+ Virtual Manager VM which works OK. No problems.
However, I have some issues with halting OpnSense. It halts Opnsense but does not halt the VM itself.
Tested from the GUI and CLI to shut down OpnSense.

Have tested to install the QEMU plugin in OpnSense but no difference.
- Operating System = Other (as i am installing a VM containing FreeBSD)
- Legacy BIOS
- Setup 2 vSwitch entries with WAN in one (LAN2) and LAN in the other (LAN1) and added 2 NICs. Both VirtIO.
- 1 CPU (during testing)
- videocard vga
- Normal priority

All works OK with the VM, just the halt that does not halt the VM itself, only the content of the VM (OpnSense).
Anyone have any ideas how to get this working OK ?

Best regards
Dan Lundqvist (mrzaz)
#13
Development and Code Review / Re: APC UPS new plugin
February 01, 2022, 08:52:02 AM
Hi,
This could already be done if you click on "advance mode". 🙂

Best regards
Dan Lundqvist (mrzaz)
#14
Development and Code Review / Re: APC UPS new plugin
August 26, 2021, 03:13:37 PM
Hello,

I have joined Droid999's small team of developing the Apcupsd plugin and the current version in external repo works OK now. Have tried to help Droid999 to squash some issues found.

I am in the process to do some cleanup, preparing the plugin to be migrated into the official opnsense_plugin repo.  Have not planned a official date yet for the move as I may need some help with the GitHub migration so we don't screw anything up or loose some data. If someone is good in doing that, please contact us through PM. :-)

Best regards
Dan Lundqvist (mrzaz)
#15
Hello,

I have found a reproducible bug with IPSec Routed and a routing entry getting lost causing issues to ping/reach remote tunnel-IP.

Prerequsit:
- Tested with 21.1.4
- Setup IPSec Routed in both end. 
example:
I have a IPSec routed net with phase1 and phase2 setup with a tunnel-net 10.6.110.0/30.
Router1   10.6.110.1/30     (LAN: 192.168.120.221/24)
Router2   10.6.110.2/30     (LAN: 192.168.120.231/24)
- Have enabled "Dynamic gateway policy" and it has created the Dynamic Gateways in the gateway tab.
- I have also added rule on IPSec+VTI_ifc+LAN with a "Allow Firewall to respond to pings"
  Dir: in, IPv4, ICMP, Any, This Firewall
- Configured the dynamicly created gateways with "Far Gateway"

1. restart routers. Both routers have the following entries. (reversed order in router2)
Destination        Gateway            Flags     Netif Expire
default            178.132.73.97      UGS      vtnet0
10.6.110.1         link#7             UHS         lo0
10.6.110.2         link#7             UH       ipsec1

2. Go to Gateways and edit the dynamic gateway created from IPsec.

3. Untick the "Disable Gateway Monitoring" and enter the tunnelIP on the other side and press APPLY.
(eg. 10.6.110.2)

4. Go to Gateways and edit the dynamic gateway created from IPsec again.

5. Tick the "Disable Gateway Monitoring" and remove the tunnelIP so editbox is blank and press APPLY.

6. Now the routing table has lost one entry. (the "10.6.110.2         link#7             UH       ipsec1"
Destination        Gateway            Flags     Netif Expire
default            178.132.73.97      UGS      vtnet0
10.6.110.1         link#7             UHS         lo0

This is a bug.

Have now been issued in:
https://github.com/opnsense/core/issues/4888

Also another issue seen is that even when both entries exists and you could ping the remote tunnel IP both from commandline or through OPNSense webgui, if you enable gateway monitoring the monitorIP shows as blank and Gateway also blank and it is always OFFLINE.

I found the following in github that looks like the problem.
https://github.com/opnsense/core/issues/4676

In pfSense, from where I am currently migrating from to OPNSense (which will be my router to use in the future), the IPSecRouted dynamicly created gateways always picks up and shows the Gateway IP and the Monitor IP even if IP says "dynamic".  This could possible be an additional bug.

Best regards
Dan Lundqvist
Stockholm, Sweden