Topics

Hello,

We have been using a basic IPSec road warrior setup with MS-CHAPv2 authentication for some years successfully.
It is used to make it possible for users to access a few internal networks to e.g. print from home.
Now the need has arisen to have a way for admins to connect in and reach a wider range of internal networks, including sensitive ones.
Obviously, non-admins must not be able to connect into the more sensitive parts of the network.

To accomplish this, I was thinking about creating a separate IPSec connection and limit it to admin users.
But before I can even start, I already see the problem of distinguishing the two connections from the remote end?
Also, I see no way of defining a separate PSK database for the admin users, or restricting/enlarging the set of reachable subnets for any single user.
At the moment, there is just a single MS-CHAPv2 authentication method defined for all users (EAP-ID '%any'), which are all defined in the PSK database (IPSec -> Pre-Shared Keys)

Is it possible to configure this all, ideally using MS-CHAPv2 for users and admins, possibly using separate IPSec connections?
If so, how could this be done?

Hello there,

so we got a new fiber line from our provider, and a modem to go along with it.
Now since we have multiple sites and many internal networks per site, I am using the 10.0.0.0/8 address range.
This new modem that we got will only show its web interface on VLAN 0 in subnet 192.168.100.0/24 though.
While its not that much of a problem to just set the interface up that way, I figured maybe I could just "hide" that network such that, let's say 10.10.10.0/24 will be natted and routed to 192.168.100.0/24.
So instead of pinging the modem at lets say, 192.168.100.2, I could use 10.10.10.2.
This way it fits in with our addressing scheme better.
Also, if we get a second modem for a second line, this way address conflicts could be avoided.

Am I on the right track when I think that 1:1 NAT can help me here?
I tried to set it up but it didn't work, but before I post configs I want to know if I'm even going into the right direction here.

Everyone who read this far, thanks for your time and have a nice day,
Daniel

I've been getting complaints from workers in both our offices that sometimes their network on their win10 machines was unstable.
Upon further inspection, I found that the problem was IPv6, which Windows uses as default if available.
The interface for the office machines is configured with DHCPv6 and the RAs set to "Managed" mode.
The behaviour is weird in that it often gives out IPv6 addresses, but they don't persist for long and keep coming back and going away, which results in unstable connectivity.
In that network, IPv4 is perfectly stable, so I don't suspect a physical problem with the network.
Is this a known problem with this version?
I am looking around for a solution but I think everything is configured right and I don't know what to do besides disabling DHCP6 and trying SLAAC.

EDIT: I forgot to mention that there doesn't seem to be a general problem with ipv6 on the network, because on both locations, we have statically configured ipv6 machines that have stable connectivity, also there is another subnet here that doesn't run in a VLAN which uses DHCP6 + RA "Managed" and it is stable.
So maybe it only happens on the VLAN networks.
Also I tried both the setting "dynamic" and "static" RA but it doesn't seem to make much of a difference regarding stability. Both locations use DHCP static assigned ::56 subnets from the ISP, so both settings should work if I understand right.

Hello there,

can somebody summarize the changes that the wireguard implementation in Opnsense went through from 21.1.3 to 21.1.4 and how they affect existing setups?
I just saw that new wireguard related things like wireguard-kmod (kernel module I presume) will be installed during the update, alongside a very huge version jump in the wireguard package (1.0.20210223 -> 2,1) and I am worried regarding the latest stories about the FreeBSD wireguard kernel code quality.
Our wireguard setup has been working very reliably over the past year or so and I just want to know that it will stay that way in the new version.
Does the new version use a kernel module? Is that the same code with the abysmal quality that caused discussions? Can the old user-mode implementation still be used in the new version?

