Messages

16

Hardware and Performance / Re: I guess Intel Chipset H110 is still a little to new! Solved in FreeBSD 11

« on: August 26, 2016, 06:38:28 pm »

Just did a quick and simple SSL benchmark test: VMware ESXi 6.0 vs. bare-metal (no VM)
CPU Pentium G4400T 2,9Ghz:

ESXi:
#openssl speed -engine cryptodev -multi 2 aes-128-cbc aes-192-cbc aes-256-cbc
aes-128 cbc     231313.74k   256633.05k   261830.53k   265155.24k   264773.63k
aes-192 cbc     194559.56k   213654.85k   214607.02k   220203.69k   220585.98k
aes-256 cbc     169802.58k   182031.75k   186861.23k   188047.02k   188506.11k

Bare-metal:
#openssl speed -engine cryptodev -multi 2 aes-128-cbc aes-192-cbc aes-256-cbc
aes-128 cbc     232662.34k   257887.64k   264367.02k   265849.76k   267400.53k
aes-192 cbc     197960.09k   215825.92k   219986.86k   221652.99k   222325.42k
aes-256 cbc     171786.18k   185165.18k   187883.29k   189288.79k   189964.29k

I would say the difference will not be noticeable, nice!
Didn't test network transfer...maybe that will show a bigger difference......but that that's must be another day

17

General Discussion / Re: opnsense-bootstrap -- interoperability made easy :)

« on: August 26, 2016, 10:10:20 am »

Can I install OPNsense on freeBSD 11 using bootstrap?
Why?: It seems I have some hardware compatibility issues in regards to FreeBSD 10.3, it takes forever to boot from USB but ver. 11 boot just fine.
Board: Asus H110T, chipset Intel H110.

I've tried to use bootstrap but got this:

root@opnsense2:/tmp # sh ./opnsense-bootstrap.sh
Must be a FreeBSD 10.x release.

*UPDATE*
Problem solved....on my board the bootloader is failing unless using UEFI. And to make UEFI work I had to disable the Win10-sercure-bios-boot-whatever-stuff.
Now I can boot FreeBSD 10.3 :-)
No work-around needed anyway :-P

18

Hardware and Performance / I guess Intel Chipset H110 is still a little to new! Solved in FreeBSD 11

« on: August 25, 2016, 09:16:49 pm »

Just bought an Asus H110T (H110 chipset). Slim-ITX, 2xLAN (1xIntel & 1xRealtek), DC power and support for the newest gen. 6 CPU (socket 1151)....price around 75$.
CPU:Celeron G3900T or Pentium G4400T (both 35W and AES-NI)..42$/64$.
Seem to be a nice kit for OPNsense for a good price.

But current stable FreeBSD 10.3 it VEEEEERY slow booting from install USB. I tried the 11 and that's boot just fine.
Current version of pfsense and OPNsense, same problem, very slow (as expected as the problem seem to be related to FreeBSD 10.3).

Maybe I should play around with VMware ESXi until 11 is implemented in OPNsense?

*UPDATE*
Problem solved....on my board the bootloader is failing unless using UEFI. And to make UEFI work I had to disable the Win10-secure-bios-boot-whatever-stuff.
Now I can boot FreeBSD 10.3 :-)
No work-around needed anyway :-P

19

General Discussion / Re: [HOW-TO] Using TOTP? Forced renegotiation every hour (disconnect)

« on: August 19, 2016, 01:43:29 pm »

I do agree. IMO I believe 1 hour would be too short for the waste majority of TOTP users.
So one could argue that most TOTP users need to change this option.

I tried to use the Client Specific Overrides but when I did a client export the "reneg-sec 36000" was not included in the config file (I expected that to be the case?).....I could have made a mistake,  but I did specify the right server ;-)

Not that I would use the Client Specific Overrides anyway (I would just edit the config-file directly)

20

General Discussion / [HOW-TO] Using TOTP? Forced renegotiation every hour (disconnect)

« on: August 19, 2016, 12:21:45 pm »

It had some problems with all my VPN clients disconnecting every one hour.
It seems the default is to forces a renegotiation every 3600 seconds.
This option control this: reneg-sec N
I assume this is especially a problem when using Timebased-One-Time-Password (e.g. Google Authenticator) as this renegotiation cannot be done automatically as a new TOTP pin-code needs to be applied.

It seems this option has to be set on both server and client, and it cannot be pushed by the server!

VPN Server:
Add this in the advance option box:

Code: [Select]

reneg-sec 36000;
VPN client:
Add this option to the config file:

Code: [Select]

reneg-sec 36000
This will force a renegotiation  every 10 hour

21

General Discussion / Re: [SOLVED] DNS

« on: August 19, 2016, 11:23:31 am »

