Netgate SG-1000 microFirewall

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.

Messages - mikeisfly

Pages: [1] 2 3 4 5 ... 33
Packages / Re: LLDP daemon package
« on: February 07, 2018, 10:42:29 pm »
Is this in regard to LADVD? Its working pretty good for me.

General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 10, 2018, 07:05:30 pm »
Also they will have to try to find performance gains another way. Out of order Instruction execution and branch prediction were big deals when they were implemented. Limiting access to a page frame to the process that created it is a way that may be able to fix the issue. Reducing the access to the high resolution clock (if possible) may also be a way to mitigate these timing leak attacks. I'm not a expert though, I just stayed at a Holiday Inn Express last night.

Is that a 100 MBps or 100 Mbps?

Captive Portal / Re: Share your Captive Portal Page
« on: January 10, 2018, 11:04:03 am »
Nice. thanks for sharing

Your welcome.

General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 10, 2018, 11:02:46 am »
As far as I understood, Meltdown and Spectre only affects 64-bit CPUs. 32-bit CPUs are not affected, correct me if I'm wrong.

Respectfully you would be wrong. If your processor does any kind of speculative branch prediction you are in the target zone.

General Questions / Re: Intel CPUs Massive Security Flaw issue
« on: January 03, 2018, 08:08:54 pm »
From my understanding of the problem all x86 processors are effected but the AMD processors have the ability to turn off the branch prediction feature. It would seem to me that if some bioses can be updated to turn this feature off on Intel Processors than the problem can be minimized without the 5% performance hit. We all want speed and putting the Kernel page file and user page file in the same space was a way for them to achieve this. I don't really think it's fair to blame Intel. Security is really hard and I would say the problem is really at the OS level. OS makers are working on the fix now so I would say everyone is doing their job. I would imagine in the future Intel processors will have the ability to turn the branch prediction off which will fix this issue.

Let me preface this with this is more generic WAN advice than specific to pfSense.  I have run across two factors to consider on a WAN IPsec link:  the previously mentioned window size and Path MTU.  And window size hits you twice with SMB.

First TCP window size.   A TCP connection can't go any faster than the product of the TCP window size and 1/RTT, no matter how big the pipe is.  RFC-1323 is a good read on this and provides the solution.  Dig some more to find out how to make sure this enabled on both end points at the OS level.   This is effect of the WAN RTT, not IPsec.  The pfSense boxes and any other routers in between don't come in to play on this issue.

Also SMB has it's own application window size, which really kills you as RTT increases over the WAN, for the same reasons.  I'm not certain if this was ever addressed in later versions of SMB or not, as we threw in some Cisco WAAS devices to work around that protocol, long ago, so I never looked at it again.  Likewise, nothing to do with pfSense or IPsec.

Lastly Path MTU.   IPsec reduces the MTU over the WAN.  More so if are using Tunnel mode, which you probably are.  If the Path MTU discovery methods aren't working correctly, you can lose speed to fragmentation.  You can also have trouble connecting at all, if the application is requesting don't fragment (DF).  I recently encountered this between an AWS EC2 instance and a premises server, going over the VPN.   Couldn't even complete an SSL/TLS negotiation as the cert exceeded the MTU and they were using DF.  Another symptom of this is with an FTP connection.  If you can authenticate the FTP session, but ls, dir and transfers fail, that can be caused by MTU problems.

Path MTU discovery is often broken by blocking the ICMP unreachable messages (in the name of "security"...) or if the tunnel endpoints don't properly setup the tunnel MTU to generate the ICMP unreachables.  I don't know one way or the other about pfSense's handling of tunnel MTU, but hopefully some who does will chime in.  A quick test for this would be to lower the interface MTU on both your application endpoints to say 1300 and see if that impacts the throughput.  You can also use ping with different sizes and the DF bit set to discover the current path MTU.  The lowered endpoint MTU is a quick and dirty hack to workaround this problem.  A slightly less dirty hack is to add MTU information to your routing table manually.  I've done this in Linux, but never looked at doing it in Windows or BSD.  The best solution is to get Path MTU Discovery working properly.

