Messages

46

18.7 Legacy Series / Re: Thunderbolt or USB-C Ethernet Performance and/or interface recommendations

« on: August 15, 2018, 08:23:45 am »

Rather than spending more money on trying to make this work, wouldn’t it be wiser to replace the NUC with a quiet small form factor slim PC with dual Intel nics on a PCI-card? They can be very cheap second hand. Or one of the Qotom boxes. Your Realtek adapter may be the problem here (poor drivers in FreeBSD) and I don’t know if you can find a well supported one (Intel) on USB in the 1st place. Also depending on what NUC you’ve got, but the more recent ones have pretty beefy graphics etc - better suited as a HTPC than a headless router...?

47

Hardware and Performance / Re: Home Gigabit Setup - Best value hardware recommendation

« on: August 06, 2018, 10:44:45 pm »

+1, got one of those (in i5) too and it works well. Runs a little hot in its cupboard in hot summer ambient temperatures (30ish C ambient) but solved that with small USB fan against the case. Sort of defeats the purpose of the otherwise fanless design, but oh well. Haven’t tried replacing the CPU thermal paste.

Speed wise I can push approx 800Mbit with IDS enabled. Haven’t speed tested VPN.

48

General Discussion / Re: Exporting LetsEncrypt Certificates in Automated way

« on: June 09, 2018, 09:46:04 pm »

Gazd25, you may want to avoid storing passwords in scripts as well, not the least kept on hosts that are also public web servers. You could avoid passwords by using certificates, although that still doesn’t change the fact that an attacker who gains control over the web server can still access the router. How about doing it the other way around, and pushing the certs from opnsense onto the windows server as opposed to pulling them? If only you can figure out a mechanism for that in Windows, I guess ssh may be tricky, maybe an ftp server? Scripting and automation is easy on the unix side.

49

General Discussion / Re: Exporting LetsEncrypt Certificates in Automated way

« on: June 08, 2018, 10:28:40 pm »

Ok here they are.

fetch-push.sh (runs weekly on a command & control Linux VM on the lan via cron):

Code: [Select]

#!/bin/bash
function age() {
   local filename=$1
   local changed=`stat -c %Y "$filename"`
   local now=`date +%s`
   local elapsed
   let elapsed=now-changed
   echo $elapsed
}

/root/pki/fetch.sh
# push new certs if less that 7.5d old
if [ $(age "/root/pki/cert.pem") -lt 648000 ]; then
        /root/pki/push.sh
fi

fetch.sh

Code: [Select]

