Messages

Hi,

I've been looking at making a number of changes to the improve my Opnsense IPS performance. I have seen a number of suggestions with sample loader.conf.local files etc. It got me thinking about how I might safely test these without hosing my system. I have been trying to find some way of specifying an alternate loader.conf file to no avail but did wonder if nextboot might be the way. Can I use nextboot.conf as a temporary loader.conf.local? I can't find it being used to test anything other than an alternate kernel but hoped it would work for me in this case.  Has anyone got any advice?

Anyone who is interested please vote.

I have managed to get Sky Broadband working with a 3rd party DSL modem and Opnsense while managing to keep my existing SR203 router (the latest Sky Q hub).  I am more than happy to share this set up with anyone who would be interested. I have attached an image of the high level setup and am preparing a detailed runbook for anyone who might be interested. FYI, The SR203 router (from SKY) is properly connected with a (private) WAN address and has 3 green lights including the internet light, it is acting as a router for the Sky Q MESH.

Hi,

I have the same issue.  I did manually add a gateway (system->gateways->single) and this seems to make it more reliable but again I would also be interested in how this can be resolved so that a manual gateway isnt required.

OK - that's fair enough. TBH I am getting pretty good results from my usb hdd so I am not too bothered.

Thanks for the clarification.

Since this was my first post.. I am wondering if I posted this in the right forum?

Can you set the "Enforce local group" under VPN -> OpenVPN -> Servers -> [server]  Settings? 

If so then create a group .. say 'vpnusers' and add your vpn users to this group and specif that group inthe above. This should ensure that only users who are a member of a specific group can connect via VPN..

NOTE - This will only work for servers using Local Database for Authentication (with TOTP as well) as far as i know although i have not fully tested this so see if radius users could be similarly restricted.

This should at least prevent users who are not 'vpn users' - who can have their own group from connecting...

One thing that might help in understanding this problem is the distinction between 'client' and 'user'.  The Client certificate that is specified in the VPN 'Client Config' is actually called a user certificate which is probably where some of the confusion starts.  I also note that despite the "User Authentication Settings" section of the Clients config you can authenticate with any valid user subject to the group membership enforcement (see above) which is a little distracting but I think this may be used when you disable user auth on the server.. which may be a way round this but will need testing.

So.. the client config specifies the client  (machine / endpoint) that is authorized to connect to your vpn... only endpoints with the certificate can even attempt to connect successfully. Then you have an added layer of 'users' who can connect.. and these can be restricted to a specific group. I don't think there is a way to prevent a legal user from connecting via another users client through any standard means...  However there are some resources around that suggest you can TAG connections with the username so as to create a specific set of firewall rules etc on a per user basis if you so wish...  https://forum.netgate.com/topic/111272/limit-openvpn-access-for-certain-user-to-only-certain-ip-in-the-local-network may also provide a way round this:

I think that's 'just how it works'.. no bug as far as I can tell here.  I hope this makes sense.

One thing to add - with certificates./. something I noticed with moving from pfsense.

In Opnsense, when creating user certificates, using an internal CA.. remember to use the "Create Internal Certificate" option and do not create a CSR and sign it using the OpenVPN-CA as this ends up with an external user cert which is not associated with the OpenVPN CA.. even though it was signed with with the CA cert... if you do this then the user certificate does not appear in the client export section.. pfSense seems to handle this differently, thohught it was worth a mention here.

Did you create separate user certificates for each client?

gdur,

It's pretty simple  - when setting up the OpenVPN server you can still follow these instructions but when you get to "Setting up the TOTP Server" do not set up a TOTP but instead, under VPN->Openvpn->servers, select the "Local Database" as the "Backend for authentication".

When adding the user, do not bother with TOTP seed and you can then use the username/password only to authenticate. 

That said, the TOTP setup is really easy and much more secure - I would seriously consider it.

Dear Forum,