I just wanted to create a new stage 1 for ipsec since I was having problems with my other one (couldn't get EAP-TLS working with win10) and noticed that weirdly, I can't select the correct auth method!
I can only select "Mutual RSA", "Mutual PSK" and "Mutual Public Key", despite Key Exchange set to IKEv2.
This seems wrong!
For pictures see what I appended. (webif is set to german, but you will still get the point)
I saw a similar issue from 2017, that was supposedly fixed, but I'm starting to think maybe it wasn't fully fixed after all:
https://github.com/opnsense/core/issues/1961
I already had issues with the selection the first time, but somehow it worked then, idk what I did back then to make it show the selections I needed.

Does anyone know what the problem is and/or how to fix it, or at least can point me in the right direction?

Hello, I'm trying for the first time to set up an IPSec VPN for road warriors on Win 10 w/ IKEv2 EAP-TLS.
As expected, it doesn't just work outright, so I tried to get the debug log, but it's always empty!
I also tried setting all log settings to the highest possible, but it didn't help (level "highest")
Even though the IPSec server seems to respond to the connection attempts, because I don't just get connection errors, but authentication failure errors.
BTW, I'm having one system error popping up on opnsense, but IDK if it could be related to IPSec:

[28-Aug-2020 02:04:20 Europe/Berlin] ArgumentCountError: Too few arguments to function OPNsense\OpenVPN\Api\ExportController::accountsAction(), 0 passed and exactly 1 expected in /usr/local/opnsense/mvc/app/controllers/OPNsense/OpenVPN/Api/ExportController.php:204
Stack trace:
#0 [internal function]: OPNsense\OpenVPN\Api\ExportController->accountsAction()
#1 [internal function]: Phalcon\Dispatcher->callActionMethod(Object(OPNsense\OpenVPN\Api\ExportController), 'accountsAction', Array)
#2 [internal function]: Phalcon\Dispatcher->dispatch()
#3 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#4 {main}

From the error message it seems to come from openvpn, but I don't even use it - it's unconfigured and disabled.
Only thing I ever did was click through its menus to see whats going on there, but didn't change anything.
I think that's when the error might have started coming up on my install.

Can someone point me in the right direction what might be going wrong with the debug log?

Hello there, I think I am facing an issue with opnsense 20.1.
Situation is as follows: 2 Sites connected via wireguard VPN, I am pinging from one side to the other and waiting for an answer. The MTU of the wireguard interface is 1400 on both sides.
Following problem occurs: When sending pings that result in packets bigger than 1400 bytes, naturally, the packet needs to be splitted. This is done correctly, and an answer comes back. This answer consists of multiple packets, which I expected, would get merged together and sent back to the pinging machine.
The answer gets lost, though, because the firewall blocks it.
It seems it doesn't expect multiple packets and thus the default block rule for incoming stuff kicks in:

Code Select Expand


# ping -M dont -s 1372 -c 1 10.2.1.12
PING 10.2.1.12 (10.2.1.12) 1372(1400) bytes of data.
1380 bytes from 10.2.1.12: icmp_seq=1 ttl=62 time=40.5 ms

--- 10.2.1.12 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 40.587/40.587/40.587/0.000 ms


Code Select Expand


# ping -M dont -s 1373 -c 1 10.2.1.12
PING 10.2.1.12 (10.2.1.12) 1373(1401) bytes of data.

--- 10.2.1.12 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms


Now the firewall live log for this ping reveals why the answer doesnt come back, which you can see in the attachments. For all even bigger sizes, it looks the same.

Now since I'm not an expert, maybe I misunderstand something here but it looks wrong to me.
Maybe someone more knowledgeable can shed some light on this issue.

The problem: On my box, I noticed that if I ping something that is connected to the physical WAN port (something on the internet or the modem) and the packet is bigger than the MTU, it seems to get dropped (in case of ping: no echo answer). If the packet is smaller though, ping works reliably. To my understanding, the packet should have been fragmented, the fragments being sent over the WAN. Also, e.g. if I lower the MTU on the WAN interface, I can see that also smaller packets will start to get dropped reliably, so I think the opnsense firewall is the culprit.

The system looks like this:

VDSL2 internet connection
^
Modem (Draytek Vigor 165)-----------------------------|
^                                                                             ^
Firewall PPPoE on VLAN 7 (WAN interface)       Firewall VLAN 0 ("Modem" interface only for accessing modem gui)
^                                                                             ^
OPNSENSE (v. 20.1.3)-----------------------------------|
^
LAN interface
^
LAN network

The MTU on WAN interface and on Modem interface are set to default for now. I saw no logs that gave anything useful. Interestingly, ipv6 ping also seems to get lost if packets are too big. As of now, everyday stuff like browsing, VOIP, conferencing or servers dont seem to be affected by this problem, but it seems to me that this is mostly luck and I fear this will bite me when it comes to things like VPN in the future, so I'd be glad if someone can point me in the right direction here.