I thought bout a lot of what your saying but reducing the MTU between both tunnels doesn't seem to help. I'm wondering why this problem effects IPsec tunnels but not OpenVPN tunnels to the extent that on OpenVPN I can at least get 100 Mbps, IPSec I'm getting 50 Kbps. I've setup many IPSec Tunnels so I'm almost certain I have it configured correctly. I'm too am hoping something can be done to make SMB work better over these links. Not sure if this is something Microsoft needs to address or something that Pfsense can fix or maybe it's a all of the above deal.

General Questions / Re: pfSense and Ubiquiti
« on: January 01, 2018, 07:33:19 am »
LDAP works with OVPN too.

Development / Re: Roadmap with Cisco's VPP and DPDK
« on: December 31, 2017, 02:49:56 am »
Thanks for the info, I'm glad to see a project that I supported coming of age. The team has worked very hard for years, I'm excited for what the future holds for pfsense. I for one am thankful for what information you have released and will wait patiently for more news to come.

Development / Re: Roadmap with Cisco's VPP and DPDK
« on: December 29, 2017, 06:40:55 am »
I just came across the YouTube video myself and found it interesting, so I searched for it on the Pfsense forums and only saw your post. Looks very interesting and I would love to test it as well. I'm wondering if this performance upgrade feature will only be available with hardware from Netgate or will the enhancements be made available to the community version as well? If not can the performance gains be purchased? This leads to all kinds of questions but I will just leave it there for the moment.

I have mine running on Chelsio 10GBASE-CX4 S320E-CXA 10GbE adapter and everything is working well for me. I am using :

2.4.3-DEVELOPMENT (amd64)
built on Tue Dec 19 18:22:48 CST 2017
FreeBSD 11.1-RELEASE-p6

Which seems to be working well. Don't know if your environment will allow you to run a development branch but it is running very stable and I have not had any issues other than Captive Portal authenticating against LDAP but looks like that will be fixed soon. See

Captive Portal / Re: Captive Portal acting weird in 2.4(2.4.2-RELEASE-p1)
« on: December 28, 2017, 03:06:03 pm »
No, you suspect falsely. I already have my macs added, since the pfSense 2.3.0, because that's when I set my everything up. Now in the upgraded 2.4 the only problem with pfSense is when changing some settings under the CP zone tab and saving those options, then the nginx breaks and I have to restart the machine. The changes ARE ACTUALLY SUCCESSFULLY SAVED.

See bugs in maybe this is the problem that you are running into?

Captive Portal / Re: Captive Portal acting weird in 2.4(2.4.2-RELEASE-p1)
« on: December 28, 2017, 01:24:49 pm »
What I suspect your problem is your are running a captive portal on the same LAN that you are accessing the firewall through. So while you are connected to the pfSense you activate the portal but your state is not dropped. Your mac is not authorized so you are not forwarded to the redirect page and you get the error that you are getting. I bet if you connect another PC, phone or something that was not on the LAN at that time (so it didn't have any open states) that new device will be forwarded to the portal splash screen. The fix would be to clear all your states, but because you can't connect to the firewall you can't do it. That is why restarting pfsense allows you to work once again. Maybe a fix for you would be to create another interface where you can configure the firewall instead of trying to activate a CP on the same interface you are accessing it through.

Captive Portal / Share your Captive Portal Page
« on: December 28, 2017, 01:24:35 am »
I wanted to dress up my captive portal page and looking around the Internet for one, since I'm not a HTML/CSS designer. I found a template that I thought was really nice and the developer shared it on GitHub. I'm sharing it here for anyone else who wanted something better than the built in one. This portal does have a responsive design that will resize depending on the device accessing the Captive Portal. There seems to be a lot of things in the file that are not needed but I haven't really had the time to optimize the file(s).

These guys/gals below deserve all the credit all I did was download their work and change a few lines of code for my needs. I am currently running on PfSense 2.4.3.a.20171227.0927 (Developmental).

You will have to take the .txt files and rename them to .html for this to work for you.
The images are embedded in the file, I encoded them to base64 you can use this site
to encode your img files and edit the code to change the background to what ever you want.

*Did a edit to today to fix all the grammer mistakes. Guess I shouldn't post when I am really really tired.

Pages: [1] 2 3 4 5 ... 33