#!/bin/sh
rsync --checksum -Ltve 'ssh' root@192.168.xx.yy:/etc/letsencrypt/live/[mydomain]/* /root/pki/

push.se

Code: [Select]

#!/bin/sh
echo Pushing config
scp /root/pki/*.pem root@192.168.aaa.bbb:/etc/pki/tls/letsencrypt/
scp /root/pki/*.pem root@192.168.ccc.ddd:/etc/pki/tls/letsencrypt/
[...]
echo Restarting remote services
ssh root@192.168.aaa.bbb "systemctl restart postfix"
ssh root@192.168.aaa.bbb "systemctl restart dovecot"
ssh root@192.168.ccc.ddd "systemctl restart apache2"
[...]

192.168.xx.yy is the web server that also runs the LetsEncrypt certbots hence generates certificates
192.168.aaa.bbb is an email server
192.168.ccc.ddd is another web server

50

General Discussion / Re: Exporting LetsEncrypt Certificates in Automated way

« on: June 08, 2018, 01:09:25 pm »

I had a similar problem. LetsEncrypt cert bots running on public web server, every time certs being refreshed they need to be distributed around a few more servers (another web server, a smtp server, etc). I solved it by writing a small script which runs weekly, checks the last-modified date on the cert files, and if less than a week old redistributes them to the other servers and remotely restarts the relevant services to pick up the new certs. Was pretty easy to do with a combination of ssh and scp, at least in an all-unix environment. I can paste the script here later if of interest.

51

General Discussion / Re: Access from LAN to DMZ

« on: April 17, 2018, 09:28:18 pm »

Ok so... I've continue to look at this and haven't found the answer but have narrowed it down.

First of all the rejects from the logs appear to be a red herring and basically this: https://forum.pfsense.org/index.php?topic=39960.0.

I've further noticed that it's only one particular host which is problematic namely my FreeNAS server. Troubleshooting with iperf3, I can iperf from a MacBook Pro and from Windows 10 to other hosts (Linux VMs) on the same subnet and across subnets (via opnsense) in all cases consistently at around 940MBit/s, so as expected.

The FreeNAS server has two physical NICs, currently one on LAN and one on DMZ. When I iperf3 to the same subnet I get the same consistent 940MBit. However when I cross subnets - from LAN to DMZ or the other way around (for testing) I get something like this:

Code: [Select]

foo$ ./iperf3 -c 192.168.200.10
Connecting to host 192.168.200.10, port 5201
[  4] local 192.168.1.174 port 49559 connected to 192.168.200.10 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec   210 KBytes  1.71 Mbits/sec                 
[  4]   1.01-2.01   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   2.01-3.01   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   3.01-4.00   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   4.00-5.01   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   5.01-6.00   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   6.00-7.01   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   7.01-8.00   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   8.00-9.01   sec  0.00 Bytes  0.00 bits/sec                 
[  4]   9.01-10.00  sec  0.00 Bytes  0.00 bits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec   210 KBytes   172 Kbits/sec                  sender
[  4]   0.00-10.00  sec  65.0 KBytes  53.3 Kbits/sec                  receiver
Not good! Something along the way, or the FreeNAS server itself, is throwing away packages. There is nothing in particular that I can see in the opnsense nor in the FreeNAS logs, and I don't really know how to troubleshoot this.

FreeNAS runs on FreeBSD 11.1.

Help...?!

52

General Discussion / Access from LAN to DMZ

« on: April 14, 2018, 06:37:04 pm »

Hi! I've got a weird problem and can't figure out what I'm doing wrong.

Setup:
LAN: 192.168.200.1/24
DMZ: 192.168.1.1/24

When I'm done I'm going to let LAN access DMZ but not the other way around. For now I've left the default LAN "pass everything" and added the equivalent for DMZ (interface DMZ, source DMZ net, dest any, action Pass).

However when I access DMZ from LAN I get dropouts and timeouts (e.g. when setting up NFS connection). Debugging this, accessing a web management GUI in the DMZ from my laptop on the LAN, some packets are let through on the basis of the default LAN rule but then some dropped on the default deny, and I can't see the reason for this at all.

See attached opn1.jpg screenshot from the Live View firewall log and opn2.jpg from the drill down of one of the blocked connections - how can that not be caught by the same default pass rule?

Also, I don't understand why "default allow LAN to any" comes in pairs with DMZ "let anything out from firewall itself".

Totally stumped on this so would appreciate pointers!

53

General Discussion / Re: Opnsense as Internet gateway for IPSec road warriors

« on: March 20, 2018, 08:58:26 pm »

Need to set "Local Network" to 0.0.0.0/0, instead of LAN subnet, for the routing to be set up properly at the client side.

I confirm it's NOT working with "IPsec net". Yet, does it work with CIDR notation of VPN segment? I expect to, but I'm not sure if default GW works as if you're in the LAN itself. Would you please test again this particular point, and write back? Thank you!

No, setting the CIDR of the VPN (10.10.0.0/24 right?) does not work either. Needs to be 0.0.0.0/0 for it to route properly...

54

General Discussion / Re: Opnsense as Internet gateway for IPSec road warriors

« on: March 20, 2018, 10:53:34 am »

I figured it out...!

Need to set "Local Network" to 0.0.0.0/0, instead of LAN subnet, for the routing to be set up properly at the client side. Also needed to add access from the IPSec subnet to the Unresolver DNS config.

Now it works as expected... Clients can connect via IPsec (tried iOS and Mac OS) and access the local LAN as well as use this opnsense instance as Internet gateway (NAT).

This was poorly documented.. No help text available in the GUI at all, and no mentioning of this in the docs either. Found the solution from a pfsense blog combined with trial-and-error and clicking around in the GUI. Could be improved...

55

General Discussion / Opnsense as Internet gateway for IPSec road warriors

« on: March 18, 2018, 04:45:16 pm »

Hi! First post on the forum. Just installed opnsense on a Qotom i5 mini pc at home and got it up and running fine (as router + firewall). I also managed to configure IPSec for road warriors as described here: https://wiki.opnsense.org/manual/how-tos/ipsec-road.html. All good so far and very happy!

There is however one thing I cannot figure out. When I connect to my opnsense firewall via IPSec (as road warrior) I would like to access my LAN (works) but also use my opnsense as Internet gateway (i.e. NAT through the WAN as if I would have been on the internal lan already). I cannot figure this out.

My setup:
VPN -> IPSec -> Mobile Clients; Virtual Address Pool = 10.10.0.0/24, DNS Servers = 192.168.1.1
Firewall -> Rules -> IPSec; single rule allowing anything to anything on the IPSEC interface
Firewall -> NAT -> Outbound; Hybrid outbound NAT rule generation, added a rule Interface = WAN, Source address=10.10.0.0/24, Translation / target = Interface address.

With this, I can connect to the VPN from an iOS client and successful access the LAN. When I try to load external pages from iOS Safari, I can see the connections being let through in Firewall -> Log Files -> Log view however iOS does not get any response and eventually times out.

I cannot figure this out... Would appreciate some pointers!

I'm running OPNsense 18.1.4-amd64 by the way...