I am in the process of migrating away from pfSense to Opnsense and have run into a minor issue that I have been unable to resolve. So far I have spent a few days and trawled the forums to no avail so I thought I would post to see if anyone can help.

I am using the following hardware:

CPU: Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz (1440.00-MHz K8-class CPU)
4GB RAM
Intel Bay Trail/Braswell eMMC 4.5/4.5.1 Controller with 60GB MMC/SD

Opnsense Release: 19.7[11.2-RELEASE-p14-HBSD]

I have had this up and running on the latest pfSense release 2.4.4-p3 outwith the nagging UART issue that initially prevented the system from booting (solved with unsetting hint.uart.1.at).

I then wanted to move to Opnsense - for the usual reasons but have run into another issue with the MMC/SD not being recognized.   I have so far been able to install to an external USB drive which has at least got me off pfSense but I'd really like to get the MMC working. I know it was working on the pfSense release.

I am guessing that this may be because there is some issue with FreeBSD 11.x and that 12.x solves the issue, this being the primary difference between Opnsense 19 and pfSense 2.4.4 but having spent a long time looking at various threads both here and on freebsd.org etc it does seen to suggest that eMMC support should be there.

I have run a boot -v with the following settings in /boot/loader.conf.local:

hw.mmc.debug=2
boot_verbose=1

and attach the boot log.  I can see if recognizes the card OK:

mmc0:  card: MMCHC S0J38Y 1.0 SN 0816F9A4 MFG 10/2018 by 19 0x004e

but the subsequent log entries suggest that it's not attaching in the end:

mmc0:  quirks: 0
mmc0:  bus: 8bit, 200MHz (HS400 with enhanced strobe timing)
mmc0:  memory: 122142720 blocks, erase sector 1024 blocks
mmc0: REQUEST: CMD7 arg 0 flags 0
mmc0: REQUEST: CMD2 arg 0 flags 0x67
mmc0: CMD2 RESULT: 1
mmc0: REQUEST: CMD2 arg 0 flags 0x67
mmc0: CMD2 RESULT: 1
mmc0: REQUEST: CMD2 arg 0 flags 0x67
mmc0: CMD2 RESULT: 1
mmc0: REQUEST: CMD2 arg 0 flags 0x67
mmc0: CMD2 RESULT: 1
mmc0: REQUEST: CMD7 arg 0x20000 flags 0x1d
mmc0: REQUEST: CMD7 arg 0 flags 0
sdhci_acpi0-slot0: Divider 250 for freq 400000 (base 200000000)
mmc0: setting transfer rate to 52.000MHz (dual data rate timing)
mmc0: REQUEST: CMD7 arg 0x20000 flags 0x1d
uhub0: 13 ports with 13 removable, self powered
random: harvesting attach, 8 bytes (4 bits) from uhub0
mmc0: REQUEST: CMD6 arg 0x3b90101 flags 0x1d
sdhci_acpi0-slot0: Divider 250 for freq 400000 (base 200000000)
mmc0: REQUEST: CMD13 arg 0x20000 flags 0x15
mmc0: REQUEST: CMD7 arg 0 flags 0
sdhci_acpi0-slot0: Divider 2 for freq 50000000 (base 200000000)
sdhci_acpi0-slot0: Divider 2 for freq 50000000 (base 200000000)
mmc0: REQUEST: CMD7 arg 0x20000 flags 0x1d
mmc0: REQUEST: CMD8 arg 0 flags 0x35 data 512
mmc0: CMD8 RESULT: 2
mmc0: REQUEST: CMD8 arg 0 flags 0x35 data 512
mmc0: CMD8 RESULT: 2
mmc0: REQUEST: CMD8 arg 0 flags 0x35 data 512
mmc0: CMD8 RESULT: 2
mmc0: REQUEST: CMD8 arg 0 flags 0x35 data 512
mmc0: CMD8 RESULT: 2
mmcsd0: Error reading EXT_CSD Bad CRC
device_attach: mmcsd0 attach returned 6

I cant seem to get any further forward.. I would really appreciate any help.