OK, thaaaaanks :-)

I'll receive my test-firewall next week and then I'll test it.

22

General Discussion / Re: [SOLVED] DNS

« on: August 19, 2016, 10:22:05 am »

My VPN clients cannot get in touch with the DNS Resolver, it only works if I use the DNS Forwarder.
It almost seems like the DNS Resolver doesn't listen on the adapter where unencrypted VPN packets are sent/received (assume that's the TUN adapter?)
"Network Interfaces" is set to All in the DNS Resolver settings.

DNS Resolver works perfectly with LAN clients.

Is it just me having this problem, or is it by-design/on purpose?

My setup router

Code: [Select]

LAN IP:            192.168.1.0/24
VPN client subnet: 192.168.2.0/24
WAN public IP:        86.x.x.x


23

16.7 Legacy Series / Re: OpenVPN: VPN clients no access to LAN network

« on: August 19, 2016, 09:52:30 am »

Okay....sometimes it help to think "out-of-box" and use what's left of your brain!
Everything works perfectly out-of-the-box....why I had problems was because I forgot I only allowe my local lan client to answer ping and SMB-share packets from the local subnet in the Windows firewall.
And when I ping from the VPN client, which is located on another subnet, it didn't get any reply.

Dammit! I wasted a lot of time because I thought it was related to the OpenVPN configuration :-(
Forget everything I wrote in this thread :-P

24

16.7 Legacy Series / OpenVPN deamon crashes easily setting a wrong option

« on: August 19, 2016, 09:37:39 am »

In OpenVPN Server configuration, if you add an option in the Advance box and you make a typo, the OpenVPN doesn't give you an error, it just crashes :-(

That's especially sad when you do this remotely connected by VPN - no way to reconnect :-(

25

General Discussion / Re: Immortal ghosts from the past

« on: August 09, 2016, 01:11:36 pm »

In short, you want to implement a timeout, so users connected by VGA or serial can skip the SSH enabling?
You are right, that would make a more secure setup process.
But this timeout feature come with a price: extra coding and hassle for the users who don't wanna bother with monitor, keyboard, serial etc.
Is it worth it? And is this really a real problem?

You're not force to connect it to you insecure LAN until the config is over....for those who are stressed about it.
You're in most cases sitting in front of it anyway, if using VGA or serial.

26

General Discussion / Re: Immortal ghosts from the past

« on: August 09, 2016, 12:11:37 pm »

I agree.
I'm not talking about having SSH is enabled when the installation starts, that's implicit ;-)
But after.....if anyone find that to be a problem. Then it could be a way of making sure no one have SSH enable by default without knowing it in the "normal stage ", so to speak.

But I don't see it to be problem myself at all...but I only got criticism in the threat for suggesting default SSH, that's why, just thinking of a way to make those critical voices more happy :-)

But I'm sure you have much more important things to do than implementing this SSH asking...but if people gets crazy about it, it could be a half-way-solution.

27

General Discussion / Re: DNS

« on: August 09, 2016, 11:11:09 am »

Ahh...it cannot resolve itself!
But it will be fixed in future versions it seems.
It's not a big issue, was just worrying that it was an indication of something else was wrong, but it seems it's by-design for now :-)
Thanks

28

General Discussion / Re: Immortal ghosts from the past

« on: August 09, 2016, 11:00:34 am »

For those who might be in a insecure LAN environment, e.g. an educational institution or other public installations,  they can still make the initial setup using VGA, serial or a  private network. No one are forced to install OPNsense connected to an insecure LAN.
They just need to know!
Perhaps a warning could be placed at the download page "Be aware SSH is enabled in the initial installation process using default root password".

And the install process could ask the user to disable SSH as one of the last setup options/questions.

Maybe this would be an acceptable compromise?

29

General Discussion / [SOLVED] DNS

« on: August 09, 2016, 09:03:42 am »

I have some general questions about DNS setup that I was not able to find in the documentation or in the help-tips in the web-gui:

1: When using DNS Resolver I get an "Server: Unknow" in my reply, why is that? Using the DNS Forwarder I get the name of the router:

Code: [Select]

c:\>nslookup opnsense.org
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    opnsense.org
Address:  37.48.77.141
2: In DNS Resolver/General there is an option called DNS Query Forwarding (unfortunately no help-tip)...what does this option actually do?
If it is disabled it seems some DNS queries are still being forwarded to the external DNS servers from WAN DHCP?

30

General Discussion / Re: Immortal ghosts from the past

« on: August 09, 2016, 07:41:20 am »

Then set web-gui password to the MAC address also....and if not?....then don't set it to to the SSH either of the same reasons.

Why is SSH more insecure than the web-interface....I would say it's the other way around, if any difference.