[pfSense] System stats: HUGE SPIKE, then failed.

[Karl Fife]

There was just now a sudden spike in states, ~100x the normal number, 
maxing out the system max in just an hour, and causing the system to fail.


With a maxed out state table, of course the system fails to process 
traffic.  Has anyone seen something like this before, or have any ideas 
what kinds of things would look like this?


Monitoring PNG attached.

For us, on a normal day, the system hovers around 7-15K states. Just 
before noon today, the system suddenly started adding states at a rage 
of about 9K per minute until the system maxed out (at 800K states in 
just under an hour and fifteen minutes).


Failure mode analysis was difficult because we couldn't access the WebUI 
or SSH becasue (of course) the LAN interface couldn't allocate a state 
for the connection, so we had to restart (hoping to find something in 
the logs.  Logs were not helpful because the circular logs were too 
small (subsequently "embiggened" of course), but more to the point, the 
offending states wouldn't be logged anyway, so that won't tell what IP 
or IP's belong to the offending states anyway.


Going forward:

The ~1 hour window in which to do forensics (when/if this happens again) 
is quite small, so I wonder if there is a way to have growl generate a 
notification when say, states exceed a certain threshold, so we can at 
least pay attention while it's happening.  Any tips on notifications?


Probably irrelevant, but this is: pfSense 2.4.2R p1 AMD64 on a 
Supermicro Rangely/Atom ECC, ZFS


Thanks!
-Karl


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] best ipsec cipher for aes-ni on sg-8860

[Karl Fife]

You might try...

(Wait for it)

...AES.


On 12/9/2017 4:02 AM, Eero Volotinen wrote:

Hi,

What is the best ipsec ciphers for aes-ni ipsec acceleration?

Eero
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Outbound NAT rule editing in 2.4

[Karl Fife]

I was literally about to upgrade one of my from 2.3.x installs and do 
some NAT rule editing.   Whew!  Thanks for pointing this out.





On 10/25/2017 8:00 AM, John Kline wrote:

I’m seeing the same thing adding or editing NAT rules (even after upgrading to 
2.4.1).

- Invalid characters detected fga9b0lcc6mv3&b=3&s=o4. Please remove invalid characters and save again.




On Wednesday, October 25, 2017, 1:43 AM, Doug Lytle  wrote:

On 10/24/2017 10:12 PM, Travis Hansen wrote:

After updating to 2.4 I see this when opening all of my outbound NAT rules:
     - Invalid characters detected "00". Please remove 
invalid characters and save again.

It shows that as soon as I open the rule for editing and also prevents me from 
updating the rules.  Anyone else seeing this?
travishansentravisghan...@yahoo.com
___



I see that 2.4.1 is now available, you may want to update and try it again.

Doug

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Actually, DHCP appears to be broken on a fresh install too

[Karl Fife]

I just applied the newly available 10/9 build.  It seems to have fixed 
my broken install, by rolling forward.



On 10/9/2017 2:21 PM, Karl Fife wrote:

FYI: Clearly caused by this:

https://forum.pfsense.org/index.php?topic=137682.msg752988#msg752988

--- Snip ---
...we'll get a fix out.  In the meantime, installing a current 
snapshot fresh will work since it all matches. Reinstalling and using 
the "recover config.xml" option will have you back up with less effort 
than other solutions.

---   ---

ZFS boot environments could contain this (or any) unforseen 
update/upgrade impact. That's why we run/ran Nano for so long.




On 10/8/2017 1:57 PM, Karl Fife wrote:
Actually, I noticed that resetting to factory defaults, and creating 
a simple test config also results in DHCP not starting. Sounds like 
something more fundamental was broken in RC. I also notice that my 
old Sep 29 image is no longer being offered an update ('on the latest 
version') making me think the issue is known, and the update has been 
pulled.


If anyone is having difficulty reproducing this, please let me know 
and I'll file a bug report with exact steps to reproduce.






___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Actually, DHCP appears to be broken on a fresh install too

[Karl Fife]

FYI: Clearly caused by this:

https://forum.pfsense.org/index.php?topic=137682.msg752988#msg752988

--- Snip ---
...we'll get a fix out.  In the meantime, installing a current snapshot 
fresh will work since it all matches. Reinstalling and using the 
"recover config.xml" option will have you back up with less effort than 
other solutions.

---   ---

ZFS boot environments could contain this (or any) unforseen 
update/upgrade impact. That's why we run/ran Nano for so long.




On 10/8/2017 1:57 PM, Karl Fife wrote:
Actually, I noticed that resetting to factory defaults, and creating a 
simple test config also results in DHCP not starting. Sounds like 
something more fundamental was broken in RC. I also notice that my old 
Sep 29 image is no longer being offered an update ('on the latest 
version') making me think the issue is known, and the update has been 
pulled.


If anyone is having difficulty reproducing this, please let me know 
and I'll file a bug report with exact steps to reproduce.




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Actually, DHCP appears to be broken on a fresh install too

[Karl Fife]

Actually, I noticed that resetting to factory defaults, and creating a 
simple test config also results in DHCP not starting. Sounds like 
something more fundamental was broken in RC. I also notice that my old 
Sep 29 image is no longer being offered an update ('on the latest 
version') making me think the issue is known, and the update has been 
pulled.


If anyone is having difficulty reproducing this, please let me know and 
I'll file a bug report with exact steps to reproduce.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] DHCP appears to be broken after 2.4 Sunday October 8 build

[Karl Fife]

Post update, DHCP service appears to die post update.  Is anyone else 
seeing this?


I'm seeing it on two separate install locations, both running 2.4RC

*2.4.0-RC* (amd64)  built on Sun Oct 08 06:40:54 CDT 2017

both on pcEngines APU2.

Logs say:
rc.bootup: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp 
-chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid igb0' 
returned exit code '1', the output was 'Internet Systems Consortium DHCP 
Server 4.3.6 [...] Config file: /etc/dhcpd.conf Database file: 
/var/db/dhcpd.leases PID file: /var/run/dhcpd.pid Wrote 0 deleted host 
decls to leases file. Wrote 0 new dynamic host decls to leases file. 
Wrote 4 leases to leases file. Can't attach interface igb0 to bpf device 
/dev/bpf0: Invalid argument


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] OpenVPN - Should not delete: direct trust of certificates

[Karl Fife]

Someone feel free to challenge me here, or give a +1

In summary: The pfSense UI should not allow users to delete certificates 
because admins may be unaware of the implications.


In detail:  In OpenVPN, certificates are trusted by way of them being 
signed by the CA (i.e. pfSense), that is, trusted "indirectly" by way of 
the signature.  That makes sense given the fundamentals of 
certificates.  However as long as OpenVPN is keeping a copy of every 
certificate it mints (e.g. in case they they need to be revoked) why are 
the certs not "simply" trusted "directly"?


The problem in my mind is that the UI appears to allow people to delete 
certs that aren't being used by a user, when in fact they should 
absolutely not be.  They should instead be 'revoking' old/unused 
certificates.  In my mind, reasonable assumption would be that that when 
certificate is deleted, it is no valid for use.  This appears to be 
incorrect. I observe that 'deleted' certs are 100% valid, and can to be 
used to login to the VPN server (until the certificate expires).


So my first thought is that the delete button should be changed to a 
REVOKE button.  However it would better in my mind to simply trust ALL 
certs "directly".  This would allow an admin to be 100% aware of all 
trusted "keys to the castle" currently in existence.  As it stands, a 
naive admin could delete certs, (incorrectly believing he has thrown 
away the key), and a rogue admin could 'mint' an unlimited number of 
certs (then delete them) and there would be no record of these 
back-doors the system.


Obviously "direct trust" is not plausible in the application of the WWW, 
but directly trusting certs in a VPN application seems preferable given 
the comparatively small number of certs, as well as the explicit 
(premeditated) nature of granting VPN access.


Am I missing something here?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] GRE interface sows reply traffic in tcpdump, but not passed.

[Karl Fife]

I'm having trouble with NAT'ed traffic through a GRE interface that is 
going over an IPSEC connection.  Pfsense itself can get ping replies 
from the remote end, but the hosts on the LAN can not.  NAT is enabled, 
so the source IP for LAN hosts is the local /30 tunnel address.  The 
irony is that Tcpdump shows ping replies from LAN hosts hitting 
pfSense's GRE interface (NAT'ed), and the states in the state table 
match those of a working NAT'ed non-GRE interface.  There are no 
firewall entries for the source or destination addresses.  I feel like I 
must be missing a concept, or this would be working.  I'm thinking that 
as the tunnel is unwrapped, maybe the IP's may mismatched to the IPSEC 
SA or something?  Any ideas?



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] pfSense 2.4 with ZFS, will it solve corrupt systems

[Karl Fife]

Is setting the copies=2 option slated to be part of the regular 
installer?  I recall copies=2 must enabled after-the-fact from the CLI.  
Enabling after-the-fact is slightly problematic, because ZFS will only 
make multiple copies of NEW blocks written, so in effect the system has 
is without redundancy of most blocks until, say, after a major update.   
I'm running several of these APU2's with discrete drives.


https://twitter.com/karlfife/status/878833005426561024

On 8/6/2017 1:18 PM, Vick Khera wrote:

On Sat, Aug 5, 2017 at 9:07 AM, Jim Pingle  wrote:


On 8/5/2017 8:59 AM, Arthur Wiebe wrote:

This is more out of curiosity to verify that I'm correct, with pfSense

2.4

using ZFS will that solve the issue where an SG appliance will stop

booting

because of a corrupt filesystem and require a reinstall?


ZFS can only protect you from on-disk corruption if you have multiple
copies of your data. So you either need mirror or raidz with multiple
drives, or set the number of copies per block to a number higher than 1 on
a single disk.



I've had too many cases where for whatever reason a box was shutdown
improperly (could be the client unplugging it for example) and the system
became corrupt and worked fine after re-installing the OS.



ZFS is very robust against this particular scenario, because the on-disk
state is always consistent.

The UFS file system journaling is also very robust against this, but does
on occasion need a manual fsck to clean up. I've never had a system corrupt
itself so bad that I had to re-install (running FreeBSD for 18+ years on
dozens of machines).



I'm hoping that ZFS with it's data integrity and rollback features will
solve this issue.

Am I right? And if so we should consider re-installing existing
installations with pfSense 2.4 so that it installs using ZFS?

ZFS is self-healing and though we have not been able to reproduce the
corruption issues seen by some with UFS, all evidence points to ZFS not
being susceptible to those problems.



Will pfSense on a single-disk install set the copies per block to > 1 to
afford additional protection against corruption? Seems like a small price
to pay given how little disk pfSense needs and how big SSDs are these days.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Netgate SG-2220 and Leviton power supply

[Karl Fife]

5 Amps is 60 Watts at 12v.  The SG2220's idle power consumption is a 
mere 6W, which is just half-an-amp.3.333A, is very easily able to 
keep up.


The 5A on the HW spec at Netgate is likely referring to the arbitrary 
maximum amperage that the *included* PSU is capable of.   That does not 
specify the amount the board will draw.  A power supply must only meet 
or exceed Amperage draw of the powered device.  Commonly PS's are often 
over-specified based on convenience/cost and availability.


If you use your Leviton PS, and for some reason it's unable to keep up 
with the SG's peak amperage, it is not going to hurt the SG.  The worst 
case scenario is that the voltage at the PS's will sag/decrease, and the 
router will be unstable.  The same thing sometimes happens as power 
supplies begin to go bad and no longer are able to produce the requested 
amperage.


I suspect that the max draw on that board is WELL under 3 amps. I'd be 
very surprised if it draws 1A under load.


You can almost certainly use it without a second thought.

-Karl


On 8/3/2017 1:30 AM, Moshe Katz wrote:

The page you linked to says that the SG-2220 needs 5A, but you say the
Leviton power supply is 4A. That's probably a bad idea. In fact, according
to the spec sheet though, the Leviton power supply is actually only
3.3A. That's almost definitely a bad idea.

--
Moshe Katz
-- mo...@ymkatz.net
-- +1(301)867-3732

On Thu, Aug 3, 2017 at 2:23 AM, Shivaram Mysore 





Hello,
I have a Leviton Power supply (12v, ~4 Amps) [1] and trying to use it with
SG-2220 running pfSense.  Will the ampere rating be enough.  I could not
get a good read on the same based on the spec sheets for SG-2220.  But,
wanted to confirm.

[1] http://www.leviton.com/en/products/47605-psc
[2] https://www.netgate.com/products/sg-2220.html

Thanks & Regards

/Shivaram
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] 2.1.6 NAT BUG - All rules deleted !!

[Karl Fife]

2.1 won't offer an upgrade if the SSD is too small.  If you have a 1GB 
CF, you will have flash a larger one.



On 6/7/2017 9:16 PM, Alexandre Paradis wrote:

2.3 support 32 bits, 2.4 doesn't.

Tomer, you should upgrade to the latest version.

On Wed, Jun 7, 2017 at 10:01 PM, Ryan Coleman  wrote:


Probably that 2.2 support ended 32-bit boards, IIRC.

Or maybe that was 2.3



On Jun 7, 2017, at 7:46 AM, Oliver Hansen 

wrote:

Is there a reason you're still on version 2.1.6?

On Jun 7, 2017 5:41 AM, "pfsense-l...@y-tech.co.il" <
pfsense-l...@y-tech.co.il> wrote:


Hi all,

I just encountered a major bug:
Adding a new port forward rule caused a deletion of all firewall rules,
ALL.
I restored the configuration from backup and tried to add it again -

same

result.
I can't find any documented bug.
Please advise.

Thanks,
Tomer.


--
This message has been scanned for viruses and
dangerous content by Y-Tech MailScanner system, and is
believed to be clean.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold






___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Chelsio T520 card transciever combatibility?

[Karl Fife]

Does anyone have experience with the Chelsio T520 series of cards 
specifically as it relates to transceiver compatibility?


SFP & SFP+:

We have several applications where we could use these well-supported 
cards, some require use of SFP transceivers (not SFP+) such as 
1000BASE-LX transceivers.  My understanding is that some cards (such as 
the Chelsio cards) can receive an SFP transceiver (negotiating down from 
SFP+) but requires explicit configuration.  Does anyone know if said 
configuration lives in the pfSense (e.g. blown away on reboot).


Aftermarket Transeivers:

Chelsio doesn't make 1000BASE-LX modules, and aftermarket modules appear 
to be marketed toward a particular brand of switch (Juniper, HP, Cisco, 
etc.).  Can I safely assume that they're largely interperable?


Any help would be greatly appreciated.
-K




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] smartctl supporting mSATA controller

[Karl Fife]

Can anyone recommend a good mSATA drive (i.e. controller chip) that 
supports a full suite of smartctl commands, such as an ATA (hdparm) 
secure erase, and self-test?  Many have parital support, and it's really 
hard to find out what support exists short of bench testing.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] SIP through IKEv2-tunnel

[Karl Fife]

Time to do a pcap, and see what's actually happening.   Look in the SIP 
session description (SDP) and see what IP addresses the client is 
telling the other side to communicate with.   Divide and conquer.



On 3/21/2017 5:42 AM, Martin Fuchs wrote:

what really irritates me is the fact (tried it just now) that using it over 
OpenVPN instead of IKEv2 it works...

any idea ?

i'm gonna look over it again...


Von: List  im Auftrag von Martin Fuchs 

Gesendet: Dienstag, 21. März 2017 10:45:34
An: pfSense Support and Discussion Mailing List
Betreff: Re: [pfSense] SIP through IKEv2-tunnel

I think so, too, that's what confuses me.


Internet -> Router -> (NAT: IPSec, OpenVPN) pfSense


so the SIP-Clients would tunnel trough the the router, terminate with the 
pfSense and the unencrypted packets are sent back to the router (which hosts 
the PBX).


In my opitnion it should work, too...




Von: List  im Auftrag von Vick Khera 

Gesendet: Montag, 20. März 2017 13:48:06
An: pfSense Support and Discussion Mailing List
Betreff: Re: [pfSense] SIP through IKEv2-tunnel

You only need siproxyd if you have multiple SIP clients inside your network
trying to talk outside.

SIP should work just fine in your situation where your PBX software and
your client are within the same VPN and do not block any traffic.

That is, I have a situation like this and it works just fine:

Internet <- pfSense NAT <- Switchvox <- local LAN clients

remotes  -> pfSense VPN -> Switchvox


I can't tell from the OP's original description how the connections are
configured.


On Mon, Mar 20, 2017 at 6:10 AM, Eero Volotinen 
wrote:


maybe you need something like this
https://doc.pfsense.org/index.php/Siproxd_package

Eero

20.3.2017 11.56 ap. "Martin Fuchs"  kirjoitti:


Hi !

I have a Fritz!Box (router) connected to the internet (no other
possibility).

In i have NATted ESP, GRE, 4500, 500, 1701, ... to a pfSense VM.

This pfSense VM just operates as a VPN-Gateway.

I have set up the routes in the Fritz!Box for the dial-in networks to the
pfSense.


I can connect via IKEv2 and browse internat services.

I have a Fritz!App (SIP-Client) on my phone.

This app connects to the Fritz!Box (which provides a SIP-connection)
successfully.


When I try to make a call, the other phone rings BUT no party cann hear
the other.


It seems to me like a RTP-issue.


On the pfSense i have Advanced Outbound NAT configured with no NAT-Rules.

The firewall-rules allow IPSec to LAN (any service).

I'm running pfSense 2.3.3p1 with one interface.


Does anyone have any idea or some hint for me ?


regards,

martin
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Routing between interfaces

[Karl Fife]

I'm in the needless complexity is insecurity camp.  Your other 
speculations are baseless.



On 2/11/2017 10:18 AM, Matthew Pounsett wrote:

I see that you're in the "NAT is security" camp, which is unfortunately a
misinformed way to approach network security.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Routing between interfaces

[Karl Fife]

I presume your ISP gave you a tunnel network and a public /28, and 
you're trying to use the IP's in the /28.  Until recently, you had been 
binding the tunnel network interfaces directly to your 'wan'.


You should probably be running a second router.  The rationale is trust 
levels.  The first router can function as a DMZ four your hosts that are 
on public interfaces.  Because the trust levels between your public 
subnet and your LANS are significantly different, you don't want a 
configuration that opens your LAN to the world if you make a even the 
most minor configuration error. Your second router can function as a 
firewall for your user-LANs, and the firwall's WAN will be a LAN IP in 
your public /30.  You can still do multi-WAN on your firewall.  Our DMZ 
is served by a 6-interface Lanner FW-7541D which allows me different 
policies for different physical interfaces.


The way you have drawn your sketch makes me think you conceptualize the 
two ISP interfaces as being 'outside', and your 'lans' are 'inside'.  
That idea is wrong, and will get you into trouble.   To deliberately use 
the language of that wrong concept, any interface allowed to talk to the 
world (any) is completely and utterly "inside" (including your public 
/28).  This is true unless you carefully and iteratively block egress TO 
any/every LAN,LAN2,Tunnel,VPN etc..  It is error-prone and fussy 
especially as you add interfaces/VLANS/VPN's.   You can simplify things 
somewhat with floating rules and interface group rules, but the ease 
with which it does something you don't expect is counter-intuitive.


Good luck.


On 2/10/2017 8:06 PM, Matthew Pounsett wrote:

vlan: 42 parent interface: em0


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

Going back to the OP, here's a postmortem on exactly what happened:

In short, we had unknowingly downgraded from 64 bit to 32 bit during an 
upgrade.  It's covered here:


https://doc.pfsense.org/index.php/Upgrade_Guide#Avoiding_Unintended_Architecture_Change

Interestingly, it worked like this:

We were running 64 bit 2.2.6.  Working fine.  We installed 64-bit 2.3.2, 
and restored our config.  Again, working fine.   Then we upgraded to 
*in-place* to 2.3.2_1, which for the *first time*, referenced a vestigal 
"upgrade URL" in our config, which had been carried-forward from an era 
when this was 'normal'.  Because the old URL happened to point to a 32 
bit architecture (the only architecture back then), we were unknowingly 
downgraded to the 32 bit architecture without realizing it.   And of 
course, the 32 bit defaults are VERY different from the 64 bit version 
(IIRC ~5x greater kern.ipc.nmbclusters and kern.ipc.nmbufs for 64 bit) 
causing our observed kernel panic on the ample Supermicro A1SRi-2758F 
(with its huge pile of cores and IGB NIC's) etc..  The pfSense project 
has correctly set stingy defaults in the 32 bit architecture, and 
there's no case to be made for running the 32 bit stack on a beefy board 
like this one.


I suspect many/most of people who have written in forum posts about how 
pfsense doesn't 'Just work' on the popular Supermicro A1SRi-2758F are 
running the 32 bit stack or unknowingly downgrading.


Last night we manually edited the config, and restored it to a clean 
64-bit image of 2.3.2, and as expected, it 'just worked' with no sysctrl 
modifications.  The upgrade to 2.3.2_1 was also flawless because the old 
upgrade URL had been removed from the config.



On 1/25/2017 4:01 PM, Karl Fife wrote:
This is a good theory, because RRD data from 2.2.6 suggests that the 
difference in utilization between the versions is slight, and that we 
had 'barely' exhausted our system default allocation.


Is there a difference between nano and full with respect to the 
installer explicitly setting tunables for kern.ipc.nmbclusters and 
kern.ipc.nmbuf?  Vick Khera says he sees explicitly set tunables on 
his 2.3.2 system, yet my virgin installation of Nano pfSense 2.3.2 has 
no explicit declarations?


Vick, is your Supermicro A1SRi-2758F running an installation that came 
from Netgate, or is it a community edition installation?  If the 
latter, Full or Nano?



On 1/25/2017 3:49 PM, Jim Pingle wrote:

On 01/25/2017 01:10 PM, Karl Fife wrote:

The piece that's still missing for me is that there must have been some
change in default system setting for FreeBSD, or some other change
between versions, because the system booted fine with pfSense v 2.2.6

Aside from what has already been suggested by others, it's possible that
the newer drivers from FreeBSD 10.3 in pfSense 2.3.x enabled features on
the NIC chipset that consumed more mbufs. For example, it might be using
more queues per NIC by default than it did previously.

Jim

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

Would you mind sharing a snapshot of your Rangeley-optimized tunables?

IIRC there are un-editable tunables that show on your tunables page that 
are not called out in the XML config.


Thanks Vick



On 1/26/2017 9:47 AM, Vick Khera wrote:

On Wed, Jan 25, 2017 at 4:01 PM, Karl Fife  wrote:


I recently did a virgin install of 2.3.2 nano on an older atom (a Soekris
6501), and found there were no tunables for kern.ipc.nmbclusters nor
kern.ipc.nmbufs.  Maybe it's a nano/full-install difference?I would
think most people running the a Rangeley board are running the full
version.  We will also begin running the full version with 2.4, (ZFS copies
= 2) :-)


I think the Nano vs full install may be your way to look. Also, my system
is running Netgate-tuned pfSense, so it is entirely possible they added the
bump to nmbclusters. Even though my configs to not specify a value for it,
it is set in /boot/loader.conf.

I'm 99.44% sure this system was upgraded from 2.2 to 2.3, and not a fresh
install of 2.3.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

This is a good theory, because RRD data from 2.2.6 suggests that the 
difference in utilization between the versions is slight, and that we 
had 'barely' exhausted our system default allocation.


Is there a difference between nano and full with respect to the 
installer explicitly setting tunables for kern.ipc.nmbclusters and 
kern.ipc.nmbuf?  Vick Khera says he sees explicitly set tunables on his 
2.3.2 system, yet my virgin installation of Nano pfSense 2.3.2 has no 
explicit declarations?


Vick, is your Supermicro A1SRi-2758F running an installation that came 
from Netgate, or is it a community edition installation?  If the latter, 
Full or Nano?



On 1/25/2017 3:49 PM, Jim Pingle wrote:

On 01/25/2017 01:10 PM, Karl Fife wrote:

The piece that's still missing for me is that there must have been some
change in default system setting for FreeBSD, or some other change
between versions, because the system booted fine with pfSense v 2.2.6

Aside from what has already been suggested by others, it's possible that
the newer drivers from FreeBSD 10.3 in pfSense 2.3.x enabled features on
the NIC chipset that consumed more mbufs. For example, it might be using
more queues per NIC by default than it did previously.

Jim

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

This is valuable input.  Thank you to you and Peter.

We had to add the tunables rows where they did not exist before. Perhaps 
if this had been a brand new virgin installation, the installer would 
have made suitable tunables estimates, based on the hardware, and 
inserted them into a new config.  By contrast, as a system-in-place, the 
installer perhaps skipped the step, seeing the preexisting tunables 
table?  We've been dragging this configuration forward from version 
2.0.  We've been bitten by this kind of thing before, where a new sane 
default is ignored by virtue of a previous config.  Just recently


I recently did a virgin install of 2.3.2 nano on an older atom (a 
Soekris 6501), and found there were no tunables for kern.ipc.nmbclusters 
nor kern.ipc.nmbufs.  Maybe it's a nano/full-install difference?I 
would think most people running the a Rangeley board are running the 
full version.  We will also begin running the full version with 2.4, 
(ZFS copies = 2) :-)


On 1/25/2017 1:15 PM, Vick Khera wrote:

On Wed, Jan 25, 2017 at 1:10 PM, Karl Fife  wrote:


pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
rangeley board (Intel Atom C2758)


Are you sure you didn't hard-code them before in the system tunables
section under 2.2? On my C2758 system (exact same motherboard) running
pfSense 2.3.2-RELEASE-p1, these are the values:

kern.ipc.nmbclusters: 100
kern.ipc.nmbufs: 1019445

and I've not tuned them at all.

What did you have to set them to? I have no additional NICs aside from the
4 built-in.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

That's very interesting. This datapoint sort of suggests that the 
opposite would have happened.  e.g. "woulda worked" in 2.3.2, "wouldnta 
worked" in 2.2.6


It may also be relevant that we're running NanoBSD on this board.   We 
are planning to stay with Nano until the ZFS-based file system arrives 
in 2.4 (we're running the beta in a few systems).


I searched the exported 2.2.6 XML config, and found there were no such 
tuneables in the configuration.  I have another thought about this in my 
reply to Vick's post.



On 1/25/2017 2:39 PM, Peder Rovelstad wrote:

There were changes in the defaults from FreeBSD 9 to 10.

https://pleiades.ucsc.edu/hyades/FreeBSD_Network_Tuning

Could that be it?  Old config overwriting new defaults?

-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife
Sent: Wednesday, January 25, 2017 12:11 PM
To: ESF - Electric Sheep Fencing pfSense Support 
Subject: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure
with pfSense 2.3.2

pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
rangeley board (Intel Atom C2758)

When we upgraded to 2.3.2, the new system failed to boot due to having
insufficient RAM allocated to network memory buffers.  We had to interrupt
the boot process increase the value of kern.ipc.nmbclusters (as per below),
then complete the boot process long enough to set system tuneables (below)
to allow subsequent startup.

What I've read online, the basic issue is that the combination of high CPU
count, high NIC count, and the igb driver create a (historically) atypically
demand for network buffer RAM.  That is consistent with our fix.

The piece that's still missing for me is that there must have been some
change in default system setting for FreeBSD, or some other change between
versions, because the system booted fine with pfSense v 2.2.6 without the
need for an advanced system tuneables.  Unless there's something
specific/quirky with our setup, it would seem sensible to me that for
subsequent releases, there should be system defaults suitable for modern
boards with resources like those found on boards like Rangeley.  I observe
that many others have had this same issue, so I doubt that this is a case of
our migrated settings preempting modern suitable defaults.

Any thoughts?

kern.ipc.nmbclustersIncreased to 8x observed MBUF Usage. Default is
too low for CVP Rangeley board, causing boot failure.   295600  
kern.ipc.nmbufs Increased to 2x default value, ~2.2x observed usage
(netstat -m). Default is too low for CVP Rangeley board, causing lockups.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F 
rangeley board (Intel Atom C2758)


When we upgraded to 2.3.2, the new system failed to boot due to having 
insufficient RAM allocated to network memory buffers.  We had to 
interrupt the boot process increase the value of kern.ipc.nmbclusters 
(as per below), then complete the boot process long enough to set system 
tuneables (below) to allow subsequent startup.


What I've read online, the basic issue is that the combination of high 
CPU count, high NIC count, and the igb driver create a (historically) 
atypically demand for network buffer RAM.  That is consistent with our fix.


The piece that's still missing for me is that there must have been some 
change in default system setting for FreeBSD, or some other change 
between versions, because the system booted fine with pfSense v 2.2.6 
without the need for an advanced system tuneables.  Unless there's 
something specific/quirky with our setup, it would seem sensible to me 
that for subsequent releases, there should be system defaults suitable 
for modern boards with resources like those found on boards like 
Rangeley.  I observe that many others have had this same issue, so I 
doubt that this is a case of our migrated settings preempting modern 
suitable defaults.


Any thoughts?

kern.ipc.nmbclusters 	Increased to 8x observed MBUF Usage. Default is 
too low for CVP Rangeley board, causing boot failure. 	295600 	
kern.ipc.nmbufs 	Increased to 2x default value, ~2.2x observed usage 
(netstat -m). Default is too low for CVP Rangeley board, causing lockups.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Rule Processing Order

[Karl Fife]

Can anyone give a philosophical/design purpose why the general OpenVPN 
rules are processed before the interface-specific OpenVPN rules (i.e. an 
OpenVPN server bound to an interface).   Processing rules from 
most-specific to least-specific seems like a more intuitive design 
guideline, but I'm certainly under-thinking a competing design 
priority.   Can anyone suggest a good rationale?






___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] pfSense 2.3.2-p1 RELEASE Now Available

[Karl Fife]

FYI, same circumstances, update is no longer choking on that step.

Thanks


On 10/6/2016 5:16 PM, Karl Fife wrote:
Update is failing over here.  Is there perhaps a file missing from a 
repo?  This is what I'm seeing when I update from the CLI:


...etc...
Fetching php56-5.6.26.txz: .. done
Fetching pfSense-rc-2.3.2_1.txz: . done
Fetching pfSense-kernel-pfSense_wrap-2.3.2_1.txz: . done
pkg: 
https://pkg.pfsense.org/pfSense_v2_3_2_i386-core/All/pfSense-kernel-pfSense_wrap-2.3.2_1.txz: 
Operation timed out


Is anyone else seeing this?


On 10/6/2016 2:29 PM, Jim Thompson wrote:
Details are here: https://blog.pfsense.org/?p=2122 
<https://blog.pfsense.org/?p=2122>

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] pfSense 2.3.2-p1 RELEASE Now Available

[Karl Fife]

Update is failing over here.  Is there perhaps a file missing from a 
repo?  This is what I'm seeing when I update from the CLI:


...etc...
Fetching php56-5.6.26.txz: .. done
Fetching pfSense-rc-2.3.2_1.txz: . done
Fetching pfSense-kernel-pfSense_wrap-2.3.2_1.txz: . done
pkg: 
https://pkg.pfsense.org/pfSense_v2_3_2_i386-core/All/pfSense-kernel-pfSense_wrap-2.3.2_1.txz: 
Operation timed out


Is anyone else seeing this?


On 10/6/2016 2:29 PM, Jim Thompson wrote:

Details are here: https://blog.pfsense.org/?p=2122 

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] New feature in ISC DHCP server v.4.3+ ( pfSense feature request )

[Karl Fife]

On 9/8/2016 9:14 PM, Jim Thompson wrote:

On Thu, Sep 8, 2016 at 7:36 PM, Karl Fife  wrote:


There is a brand new feature/option in ISC dhcpd 4.3.0 (the DHCP server
version in pfSense 2.3+).


you could say, "Thank you".  I drove the old crud out.




I would guess that few people here know who makes which specific 
contribution.  It certainly doesn't mean that people are not appreciative.


-K



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] New feature in ISC DHCP server v.4.3+ ( pfSense feature request )

[Karl Fife]

There is a brand new feature/option in ISC dhcpd 4.3.0 (the DHCP server 
version in pfSense 2.3+).


I would like to see this new feature available in the pfSense GUI

The new feature allows the DHCP server to ignore client UIDs as the 
primary identifier for the lease.  A host that presents a UID will have 
its lease assigned/keyed to that UID instead of having it be keyed to 
the client's MAC address.


Rationale for this feature request:

Honoring the client-presented UID is a DHCP specification, but in 
practice, A *single* host, with multiple OSes (or a host with a 
multi-step boot process, e.g. PXE boot) will end up receiving multiple 
different IP leases if one stack's DHCP client happenst to present a 
Client Identifier UID's versus another that does not (versus yet another 
that present a differently-formatted UID). Thus the ISC created a server 
feature in 4.3.0+ allowing client identifier UID to be ignored by the 
server.


In practice, I often see the example where a host that boots PXE, into 
iPXE, into Linux (e.g. Fog's Linux stack) on its way to say, Windows, 
often ends up having different IP addresses along the way.  I tend to 
see where the Intel PXE stack presents a UDI, iPXE does not, and Windows 
can't be bothered with a DHCP discover at all (going straight to a DHCP 
Request which may be out-of-pool). :-)


Unfortunately it is NOT a command-line option, thus can't be passed as 
an advanced option.  I think it would be necessary to add a simple GUI 
checkbox.  Since it can be desirable for a host to be identified by the 
same IP throughout the stages of the boot process (not to mention a 
cluttered DHCP lease table with multiple entries for a the client's 
MAC), it would be helpful to ENABLE the use of this feature in pfSense.


Is this in the pipeline?  Before making a formal feature request I 
thought I'd bounce it off my peers here on the mailing list.


Cheers.

-Karl Fife

https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf

" ignore-client-uids flag;
 If the ignore-client-uids statement is present and has a value of
 true or on, the UID for clients will not be recorded.  If this
 statement is not present or has a value of false or off, then client
 UIDs will be recorded.  "


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] DHCP Implicit rule processing order

[Karl Fife]

Functionally related to the implicit auto-lockout rule.  Makes sense.  
Thanks.



On 8/31/2016 9:49 PM, Jim Pingle wrote:

On 8/31/2016 9:30 PM, Karl Fife wrote:

This suggests the implicit rules are evaluated BEFORE the explicit
rules.  Is there a good reason they're evaluated first? I'd expect them
to be after to allow for debugging, logging, blocking, etc.


Yes, that is done on purpose. Otherwise it would be far too easy for a
user to block DHCP with a manual rule on the tab and then lose connectivity.

Jim
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] DHCP Implicit rule processing order

[Karl Fife]

If I understand correctly, the actual interface to which the DHCP 
service is bound gets an IMPLICIT (hidden) pass rule.


HOWEVER, I have a log&pass rule defined during DHCP activity.  I see the 
states, and see the LOGS for the DHCP conversations, (wireshark etc), 
but the pass rule is not being hit.


This suggests the implicit rules are evaluated BEFORE the explicit 
rules.  Is there a good reason they're evaluated first? I'd expect them 
to be after to allow for debugging, logging, blocking, etc.



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] automatic aliases (are sometimes incorrect)

[Karl Fife]

It appears that some of the automatic aliases offered via the GUI when 
creating firewall rules can be misleading or incorrect under certain 
circumstances.


For example:

If I create an OpenVPN server (say, a remote access type), and assign it 
to an interface called, say, VPN_BYOD, I'll see (as expected) aliases 
called VPN_BYOD_net and  VPN_BYOD_address. However, in this example, the 
alias does not actually correspond to the interface's true subnet.  
Since I'm being offered an alias for VPN_BYOD in the GUI, I'd expect it 
to be correct, and expect it to correspond to the tunnel subnet 
configured per OpenVPN server.  It doesn't, and this is perhaps 
unsurprising considering that the aliases values are probably generated 
by the values explicitly assigned to the interface (static/DHCP 
subnet/address) rather than divining them via the underlying service.  
In my example, OpenVPN is indeed assigned to an interface, but the 'tab' 
configuration is set to 'None' (even though the subnet is configured 
elsewhere).  This may therefore be expected behavior.


However, It seems like it would be much better behavior for the GUI to 
(simply) NOT show a subnet alias if the subnet can not be determined 
(for example, if the interface subnet is explicitly set to 'None').  
This would avoid the situation where someone creates a firewall rule for 
that subnet, only to realize that the source is undefined, or totally 
wrong.  In my case, I had to shell out, and interrogate PF directly to 
determine that the alias was incorrect.  That seems like bad default 
behavior to me.  Any opinions on this?



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Unicast Flood

[Karl Fife]

Answering my own question:

Unicast flooding is fundamental.  Unicast flooding in response to a null 
switching table is the only way for a frame to reach the intended host, 
say, if the switching table had an entry which expired before it could 
be re-populated with the host's arp reply.



On 8/16/2016 2:19 PM, Karl Fife wrote:

Hey all.  I'm trying to get to the bottom of an Ethernet concept:

If an Ethernet switch has no switching/forwarding table entry for a 
given MAC, does it flood/broadcast BY DESIGN (e.g. to behave like a 
good old-fashioned Ethenet HUB) or is unicast flooding an accidental 
characteristic of the way Ethernet switches work (i.e. down on the 
metal)?


For example, I could imagine an Ethernet switch design which the 
switch always returns null in the switching table for 
FF:FF:FF:FF:FF:FF, triggering a broadcast/flood, thus other bona-fide 
null (expired) lookups also happen to flood, BUT that this behavior is 
not strictly required to function.


Clarification on this detail would be much appreciated.







___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Unicast Flood

[Karl Fife]

Hey all.  I'm trying to get to the bottom of an Ethernet concept:

If an Ethernet switch has no switching/forwarding table entry for a 
given MAC, does it flood/broadcast BY DESIGN (e.g. to behave like a good 
old-fashioned Ethenet HUB) or is unicast flooding an accidental 
characteristic of the way Ethernet switches work (i.e. down on the metal)?


For example, I could imagine an Ethernet switch design which the switch 
always returns null in the switching table for FF:FF:FF:FF:FF:FF, 
triggering a broadcast/flood, thus other bona-fide null (expired) 
lookups also happen to flood, BUT that this behavior is not strictly 
required to function.


Clarification on this detail would be much appreciated.





___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] multiple:multiple

[Karl Fife]

Makes sense.  I was confused, seeing it in the context of analyzing 
secure connections to Google subnets.  Apparently I'm not "QUIC" enough 
on the uptake of the Google's experimental transport layers.  :-)



On 8/5/2016 5:41 PM, Jim Pingle wrote:

On 8/5/2016 3:13 PM, Karl Fife wrote:

All of the states in the pfsense states display make sense to me:
e.g. http://www.cs.hofstra.edu/~cscccl/c333/tcp.gif

Maybe I'm having a brain fart, but I'm not finding a good treatise on
the "multiple:multiple" state?
Anyone?

That "state" should only be seen with UDP and other stateless protocols.
You'll see SINGLE:NO_TRAFFIC when one side sends a single packet to the
other but has not yet received a response, and MULTIPLE:MULTIPLE when
both sides have sent multiple packets that match the state.

You can also see various combinations of these depending on the
protocol. For example you might see SINGLE:MULTIPLE from a perfectly
normal DNS request or you might see it on a partially working (or even
broken) ESP state for IPsec.

Essentially it's a counter that lets you know if 0, 1 or 2+ packets have
been observed matching the state.

Jim
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] multiple:multiple

[Karl Fife]

All of the states in the pfsense states display make sense to me:
e.g. http://www.cs.hofstra.edu/~cscccl/c333/tcp.gif

Maybe I'm having a brain fart, but I'm not finding a good treatise on 
the "multiple:multiple" state?

Anyone?



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] looking for perfect pfsense box for home?

[Karl Fife]

Honestly that j1900 looks like a really great choice.

I think the right questions would be whether you can tolerate the VGA 
console, whether it will cost more in terms of power consumption, 
whether you need the AES-NI instructions.  I was going to mention ECC 
ram, but the netgate box appears to be Non-ECC :-(


Given the role and quantity of RAM, ECC would be a sensible choice IMO.


On 8/3/2016 11:00 AM, Ryan Coleman wrote:

And there are many people on the list here who have vouched for the J1900 box 
mentioned earlier.

I am pretty sure we’ve vetted it; I know I have and I am going to start 
deploying it at customer sites over NetGate hardware.



On Aug 3, 2016, at 10:58 AM, Karl Fife  wrote:

+1

You can buy the 'blessed' hardware alone (e.g. CentOS) from netgate for $300 
(2-port) and $350 (4-port).   Cheaper than if you buy a preconfigured pfSense 
appliance with support.  Seems like REALLY inexpensive insurance to be using 
vetted hardware that others are also using.  In general, I consider cheap 
networking gear to be a false economy.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] looking for perfect pfsense box for home?

[Karl Fife]

+1

You can buy the 'blessed' hardware alone (e.g. CentOS) from netgate for 
$300 (2-port) and $350 (4-port).   Cheaper than if you buy a 
preconfigured pfSense appliance with support.  Seems like REALLY 
inexpensive insurance to be using vetted hardware that others are also 
using.  In general, I consider cheap networking gear to be a false economy.



On 8/3/2016 10:43 AM, Steve Yates wrote:

I'm being serious but what is your rationale for not using pfSense's/NetGate's?

https://www.pfsense.org/products/

The "cheap" part (< $299)?  We tried a "build our own" approach and it's tough 
to get a small package.  Any old PC will do just fine if one adds an SSD but as someone pointed out 
that may use far more power in the long run.

--

Steve Yates
ITS, Inc.

-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Eero Volotinen
Sent: Wednesday, August 3, 2016 2:37 AM
To: pfSense Support and Discussion Mailing List 
Subject: [pfSense] looking for perfect pfsense box for home?

Any ideas where to find perfect pfsense box for home usage.

Must be cheap and silent? netgate device? shuttle box?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] How do you numerate your tunnel networks?

[Karl Fife]

Any hints or good ideas for numerating VPN tunnel networks so that they 
can be easily and statically routed, just like the LAN's they serve?

(e.g. for a big private internal corporate network).

One idea
Allocate, say, a /23 in place of a /24, and waste an entire /24 as a 
tunnel network.
   Pro's - No addtional routing directives required on any of the hubs 
and spokes of the VPN-connected LANs.
   Con's - Wasteful, and even more problematic if you have to 
renumerate because the proposed tunnel networks are in use.


Another idea
Allocate a parallel, yet similarly structured hierarchy in a different 
netblock, say, 172.31.0.0/16
   e.g. a static route to 10.240.0.0/12 would get a static entry for 
the correlated tunnel network hierarchy say, 172.31.240.0/20
   (i.e. 10.240.0.0 thru 10.255.255.255 maps perfectly to 172.31.240.0 
thru 172.31.255.255
  Pro's - A single /16 in (172.31.0.0) can exactly map and evolve 
with the hierarchy of LANS (with granularity down to /23).

  Con's - 2x the number of static routes

Any other ideas?  From the real world, any thoughts about either schema?
Thanks!


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Mini-USB console on new pfSense certified hardware

[Karl Fife]

On 8/1/2016 4:20 PM, Moshe Katz wrote:

You could also use a set of USB over twisted pair adapters, but those
aren't necessarily the most dependable pieces of hardware over long
distances.


Indeed.  When something goes wrong, cognitive loads are high, and you 
don't want to be dickign around with uncertainty about your diagnostic 
tools and methods.  It's especially problematic at the precise moment 
when your wings are clipped because you don't have access to various 
online resources.  It's one of those "correlated risks" that makes this 
a bad place to introduce new variables, even if their absolute risk is 
low.   Just my 64¢.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Mini-USB console on new pfSense certified hardware

[Karl Fife]

USB HOST to RS232 adapter

It appears that the new rangely-based pfSense certified hardware (2440, 
4860) has a mini-USB (client) port for console access.


This "convenience" is ironic for us because I actually prefer RS232, 
(because that's the interface everything else uses).  As far as I know, 
I can't buy a USB-to-RS232 adapter because the dongles you buy are all 
USB *clients* (as is the router) therefore I couldn't connect a dongle 
adapter to pfSense and connect with hardware RS232.


The other irony is that the pfSense board doubtless has the UART right 
there on the board ahead of the USB adapter.   I wish there were a USB 
Header I could grab.  Can anyone say whether there's a way to grab 
serial from the board directly?


While this baked-in adapter may be in improvement for many, I'm guessing 
it's as inconvenient others because RS232 is a standard handoff.  
Everything else uses it, so we build solutions around it.  With hardware 
RS232, I can attach a Serial-to-IP adapter connected to our management 
network, or I can run serial over twisted pair to a remote hardware 
serial port.


Any elegant solutions to this change?




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] 32-to-64 bit upgrade - unbound needn't be un-bound

[Karl Fife]

Over the weekend I did some 32-to-64 bit architecture upgrades on 
NanoBSD systems with 64-bit hardware.


The migrations were seamless EXCEPT that in every case, the DNS 
forwarder [sic] would fail to work unless selectively un-bound from IPv6 
interfaces.


On all of the systems, there was at least one interface included by the 
default "all" which is not dual-stack.  I suspect this is why dnsmasq 
was choking.  HOWEVER, I bring it up here in the forum because the very 
same configs would not cause DNS to choke if restored to 32-bit 
architecture of the same version.


Strange.

In my case, I've switched those systems to use unbound/Resolver, and in 
all cases, all systems with unbound don't need to be un-bound from IPv6 
interfaces.


Most of these configs have been rolled forward since early 2.0, so I 
suspect that there may be idiosyncrasies in the config (e.g. old 
defaults) that might be responsible (e.g. settings that may not cause 
this issue to express itself in a brand new install).


Any hypotheses of this weird observation?



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Lightning strike

[Karl Fife]

On 7/26/2016 8:40 PM, Chris Buechler wrote:

On Tue, Jul 26, 2016 at 7:43 PM, Volker Kuhlmann  wrote:

On Tue 26 Jul 2016 09:41:37 NZST +1200, Karl Fife wrote:


Interesting how it failed: The fried port 'simply' broke
connectivity for the interface's LAN segment.  Everything else
continued to work.  I kinda didn't believe the report that Internet
was out for the one LAN, since the other was not.

I don't think this is that unusual or surprising. You get the same
effect if you plug in a real POTS line into an Ethernet port...


  After some
testing, I found the system would not come up after reboot because
it had gone into port reassignment mode since the config made
reference to a non-existent interface.

I find this really really annoying of pfsense! Especially for headless
systems. Hey, why run with only one interface and some functionality
missing when one can run with functionality of zero point zero instead?


Because any fall back there is potentially unsafe. Say you have
igb0-igb5, and igb2 dies. Now your igb3 is igb2, igb4 is igb3, etc.
Any assumptions you make about what's correct are potentially
dangerous, and likely to be wrong. We've had discussions around that
in greater depth multiple times over the years. Any way you do it has
edge case bugs, is dangerous and/or wouldn't be right anyway.



Amen to that.   Please don't change port behavior "automagically". This 
appears to be a phenomenon now.  I'm often seeing examples of ridiculous 
"fail safe" hardware features (e.g. binding IPMI to eth0 on IPMI link 
failure, or bridging interfaces on OS failure). Chok-full-o externalized 
security risks.   Certain "visionaries" needs to be taken out and beaten.


Thanks to Moshe, Jim and others for the links and musings!!   I now 
suspect that the isolation amplifier likely induced current on the 
Ethernet controller side of the circuit, meaning that the board may need 
a dual-chipectomy.


Either way, my thinking is that the low cost of fiber fiber and 
transceivers may be cheap insurance in the fugure if for example there's 
potential for different safety-ground reference points in the AC 
wiring.  In my case, I was on different panels within the same 
structure.  Technically they have the same safety-ground reference, but 
in the event of an AC power anomaly/event, anything can happen (e.g. as 
a the safety ground path begins to carry current).


I do think that if switching gear on BOTH ends of my Ethernet run *had 
been* bonded to a common "Earth-ground" reference (vs the electrical 
safety ground, as recommended by manufacturers), I suspect it may have 
significantly reduced the probability of damage as the anomaly would 
have been partly sunk through the earth-ground lug on the back of the 
equipemnt, reducing the potential for errant current being induced 
through the isolation transformer.  As it was only one side was bonded 
to a dedicated earth-ground, possibly increasing the chance of trouble 
versus the chances if neither side had been earth-grounded at all.



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Lightning strike

[Karl Fife]

The 6th Ethernet port (em5) on my Lanner fw-7541D died Saturday night 
during the electrical storm.  Just the one port.


Apparently fried, apparently by an electrical anomaly.

Now, the link light is always on (dimly lit), whether populated or not, 
and neither the POST, nor the OS detects the presence of the fifth port.


Interesting how it failed: The fried port 'simply' broke connectivity 
for the interface's LAN segment.  Everything else continued to work.  I 
kinda didn't believe the report that Internet was out for the one LAN, 
since the other was not.  After some testing, I found the system would 
not come up after reboot because it had gone into port reassignment mode 
since the config made reference to a non-existent interface.


I edited the config in VI to de-reference the interface, and All's well.

I really like this Lanner hardware, and would like to keep it in 
service.  Ideally I'd like to fix the (now dead) spare port so that I 
still have a spare.


Can anyone tell me what's component is typically fried in this scenario? 
 Is it the NIC controller chip itself? I'm guessing it's not, rather 
I'm guessing it's just the big, blocky Ethernet Isolation 
transformer/amplifier that's been fried.  I'm also guessing that the 
reason the system is still functional (at all) is because the little 
dude did its job.  I know it's a long shot, but I'd like to hear if 
anyone has ever repaired a fried Ethernet port on a motherboard.


Also ironic, everything's very well grounded with a dedicated 
earth-ground via #6 AWG except the one (damned) switch that services 
that one (damned) LAN. I imagine if I'd gone to the trouble of running a 
dedicated ground to that switch, it may not have sunk the spike.  Any 
experience or war stories in this arena appreciated as well.  Memo to 
myself: Run fiber to switches on different power/earth.


-Karl
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] CIFS slow on PPTP

[Karl Fife]

The problem has less to do with CIFS, and more to do with applications 
and the laws of physics.


The laws of physics dictate that large files opened from far away will 
not perform like those that are close, and applications must be designed 
to deal with those realities.   This is one reason why terminal services 
and remote desktop get a lot of traction in business.  It allows data to 
sit near the application, and send just the UI data to the remote party 
(Remote Desktop as an application is mature, and works well).


There is no panacea.  There are only varying levels of compromise to 
make usable work flows.  Even the examples I've seen of traditional LAN 
applications which have been completely rebuilt to become Cloud apps are 
thought to be less 'performant' by users, ergo, also a compromise.


What will work best all depends on the business process you're trying to 
create.  Good luck.


-K


On 7/25/2016 2:22 PM, Chris wrote:

Karl Fife wrote:

Are you sure that CIFS is slow because of PPTP?  All but the latest
CIFS/SMB protocols are poorly suited for high-latency connections such
as the public Internet (e.g. where you might use VPN).  Even under the
best circumstances, many applications don't tolerate it well
(Size/speed/latency/loss etc.)

BTW: Is there any alternative to CIFS? Any parameters to speed it up? Is
there any replacement? I would use SFTP, but its usability is sth.
completely different for non-powerusers.

- Chris

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] CIFS slow on PPTP

[Karl Fife]

Are you sure that CIFS is slow because of PPTP?  All but the latest 
CIFS/SMB protocols are poorly suited for high-latency connections such 
as the public Internet (e.g. where you might use VPN).  Even under the 
best circumstances, many applications don't tolerate it well 
(Size/speed/latency/loss etc.)


Just sayin'.


On 7/23/2016 4:01 PM, Chris wrote:

Dear All,

CIFS is too slow on PPTP. pfSense is server.

I've already tried to

- select "Disable Firewall scrub..."
- allowed icmp type df on WAN and PPTP interface for MTU path discovery -
default MTU seems to be 1400. Are there any (DSL?) connections where even
that is too much? Is it possible to change it on pfSense only and make the
client adjust automatically?

Are there any other things I should check?

- Chris



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] DNS Forwarder # exception

[Karl Fife]

DNS Forwarder had a domain override *exception* feature that I don't see in
DNS Resolver.  I'm looking for a equivalent/workaround.

Obviously, In both dnsmasq and unbound, I can create a domain override, e.g.

DomainIP
example.com10.243.0.1

However, I Don't want the override to answer queries for certain hosts,
e.g. mail.example.com, vpn.example.com, because queries to those domains
will fail if 10.243.0.1 is not available (e.g. mail.example.com) or not
available JUST YET (e.g. vpn.example.com).

With dnsmasq, I could create an exception with # so those queries would
just fall through to the public DNS, e.g.

vpn.example.com#
mail.example.com  #
sip.example.com   10.55.47.1

Certainly I can create a HOST override that resolves the host's public IP,
but that breaks when the public IP changes.  What's the best way to
accomplish these domain override exceptions these days (in
unbound/DNSResolver)?

Thanks
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Traffic Limiter name change

[Karl Fife]

We've entered the wonderful world of the traffic limiters. Specifically, 
we put FACEBOOK subnets through a comparatively skinny pipe.  This is 
done to make it JUST a bit too painful to look at kitten photos, but 
perfectly suitable to look at CompetitorCo's facebook page for 
legitimate business purposes. We're still collecting empirical data on 
how much it disuades personal use, but it doesn't seem to create tension 
the way that explicit blocking would.


The issue:

in <=2.2 if an in-use limiter is renamed, the system will yell at you.  
IMO, that's good.


in 2.3, if an in-use limiter is renamed, the system will not yell at 
you. IMO that's bad.


Should this fact be considered a regression, or is there a reason for 
removing this notice/check?


IMO, it would be preferable to abstract the limiter names the way 
aliases have been abstracted (so they can be changed without the risk of 
breaking things) but I understand that limiters may not be used as 
frequently as aliases.




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] CPU Utilization on landing page

[Karl Fife]

Scaling down the update frequency on the traffic graphs seems to 
meaningfully reduce utilization.  Many other widgets don't appear to 
have have settings for their poll intervals.   Are there other settings 
hidden away reduce the update frequency (to prolong the suitability of 
older hardware)?


I know that old routers have to meet their makers eventually, but I hate 
to do so only because dashboard starts causing real-time applications to 
fall over.


-K


On 6/23/2016 4:35 PM, Chris Buechler wrote:

On Thu, Jun 23, 2016 at 11:55 AM, Karl Fife  wrote:

Ever since upgrading to 2.3, I notice that the CPU utilization is uncommonly
high when a browser is pointed at the Status / Dashboard.

Naturally, this is the php-fpm process.  Each instance of php-fpm runs at
between 8 and 40% of my 1.8ghz Atom (dual core, HT).  With four or five
dasbord windows open and I can burn 70% of the CPU on the idle box.   Doing
the same on <= 2.2 barely registers additional utilization.


Many more things dynamically update than before, and do so more often.
Opening up 5 dashboard instances basically turns the box into a
relatively busy web server, doing probably a few dozen requests per
second depending on which all widgets are enabled. Yes that will chew
some CPU on an old Atom.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] CPU Utilization on landing page

[Karl Fife]

Ever since upgrading to 2.3, I notice that the CPU utilization is 
uncommonly high when a browser is pointed at the Status / Dashboard.


Naturally, this is the php-fpm process.  Each instance of php-fpm runs 
at between 8 and 40% of my 1.8ghz Atom (dual core, HT).  With four or 
five dasbord windows open and I can burn 70% of the CPU on the idle 
box.   Doing the same on <= 2.2 barely registers additional utilization.


Disabling active widgets (traffic graphs, firwall logs) reduces the 
utilization slightly, but it's nowhere near what it was <= 2.2.


Is something wrong here, or is this new framework simply more resource 
intensive?  Certainly I'd expect the client to be working harder with 
the javascripty bootstrappy interface, but I would not expect a pfSense 
workload change.  In our case, all of the upgraded instances (4) behave 
the same, and all are running on the same Lanner FW-7541D, so maybe 
there's an idiosyncratic problem with that hardware.


Is anyone else seeing this?

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] MTU on TUN adapter in lossy conditions

[Karl Fife]

Extremely helpful.  I'll post our test results.


On 6/15/2016 2:10 PM, Heath Barnhart wrote:

Most VPN's I've worked with dropped the MTU to 1300 for that very reason.
I'd give it a try and see what happens. One thing I would check to see is
if OpenVPN also effects the MTU of the physical interface being used, and
if it permanently changes it. I ran into an issue where an application
would randomly quit working. After doing some digging I found that Cisco
AnyConnect had reconfigured the MTU on my wired NIC to 1300, even when the
tunnel was disabled.

On Wed, Jun 15, 2016 at 1:46 PM, Karl Fife  wrote:


Has anyone had success adjusting MTU on OpenVPN tunnel adapters to deal
with loss amplification across tunnel networks?

By default the MTU on an openVPN adapter(s) are set to 1500, but it seems
that performance in lossy conditions might be dramatically improved by
changing the MTU to something smaller to prevent packet fragmentation
across the tunnel network (e.g. to account for the encrypted packet's IP
overhead, such that one packet could be encapsulated by one packet of the
tunnel network).  It seems that if the MTU's are the same, one would
invariably end up with frequent fragmentation, greatly increasing the
packet loss amplification on lossy (e.g. wireless) networks, and
exaggerated falloff of application performance as packet loss increases.
This is also consistent with what I observe.

I understand that this artificial constraint would result in lower
performance in high quality connections, but am I on the right track to
dealing with performance on lossy networks?  If this is conceptually
correct, so would I also need to explicitly tell OpenVPN not to fragment in
general?  Any big-picture guidance would be much appreciated.



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold






___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] MTU on TUN adapter in lossy conditions

[Karl Fife]

Has anyone had success adjusting MTU on OpenVPN tunnel adapters to deal 
with loss amplification across tunnel networks?


By default the MTU on an openVPN adapter(s) are set to 1500, but it 
seems that performance in lossy conditions might be dramatically 
improved by changing the MTU to something smaller to prevent packet 
fragmentation across the tunnel network (e.g. to account for the 
encrypted packet's IP overhead, such that one packet could be 
encapsulated by one packet of the tunnel network).  It seems that if the 
MTU's are the same, one would invariably end up with frequent 
fragmentation, greatly increasing the packet loss amplification on lossy 
(e.g. wireless) networks, and exaggerated falloff of application 
performance as packet loss increases.  This is also consistent with what 
I observe.


I understand that this artificial constraint would result in lower 
performance in high quality connections, but am I on the right track to 
dealing with performance on lossy networks?  If this is conceptually 
correct, so would I also need to explicitly tell OpenVPN not to fragment 
in general?  Any big-picture guidance would be much appreciated.




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Snort or Suricata

[Karl Fife]

With as many rules as an IDS/IPS would evaluate for each packet, it 
seems that a multi-threaded option would be an obvious choice, 
especially on modern multi-core quasi-embedded systems (e.g. 
Rangely/Atom) with lower absolute clock speeds.  Otherwise it seems you 
might become effectively CPU bound given modern uplinks and applications 
(e.g. captive portal, multi-lan etc), thus introducing jitter and 
reduced throughput.


Is this consistent with anyone's real-world observation/testing?


On 6/13/2016 9:28 AM, Steve Yates wrote:

See if disabling the stream-events.rules ruleset helps.  The web forum had some 
references about that being incompatible with the pfSense implementation.  If 
memory serves, it's because Snort/Suricata see copies of packets not the actual 
stream so they are often processed out of order.

When I looked a while back it seemed like Snort and Suricata were similar but 
Snort was single thread and Suricata could multi-thread.

https://github.com/Snorby/snorby/wiki/Snort-vs-Suricata-vs-Sagan
http://wiki.aanval.com/wiki/Snort_vs_Suricata

--

Steve Yates
ITS, Inc.

-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Daniel Eschner
Sent: Sunday, June 12, 2016 1:57 PM
To: pfSense Support and Discussion Mailing List 
Subject: [pfSense] Snort or Suricata

Hi there,

i installed Snort and let it run with snort Community Rules and ET Rules.
I get ton als Fals positiv alters.

Maybe is suricata better? What are the difference?

It Seems that only the ET rules has no or veryl less fals positivs.

Cheers

Daniel
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Update 2.3_1 to 2.3.1 failed

[Karl Fife]

On 5/24/2016 2:30 PM, Chris Buechler wrote:

On Tue, May 24, 2016 at 2:25 PM, WebDawg  wrote:

On Tue, May 24, 2016 at 2:18 PM, Chris Buechler  wrote:


On Tue, May 24, 2016 at 1:28 PM, WebDawg  wrote:

On Tue, May 24, 2016 at 11:34 AM, Chris Buechler 

wrote:

On Tue, May 24, 2016 at 5:33 AM, OSN | Marian Fischer 

wrote:

Hi list,

when i try to update one carp member from 2.3_1 to the latest update

(2.3.1) it fails after

# snip
Updating pfSense-core repository catalogue...
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
# snip

the other member did the update well. Both are running on 4GB  CF nano

install.

any solution out there?

Diag>NanoBSD, set to permanent rw, and reboot for good measure. It work
then?
___



I have a few pfSense devices that I purchased, do I need to set permanent
rw on them for 2.3.1?

If you have problems with them, yes. Once upgraded to 2.3.1, they'll
be set permanent rw with no option to go ro.



So if I already have them up to 2.3.1, I am fine.

Yes.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


So is the R/O,R/W issue the same cause as here?

thusly:
https://imagebin.ca/v/2hkICOAnJnbs

Log:
http://pastebin.com/vFMqWNHK

If the update wizard reports "update failed", but post reboot it reports 
2.3.1, and my 'failed' updates all show NanoBSD mounted R/W, and show v 
2.3.1.  Any cause for concern, or reason to suspect that the system 
might be in an unusual state?


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] [Announce] pfSense 2.3.1-RELEASE Now Available!

[Karl Fife]

I just upgraded pfSense community edition from 2.2.6 to 2.3 on two 
different Lanner FW-7541D's


In both cases the UI reported "Firmware Installation Failed"

thusly:  https://imagebin.ca/v/2hkICOAnJnbs

however the unit rebooted, correctly showing the updated version.

The install logs didn't seem to have any smoking guns:

http://pastebin.com/vFMqWNHK

Any thoughts?


On 5/18/2016 4:33 PM, Chris Buechler wrote:

We are happy to announce the release of pfSense® software version 2.3.1!

This is a maintenance release in the 2.3.x series, bringing a number
of bug fixes, two security fixes in the GUI, as well as security fixes
for OpenSSL, OpenVPN and FreeBSD atkbd and sendmsg.

Please see the release announcement for all the details.
https://blog.pfsense.org/?p=2050
___
Announce mailing list
annou...@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/announce


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Soeckris Net5501 SSD

[Karl Fife]

Noteworthy differences between the 3700 and 3500 series, and a nod to 
the 710:


Both the 3500 and 3700 have capacitor-backed write cache, so power 
events are unlikely to be cataclysmic, but the 3700 series has roughly 
42x better write endurance than the 3500.


Intel publishes that the 80GB 3500 is good for 45 TB (same as the 3510).
By contrast, they publish that the 100GB 3700 is good for 1874 TB.  This 
is apparently due to a suite of technologies called HET, which includes 
differences in both silicon and the controller. The older 710 series 
share this HET technology (and share capacitor-backed write cache), but 
the 710 drive I/O is slower, ergo, so is the cost, possibly making the 
710 a better value in terms of pursuing marginally higher reliability.


Neither the 3510, nor the 710 have what Intel calls End-to-End Data 
Protection, which just appears to be parity on steroids. Opinions 
welcome on this, but I would be surprised if the the susceptibility to 
bit rot on an datacenter-grade SSD did not already far exceed that of a 
CF card.  As such, the 710 seems like it may be an affordable little 
corner in the realm of SSD drive overkill for a pfSense install.


-Karl

On 5/18/2016 1:35 PM, Steve Yates wrote:

The Intel S37xx is their data center line right?  We've had some weird stuff in 
Windows and Linux servers get fixed by drive firmware updates.  There have been 
multiple updates since fall 2015.  Weird as in the Intel software in Windows 
showed both drives in a RAID 1 failed, though Windows could still read and 
write to that drive letter.  Based on the Linux errors I suspect the drives 
were temporarily dropping out and/or taking too long to access.

That said, I know you were asking for real world experience, but Intel does 
list reliability and drive write life specs for their SSDs if you open the PDFs 
on their site.  They do list compressed read and write speeds for some drives 
so be careful what table you're reading.

--

Steve Yates
ITS, Inc.

-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife
Sent: Wednesday, May 18, 2016 1:18 PM
To: pfSense Support and Discussion Mailing List 
Subject: Re: [pfSense] Soeckris Net5501 SSD

Ed, you said it well here:  "wear leveling work is in SATA and DOM"

I think this is an important point, because If I understand correctly, there is 
nothing inherent to DOM or SATA to make it more or less suitable to the 
excellent implementations we've seen of over-provisioning, wear-leveling etc. 
in the other storage form factors.
As you say though, that's were the work is taking place, so if you want it, DOM 
and SATA appear to be the devices to use. Funny how that works, but it appears 
to be market forces only, not technology which informs this detail.

Thanks too for the info on the Soekris 6501.  I have one in the feild, also 
with an MSata module.  I'm really glad I didn't try to upgrade that in place, 
or I might be talking ethyl the 60-year-old office manager through 
router-resurrection.  Fun.  You just saved my bacon.  Thanks for that.

In the realm of SSD's I have been using Intel S37xx's as ZFS intent log 
accelerators for as long as they've been available. Great devices.  Some 
installs have seen many terabytes of writes per week for years without issue.  
For a pfSense install, it's an absurd amount of overkill.
Still, as you say, 'pro grade' SSD's are a mere $50, so 'pro' SSD's start to 
become an economical choice.

In particular, I see the Intel S35x0 ~80GB for $60.  Do you know if the 
reliability is in the same league as the s3700 series, it would be an easy 
choice given the high cost of downtime in a remote install.  Any experience 
with that series of devices in particular?

Thanks a lot Ed.  Your input was exactly what I was looking for!
-Karl

On 5/18/2016 10:11 AM, ED Fochler wrote:

Karl,
There are numerous other similar answers to be found, but here’s mine:

Get away from CF if you can.  The modern performance and wear leveling work is 
in sata and DOM, those are better devices.  Abandon the nano-BSD and just find 
the miscellaneous checkbox to put /tmp and /var in ram.  That’s the bulk of the 
benefit without the separate distribution.  Although that is seldom necessary 
any more either.

My Soekris 6501 still doesn’t like the upgrade to PFSense 2.3 on mSata, but I’m 
running one from a Sata disk on 2.3 just fine.  This problem seems Soekris 
specific, but my summary is still that sata seems to be where the support is.  And 
with SSD, I don’t see any benefit to staying away from sata even if you are 
allergic to spinning disks.  Market forces have made 100GB SSD’s available for 
less than $50, and that’s some wild over-provisioning for an install that is happy 
in < 4GB.  You can get a nice Intel or “pro” samsung for a little more if you 
want more insurance against having to

Re: [pfSense] Soeckris Net5501 SSD

[Karl Fife]

Ed, you said it well here:  "wear leveling work is in SATA and DOM"

I think this is an important point, because If I understand correctly, 
there is nothing inherent to DOM or SATA to make it more or less 
suitable to the excellent implementations we've seen of 
over-provisioning, wear-leveling etc. in the other storage form factors. 
As you say though, that's were the work is taking place, so if you want 
it, DOM and SATA appear to be the devices to use. Funny how that works, 
but it appears to be market forces only, not technology which informs 
this detail.


Thanks too for the info on the Soekris 6501.  I have one in the feild, 
also with an MSata module.  I'm really glad I didn't try to upgrade that 
in place, or I might be talking ethyl the 60-year-old office manager 
through router-resurrection.  Fun.  You just saved my bacon.  Thanks for 
that.


In the realm of SSD's I have been using Intel S37xx's as ZFS intent log 
accelerators for as long as they've been available. Great devices.  Some 
installs have seen many terabytes of writes per week for years without 
issue.  For a pfSense install, it's an absurd amount of overkill.  
Still, as you say, 'pro grade' SSD's are a mere $50, so 'pro' SSD's 
start to become an economical choice.


In particular, I see the Intel S35x0 ~80GB for $60.  Do you know if the 
reliability is in the same league as the s3700 series, it would be an 
easy choice given the high cost of downtime in a remote install.  Any 
experience with that series of devices in particular?


Thanks a lot Ed.  Your input was exactly what I was looking for!
-Karl

On 5/18/2016 10:11 AM, ED Fochler wrote:

Karl,
There are numerous other similar answers to be found, but here’s mine:

Get away from CF if you can.  The modern performance and wear leveling work is 
in sata and DOM, those are better devices.  Abandon the nano-BSD and just find 
the miscellaneous checkbox to put /tmp and /var in ram.  That’s the bulk of the 
benefit without the separate distribution.  Although that is seldom necessary 
any more either.

My Soekris 6501 still doesn’t like the upgrade to PFSense 2.3 on mSata, but I’m 
running one from a Sata disk on 2.3 just fine.  This problem seems Soekris 
specific, but my summary is still that sata seems to be where the support is.  And 
with SSD, I don’t see any benefit to staying away from sata even if you are 
allergic to spinning disks.  Market forces have made 100GB SSD’s available for 
less than $50, and that’s some wild over-provisioning for an install that is happy 
in < 4GB.  You can get a nice Intel or “pro” samsung for a little more if you 
want more insurance against having to visit those devices.  I’m generally a fan of 
the SSDs with metal cases for heat dissipation.

ED.






On 2016, May 17, at 6:09 PM, Karl Fife  wrote:

I have about 15 Net5501's OR Lanner FW-7541D's in the field running 
embedded/Nano on CF cards.  There's not enough space on a 1GB  CF to upgrade to 
v2.3.  Of course I can upgrade to larger CF cards, however the eventual 
phase-out of NanoBSD makes me wonder if it's better to install a SATA SSD (or 
SATA DOM) which would possibly eliminate the need to re-re-factor storage in 
the near future (e.g with the release of v 2.4, and the phase-out of NanoBSD: 
https://doc.pfsense.org/index.php/Upgrade_Guide#Planning_for_the_Future )

Question:
I'd like to ask what solid-state storage others are using on non-NanoBSD installs.  If 
running the "full" version of pfSense, Is it sufficient 'simply' to use a 
quality wear-leveling SATA DOM, or is it recommended to use something with even better 
write endurance?  I wouldn't have thought the pfSense write load is high, but blog posts 
from early adopters of SSD's + pfSense seem to have run into write endurance problems.   
SSD's have improved greatly especially in terms of wear-leveling, over-provisioning etc.. 
What's a recommended non-disk drive for full pfSense these days?









___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Soeckris Net5501 SSD

[Karl Fife]

I have about 15 Net5501's OR Lanner FW-7541D's in the field running 
embedded/Nano on CF cards.  There's not enough space on a 1GB  CF to 
upgrade to v2.3.  Of course I can upgrade to larger CF cards, however 
the eventual phase-out of NanoBSD makes me wonder if it's better to 
install a SATA SSD (or SATA DOM) which would possibly eliminate the need 
to re-re-factor storage in the near future (e.g with the release of v 
2.4, and the phase-out of NanoBSD: 
https://doc.pfsense.org/index.php/Upgrade_Guide#Planning_for_the_Future )


Question:
I'd like to ask what solid-state storage others are using on non-NanoBSD 
installs.  If running the "full" version of pfSense, Is it sufficient 
'simply' to use a quality wear-leveling SATA DOM, or is it recommended 
to use something with even better write endurance?  I wouldn't have 
thought the pfSense write load is high, but blog posts from early 
adopters of SSD's + pfSense seem to have run into write endurance 
problems.   SSD's have improved greatly especially in terms of 
wear-leveling, over-provisioning etc.. What's a recommended non-disk 
drive for full pfSense these days?










___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Monitor (RRD) all 0 data on 2.3

[Karl Fife]

I envision the ideal design to be one in which I can have five or six 
(customized) graphs in one view (rather than having only one single 
customizable 'default' view).   Ideally all of the saved graphs would 
visible/rendered together when I go that page, but even if I had some 
presets (like an car's FM radio :-), I'd consider it an improvement over 
the RRD implementation, as well as the current one..


(top-posting for consistency)


On 5/3/2016 10:37 AM, Jeppe Øland wrote:

Found it (Status/Monitoring), but buy do I dislike the new setup.

I really liked the old one where I could see several time-periods at a
glance.

But worse is I can't seem to get the new UI to show me "total data passed
in/out" for the interfaces over a period. I use(d) this for accounting :-(

On Tue, May 3, 2016 at 8:31 AM, Jeppe Øland  wrote:


Where did RRD graphs move to in 2.3?
Can't seem to find them anywhere (am I blind?)

On Thu, Apr 21, 2016 at 5:22 AM, Vick Khera  wrote:


oh never mind. i first read you did an upgrade. that is a weird symptom...

On Thu, Apr 21, 2016 at 8:21 AM, Vick Khera  wrote:


On Thu, Apr 21, 2016 at 1:53 AM, Gé Weijers  wrote:


I just performed a clean install of 2.3 on an AMD64 PC. Everything is
fine,


Was your prior install 32-bit? When you switch/upgrade from 32 to 64 bit
the RRD graphs break.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Site to Site VPN behind nat

[Karl Fife]

On 5/2/2016 10:24 AM, Vick Khera wrote:

On Sun, May 1, 2016 at 8:18 PM, Dane Reugger  wrote:


I've seen this done with Aruba but not sure it's possible with PfSense but
if it is I would love a guide to get it going.


Use OpenVPN. It doesn't care at all about the NAT. Many guides online for
setting up whole network VPN over OpenVPN.

On pfSense server, you create one "server" entry per remote LAN you want on
its own dedicated port. Open up the firewall to allow connections and
you're good to go.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


...Unless of course both sides are behind NAT.  One side must public, or 
at least have a port forward from the public interface.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Long delay before DHCP issued leases appear n the DHCP lease table

[Karl Fife]

I've been 'subdividing' some growing networks into multi-lan; guest, 
management networks etc.


On every occasion I've observed that it has taken considerable time 
(perhaps 10 to 20 minutes) after the DHCP server begins issuing new 
leases (to hosts moved from the other interface) before they show in the 
DHCP lease table.These hosts are successfully being issued  IP 
addresses in the new range, and their MAC's and IP's show up in the 
pfSense ARP table, plus I can see the activity in the DHCP log.
Restarting DHCPD doesn't seem to have an immediate effect.   So far, it 
seems most correlated with the passage of time.


Naturally all of the hosts in all scenarios were moving from a different 
interface on the same router.  Some even had static reservations (that 
were deleted).   These have all been 2.2.6 installations.  I may have 
the opportunity to re-factor as above on a 2.3 installation later this 
month.


Any ideas what's happening here?  Am I waiting for ARP expiration or 
something?  Any way to speed up this process?












___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Cisco VPN

[Karl Fife]

I've done this.  IIRC It was a PITA.
I'm having trouble finding my notes but my recollection is that the 
Cisco nomenclature is different.


Also, the only cyphers and keys I could make work were as follows:

Key exchange v1

Phase 1 Auth
Auth: Mutual PSK
Nego: Main

Phase 1 Prop
AES 128
Sha 1
DH 2 (1024)

Same Key, Hash, and cipher for phase 2

Don't forget about MTU when using IPSEC.  I can't remember the default 
these days, but on pfSense under advanced IPSEC settings, you'll want to 
ensure MSS clamping is enabled so you don't have to reduce MTU on your 
WAN.  If your remote Cisco hardware doesn't support the same, you may 
have to reduce MTU.








On 4/21/2016 9:26 AM, Ian Bowers wrote:

How/when is it failing?

On Thu, Apr 21, 2016 at 10:01 AM, user49b  wrote:


Hi

Please could someone point me to some descent documentation.
I'm struggling to get IPsec VPN connection working to a Cisco VPN server
from behind pfSense.

So I have a terminal server behind pfSense, and trying to connect to VPN
server on internet.

Regards
Chris



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] NTP Drift file not retained (NanoBSD) and "clipping" of

[Karl Fife]

It appears that pfSense 2.3 and earlier on nanoBSD does not retain its 
system clock calibration between reboots.


On certain (certified) systems, this appears to trigger a sequence in 
which the offset gets further and further behind, and NTPD tries in vain 
to slew the clock, increasing the drift (freq) value until it exceeds 
500, at which point the NTP server gives up, and advertises stratum 16.  
Said system is able to function as a reliable time server if I manually 
step the clock after the system has booted up.  Eventually it will 
re-calculate its drift


Poking around, I see that pfSense on nanoBSD writes NTP drift value to 
/var/db/ntpd.drift

which is mounted to ramdisk  /dev/md1,

Obviously not retained in the case of an abend, but notably ALSO not 
retained during a normal reboot.  Is there a strategic reason this 
hard-won calibration is not retained?



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Ambiguous gateway monitoring

[Karl Fife]

That's the answer I was looking for.

It occurs to me that Chris has just described the very configuration of 
thousands of corporate laptops with Wi-Fi adapters and wired NIC's on 
the same LAN subnet, with the same gateway :-)


Even Microsoft spells this out as a No-No: 
https://support.microsoft.com/en-us/kb/175767


"If you configure a Windows-based computer that has more than one 
network adapter on the same physical network and protocol subnet, you 
may experience unexpected results. ...by definition, only one adapter 
may communicate on the network at a time in the Ethernet network 
topology. ...  Additionally, broadcast messages must be handled by each 
adapter because both are listening on the same network. This 
configuration requires significant overhead, excluding any 
protocol-related issues."



On 4/15/2016 1:41 PM, Chris Buechler wrote:

On Fri, Apr 15, 2016 at 12:31 PM, Karl Fife  wrote:

I'm bringing this up in the off chance that it is a bug.  I think it might
be expected behavior but want to bounce it off a few others.

I have an installation with two fiber uplinks.  Each uplink has an IP on the
ISP's single WAN subnet (e.g. one single subnet, not a pair of tunnels).
This is a temporary configuration but in the meantime I observed the
following.

In this configuration, the gateway monitoring's default settings use a
single gateway monitoring IP address (their DHCP default gateway).  What I
observe is that ONE of the two interfaces will have 'unknown/pending'
gateway status.  Obviously, the gateway monitoring ICMP messages for BOTH
interfaces are routing via only ONE of the two, leaving other gateway's
status unknown.


The issue isn't gateway monitoring, it's that you can't have the same
subnet on multiple interfaces and can't have multiple WANs with the
same gateway IP. There can only one one ARP cache entry for a given IP
and it will be associated with only a single interface. It's a toss up
as to which will work in that case. It's impossible to communicate
with the same IP on two diff NICs.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Ambiguous gateway monitoring

[Karl Fife]

I'm bringing this up in the off chance that it is a bug.  I think it 
might be expected behavior but want to bounce it off a few others.


I have an installation with two fiber uplinks.  Each uplink has an IP on 
the ISP's single WAN subnet (e.g. one single subnet, not a pair of 
tunnels). This is a temporary configuration but in the meantime I 
observed the following.


In this configuration, the gateway monitoring's default settings use a 
single gateway monitoring IP address (their DHCP default gateway).  What 
I observe is that ONE of the two interfaces will have 'unknown/pending' 
gateway status.  Obviously, the gateway monitoring ICMP messages for 
BOTH interfaces are routing via only ONE of the two, leaving other 
gateway's status unknown.


QUESTIONS:
1. It's actually the NON-default interface (em2) that is being 
successfully monitored, NOT the default gateway interface (em1), so 
first of all if the monitoring service isn't clever enough to monitor 
its gateway on its own interface, shouldn't it be using the default 
interface?


2. While this specific configuration is temporary for us 
(fiber/link/transciever debugging), it seems that the gateway monitoring 
should in fact be clever enough to use its own in interface for 
monitoring its gateway address.  Is that right? While unusual, I don't 
think there anything fundamentally wrong with this configuration, right?


Thanks in advance.

Smart-alecs only:
Yes, The 'normal' configuration both fiber links is membership in a LAGG 
interface.
Yes, I know default gateway monitoring will begin if I change the 
monitor address for the default gateway to a different subnet IP address 
(e.g. a public dns server).







___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Access Point Recommendations?

[Karl Fife]

Your point about having a one-off solution is a great one. Installing a 
single UniFi AP would be unnecessarily complex.


The TP-Link TL-WA801nd is a BGN-only device.  Do you (or anyone) have a 
preferred stand-alone AC access point?



On 7/22/2015 8:10 PM, Adrian Zaugg wrote:

  TP-Link TL-WA801nd


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Access Point Recommendations?

[Karl Fife]

My specific hardware recommendations are below:

I suspect Geoff's PoE switches did not meet the published requirement 
for 802.3at (i.e. more than 15 watts of PoE) rather than being an 
idiosyncratic incompatibility.


The irony is that the AVERAGE wattage for AP-AC is actually LESS THAN 15 
watts, thus one might assume the AP-AC should be able to work.  HOWEVER, 
the power draw of the AC-AP is not uniform.   Even though it draws ~11w 
on average, when it needs 25w for a few fractions of a second, the 
802.3af PoE PSE will not be able to keep up, and the AP will 
malfunction.   This is the same consideration FOR meeting the VA (vs 
Wattage) requirement  on your servers with a UPS.


My personal recommendation for Wi-Fi is for Ubiquiti UniFi.  It's just a 
great value, and it's simple to manage/administer remotely. pfSense 
plays a role in our case with DNS forwarder responding to the default 
"UniFi" with the routable IP address of the controller (physical, local 
virtual, cloud etc).  We've got dozens of APs in many locations across 
the country, all managed from one VM, in our case, over VPN.  In this 
way, we can drop ship a brand new UniFi to a remote location and it will 
"call home" for configuration


Within the UniFi family:

1. I recommend the AP-AC if at all possible.  It's an absolute 
requirement for congested areas, or installations where you would 
actually benefit from lots of link bandwidth.  Just do it if you can, 
for the same reason a SSD is an obvious choice (unless you are 
*severely* cost constrained or can explain in detail why its a bad fit 
for your application).  While Speedtest.net is a poor proxy for link 
speed, as a point of reference we're getting 70+ mbs on my mobile phone 
over Wi-Fi versus 11mbps with 802.11g (to a 100mbs backhaul).


2. I recommend UniFi AP-PRO too (What I still use at home), but only for 
low-interference (low congestions) installations especially if you have 
a budget constraints, and/or can not upgrade to bona-fide 802.3at power 
sourcing equipment, and do not want a "Brick Farm" comprising a pile of 
midspan power bricks and a rat's nest of cables.  (I just thought of 
that... Brick Farm)


3.  We've had surprisingly good luck placing outdoor units indoors 
(though our sample size is small.  The outdoor AP's appear to work 
unusually well for a given underlying technology (B, G, N, AC) etc., 
presumably because of their superior high-gain antenna design. They're 
spendy, but they might be a good choice for an installation where you 
are barely at the border of needing to install multiple units in a 
single location.


Just now I was testing a spare unit we're turning up.  It was still set 
using the high power defaults.  I wandered from the base and lost 
connectivity.  It was a practical reminder that unless you live on 
Gilligan's island, or in a Faraday cage, cranking UP the power on an AP 
almost always makes things worse (because you end up with asymmetry 
between TX&RX, especially with mobile phone clients). In other words, 
you  are always harmed by having strong signal from AP's with which you 
can not effectively communicate in 2 directions.   Turning DOWN the 
power usually makes things better (closer to parity between Tx & Rx).   
If Alice and Bob need to talk, but they're out of earshot, it doesn't 
help to give ONLY Alice a megaphone.




On 7/20/2015 5:57 PM, Geoff Nordli wrote:

On 15-07-20 01:19 PM, Vernon Fort wrote:
I have had several sites use the Ubiquiti Networks Unifi-ap-lr (long 
range).  Run the software as a service on a DC or standard 2008/2012 
server or even a windows 7 machine.  They work very well.  I've had 
zero issues with the 30 or so of these devices I have setup and 
installed with the exception of some wifi printers and older 
devices.  But I think the latest software and firmware had solved 
these issues.


Vernon



-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of compdoc
Sent: Monday, July 20, 2015 2:00 PM
To: 'pfSense Support and Discussion Mailing List'
Subject: Re: [pfSense] Access Point Recommendations?

A lot of good info in these posts, but no real hardware 
recommendations...





I have a site with the Unifi AP AC and it has been solid.

The only issue I had is the POE didn't work with our existing switches 
and I needed to actually use the POE adaptors they provided.


Geoff


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Access Point Recommendations?

[Karl Fife]

Both Zero Handoff and Wireless Backhaul for Wi-Fi  have proven to be 
*not useful* technologies for us due to the transient and unpredictable 
nature of Wi-Fi interference.  Both technologies have correlated risk 
factors that cause cascading performance degredation.  As interference 
or load increases, the probability of adverse loss, jitter, and latency 
also increase.  That breaks the network's suitability to many applications.


SNR in the backhaul band can be fine for days, then can become absolute 
shit for hours, seemingly for no reason.  Site analysis shows an energy 
spike in the backhaul band.  Maybe somebody's 'smart' AP has changed 
channels.  Maybe someone is microwaving a baby monitor.  Maybe the UFO's 
just outside probe my brain using the Wi-Fi bands to steal my secret 
plans.  Architecture using these technologies can be acceptable for 
hobbyists, or for when there is literally no other option within budget, 
but IMO architecting a system with them is similar to setting out for a 
day on the ocean with a life jacket (i.e. no boat).


Zero Handoff?
This we've measured less carefully, but performance appears to tank far 
sooner in this scenario too.  Please chime in if you have specific 
expertise on this technology, but this appears that ZH depends upon low 
interference on a single channel across the entire handoff 'campus'.   
That's a pipe dream in dense condominiums and high-rise office 
buildings.  It may be OK if you live in a Faraday cage or on a drilling 
platform in the ocean.  Apart from those scenarios, we've never been "on 
the fence" as to whether we should use it.


Now AC on the other hand...  I love me come AC.  Plus, they tend to 
serve double duty as space heaters.

-KF





On 7/17/2015 10:37 AM, Zandr Milewski wrote:

Be aware, though, the UAP-AC is missing some banner UniFi features.

No Zero-Handoff
No Wireless Backhaul

I can't tell if any of the UniFi indoor stuff does the UNII-2e/DFS 
stuff. The AC's certainly don't.


On 7/17/15 08:29, David Burgess wrote:
On Fri, Jul 17, 2015 at 8:45 AM, Chuck Mariotti 
 wrote:
We are having a number of issues with Engenius Access Points... they 
seems to have the features we need but for some reason, connectivity 
is not reliable (seems Mac related). As much time as I would like to 
spend debugging it, it would be cheaper to replace.


Does anyone have any recommendations for small office access points?



I second both of the previous replies. I use Unifi and Tomato
exclusively for wireless.

For budget installs with plenty of features, try Shibby's Tomato on
the ASUS RT-N12 or RT-AC66U.

For POE, top aesthetics or mass deployment and central management,
spend a little more on the Unifi.

db
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Access Point Recommendations?

[Karl Fife]

We've gone all-in with AC in challenging environments (crowded, 
congested etc).  UniFi AP-AC to be exact.  It's awesome.


One trick with UniFi AP-AC (vs AP-PRO) is that UniFi AP-AC *needs* 
802.3at PoE PSE.  It will APPEAR to work with 802.3af PoE PSE, but it 
will choke under even light load.  Literally it will become 
power-starved and it will malfunction or reset.  We've seen stability 
with Juniper's 802.3af+ 'PoE-Plus' firmware update which gets you up to 
~18w per PD.  Without it, the voltage will sag under load and reboot.


-K

On 7/17/2015 4:11 PM, Chris Bagnall wrote:

On 17 Jul 2015, at 15:50, Jim Spaloss  wrote:

Ubiquiti Unifi.

+1 would recommend - with caveats.

The AC model is… flaky - or at least, it was when I tried it at the end of 
2014. Only about 50% of client devices would connect at a time - seemingly 
random - restart the AP and some different ones would connect. Performance was 
great for those that were connected, but I’d be hesitant about installing it at 
a paying customer’s premises.

As Todd says, the basic UAP is 24v passive PoE, not 48v 802.11af. There is, 
however, an adapter for around £12 that converts 802.11af into 24v passive PoE, 
which works well. You don’t need to use the provided AC adapter unless you want 
to.

The UAP Pro is excellent. Standard PoE from any 802.11af switch, good coverage, 
decent performance, and no problems with dozens of devices connected to it.

If you don’t need 5Ghz and you aren’t bothered about the non-standard PoE, then 
the UAP is cheap-as-chips (around £50 at last check). Otherwise go with the UAP 
Pro.

Kind regards,

Chris


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Rules for interfaces assigned to a bridge: expected behavior?

[Karl Fife]

I am trying to understand the expected behavior with regard to rules for 
interfaces that are members of a bridge, when the bridge device (e.g. 
BRIDGE0) is *directly* assigned to an interface (e.g. LAN, WAN etc.)


Intuitively, I would expect that rules appearing on the bridged 
interface's named tab would apply to all member interfaces for that 
bridge.  In other words, I would have expected the tab to function just 
as if an Interface Group had been defined for those interfaces.  This 
does not appear to be the case.


I tried this last on v 2.2.0 (not since).  I could not get traffic to 
flow between bridged interfaces in my testing without creating pass 
rules directly on the bridge's individual member interfaces OR by 
creating pass rules on an Interface Group created for, and assigned to, 
each of the bridge's member interfaces (i.e. one *tab* to *rule* them 
all)  :-)


If this is expected behavior, what is the rationale?  The named tab for 
the bridge would seem to serve no other purpose than group rules.


-K
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] OpenVPN connects fine, no internet

[Karl Fife]

>>The VPN should protect from all MITM attacks and snooping between the 
VPN client and server.


This is a great idea, but I find that routing all traffic through VPN 
causes problems in marginal (lossy or congensted) networks.  I'm curious 
to know if others have also had this pain point, and whether you've had 
any success by simply sending VPN over TCP.



___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

[Karl Fife]

I agree with you Chris.  That's an excellent choice for someone building 
out a new network assuming you don't peer with other networks/systems in 
that space.  Ultimately, it's a crap shoot, and the solution is to use 
IPV6 and 6:4 NAT for legacy.  Still, if there were a way to easily 
invoke client-side NAT to resolve conflicts, I'd certainly trade beer 
for it.

-K


On 12/10/2014 6:34 AM, Chris Bagnall wrote:

On 10/12/14 6:36 am, Chris L wrote:

That’s actually your fault for using 10/8, not Comcast's.
Even if they were to use something like 10.58.223.0/24 they’d still 
conflict with your 10/8.


There are so many different brands and models of consumer router on 
the market these days in the 10/8 and 192.168/16 range that we've 
pretty much given up on them for all new installs, instead dropping 
things into the other RFC1918 range: 172.16/12 (we usually use 
variants on 172.20.x/24 where x is reasonably random).


I don't think we've seen more than 1 or 2 consumer routers that 
default to anything in the 172.16/12 range - yet.


Kind regards,

Chris


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

[Karl Fife]

Chris L, can you clarify your point?
Every RFC1918 subnet carries with it a risk of subnet conflict. Some 
subnets carry more risk than others.  In our case, 192/168/n would 
result in higher probability of conflict because most small networks use 
that space.  I might 'fault' Comcast because they're allocating the 
largest netblock to their smallest residential customers.  It's not 
wrong per-se (AFAIK), but it's certainly poor judgement.  Mobile Network 
Operators and large enterprises run large 10/8 intranets, thus are known 
to utilize the largest IPV4 netblock. Home/small users do not, thus it 
is good practice to use the smaller netblock to reduce the risk of 
conflict when multi-homing, whether it be via VPN or MNO.



On 12/10/2014 12:36 AM, Chris L wrote:


On Dec 9, 2014, at 8:53 PM, Karl Fife  wrote:


In the wild, I'm seeing a an increasing number of crappy consumer/ISP
routers with subnets that conflict with ours (10../8). Comcast appears
to be a common offender, curiously allocating the largest private subnet
to their smallest customers.  Of course this breaks VPN due to address
ambiguity/conflicts.

That’s actually your fault for using 10/8, not Comcast's.

Even if they were to use something like 10.58.223.0/24 they’d still conflict 
with your 10/8.
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

[pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

[Karl Fife]

In the wild, I'm seeing a an increasing number of crappy consumer/ISP
routers with subnets that conflict with ours (10../8). Comcast appears
to be a common offender, curiously allocating the largest private subnet
to their smallest customers.  Of course this breaks VPN due to address
ambiguity/conflicts.

We're usually able to talk non-tech people through changing their LAN
subnet.  That doesn't work when a user isn't the network administrator,
such as in a hotel.

Using 1:1 NAT on the VPN *server* interface is workable (making the
resources "unambiguous"), but this is ugly because it means resources
need to be referenced with a different IP addresses (depending on
whether inside or outside of the office).

A seemingly obvious solution would be client-side NAT.  For example if
the client were placed behind a private NAT, (with the physical adapter
on the 'native' (10../n) network and a virtual LAN adapter in a
non-conflicting subnet (say 192.168../n).

Looking around, this doesn't appear to "be a thing".   I think it would
make sense to have client side NAT be part of a VPN client to invoke if
needed.  Maybe it exists, and I'm just looking in the wrong places.

Anyone seen this?
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] OpenVPN & Non-admin users.

[Karl Fife]

Somehow I overlooked that option. Needless fussing.

Enabling the OpenVPNManager by default seems like it could be a 
reasonable option considering that all supported versions of Windows 
(Vista/7/8/[10]) require users (even admins) to elevate the OpenVPN 
client (and/or create an elevated shortcut).


Is this not default because it's "currently incompatible with the 64-bit 
OpenVPN installer"?  If so, is there any practical downside to running 
the 32 bit installer on a 64 bit system?  Is there a practical downside 
to running the OpenVPNManager in lieu of an elevated shortcut?




On 12/2/2014 5:57 PM, Chris Buechler wrote:

On Tue, Dec 2, 2014 at 3:47 AM, Marijn Hofstra  wrote:

  > We add them to the Windows built-in "Network Configuration
Operators"

Do you know this to work with Windows 8 Enterprise (or Win 10
for that matter)?  I've seen this work in some versions of
Windows, but when we tried it in Win 8 Enterprise, it didn't
seem to work.  We didn't probe further, suspecting that it
was due to security changes in Windows >=8.


I dealt with this issue recently, so I'll chime in for my $0.02.

This works for WinXP, but for Vista and newer, you really need the OpenVPN GUI 
add-on. IIRC, the particular security group no longer provides the desired 
permissions in Vista and newer.

With the GUI add-on, basically you ensure that the openvpn service is running 
(autostart) and add a few lines to your .ovpn config, something the likes of:



You can skip all that if you're using our OpenVPN Client Export
package, just check the OpenVPN Manager box and it takes care of all
that automatically.
___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] OpenVPN & Non-admin users.

[Karl Fife]

> We add them to the Windows built-in "Network Configuration Operators"

Do you know this to work with Windows 8 Enterprise (or Win 10 for that 
matter)?  I've seen this work in some versions of Windows, but when we 
tried it in Win 8 Enterprise, it didn't seem to work.  We didn't probe 
further, suspecting that it was due to security changes in Windows >=8.



On 12/1/2014 3:04 PM, Gordon Russell wrote:

We add them to the Windows built-in "Network Configuration Operators" group, and 
that gives them enough privilege to add routes, and we use the standard Openvpn client & 
GUI. We need for our end users to be able to bring up/down the tunnel, and so auto-starting 
as a service proved not workable.

Gordon Russell
Clarke County IT
540 955 5135


- Original Message -

From: "Karl Fife" 
To: "ESF - Electric Sheep Fencing pfSense Support" 
Sent: Monday, December 1, 2014 3:37:25 PM
Subject: [pfSense] OpenVPN & Non-admin users.

I'd like to poll how others have dealt with the issue of non-admin
Windows users running OpenVPN (TUN) for remote access.

If you recall, non-admin users don't have the privileged of inserting a
routes, so even though the tunnel is is established, it won't be used
without an explicit route.

I've read all of the scenarios, from running the client as a service,
disabling username/password, creating client shortcuts with elevated
privilege etc, using the Viscosity client for windows (only needs admin
to be installed, not to be used).

If you feel like showing off your astute reasoning, which route did you
take and why?


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

[pfSense] OpenVPN & Non-admin users.

[Karl Fife]

I'd like to poll how others have dealt with the issue of non-admin 
Windows users running OpenVPN (TUN) for remote access.


If you recall, non-admin users don't have the privileged of inserting a 
routes, so even though the tunnel is is established, it won't be used 
without an explicit route.


I've read all of the scenarios, from running the client as a service, 
disabling username/password, creating client shortcuts with elevated 
privilege etc, using the Viscosity client for windows (only needs admin 
to be installed, not to be used).


If you feel like showing off your astute reasoning, which route did you 
take and why?



___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] GUI "Auto Update" updates to image with wrong console type

[Karl Fife]

That's partly consistent with our observations so far.  The 
configurations of ALL the previously cited installs followed upgrade 
paths through 2.0.3.  However we can confirm for at least two of the 
migrated configurations that the serial ports were working properly on v 
2.1.3 when their configurations were first moved TO the Lanner FW5741D 
platform from 1. Soekris 5501, and 2. VMX-9 on ESXi.


So in our case, while all passed through 2.0.3, the 2.1.3->2.1.4 
Auto-update was perfectly correlated with onset.


In our observation:
2.1.4->2.1.5 auto-update did not remedy the issue in any cases,
2.1.4->2.1.5 (manual) remedied the issue
2.1.5->2.1.5 (manual) remedied the issue

-K

On 9/9/2014 11:04 AM, Jeremy Porter wrote:

Two things would be helpful, did the system start as a clean 2.1.4 or
was it upgraded from a previous version, if so what versions?
I've seen a couple of odd cases, but usually where a system was upgraded
several times.  There might have been an issue around 2.03(p1) or so.
We haven't been able to replicate the problem in the lab, so its
possible there is a specific upgrade path that errors.


On 9/9/2014 7:21 AM, Vick Khera wrote:

To be clear, this only happened to me on the 2.1.4 -> 2.1.5 upgrade.

On Tue, Sep 9, 2014 at 8:20 AM, Vick Khera  wrote:

On Mon, Sep 8, 2014 at 8:05 PM, Karl Fife  wrote:

Has anyone else observed that the serial console stops working after a
WebGUI update?

On my ALIX home office router, the serial console disappeared until I
did a second reboot. On my higher-end routers running on "real"
computers there was no problem with the serial port consoles.

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

[pfSense] GUI "Auto Update" updates to image with wrong console type

[Karl Fife]

Has anyone else observed that the serial console stops working after a 
WebGUI update?


This has happened consistently with our Lannder FW-5741D's

I can not definitely exclude all other causes, but I observe that all 
six have had their console type changed to VGA from Serial, presumably 
during one of the two automatic upgrades since the initial 
configuration. I also suspect that this has not happened to any of our 
Serial-only Soekris boards, but I don't have physical access to  confirm 
that.


I have been able to restore functioning by manually re-updating with the 
appropriate Serial/NanoBSD/i386/nGB image.


Has anyone else observed this?

-Karl


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] pfSense Routing - VPN's

[Karl Fife]

OpenVPN vs IPsec:
I find IPsec to be a bit more 'fussy' than OpenVPN, mainly because an 
IPsec setup with multiple tunnels to a single instance will share a 
single "logical" interface, making policy/rule management a bit more 
prone to human error, in contrast to OpenVPN where each site-to-site 
tunnel can appear as a discrete interface. Still, OpenVPN CAN manage 
multiple OpenVPN rules on a single interface for common rules if 
desired. (i.e. Allow any DNS).  I also find IPsec can be a bit fussy 
with regard to ESP and its MTU issues, though pfSense makes it much 
easier with MSS clamping ONLY on IPsec tunnels, which eliminates the 
need to reduce the MTU on the WAN interface (and all interfaces bridged 
to WAN).   Benefits of IPsec? Some day I'll meet someone who can tell me 
whether IPsec has any increased cryptographic strength for a given 
cipher/key/RNG combination due of the fact that the phase 2 re-keying is 
done in a quasi-out-of-band fashinon (i.e. using phase 1 IKE).  In other 
words, I assume that cracking a phase-2 key would only benefit an 
attacker until the next phase-2 re-key, unless they have also cracked 
the phase-1 IKE.  Cracking a phase-1 key exchange seems like it could be 
extremely difficult if (for example) a properly decrypted phase 1 IKE 
looks like entropy.


Renumeration (re-IP'ing)
No need to renumerate the main branch in your example as long as the 
main branch isn't assigned a subnet mask of less than 24 bits (/23 , 
/16, /8, etc).  pfSense at the main branch will have interfaces (ergo 
routes) for each of the discrete 10.0.(4,5,6..n).0/24 tunnels, making 
routing to them implicit.  In your example, the 'spokes' off the main 
branch would need to be told to find your other LAN subnets via this 
tunnel. In OpenVPN it's done right in the tunnel configuraiton: (OpenVPN 
Advanced "route 10.0.0.0 255.255.0.0;".


Good luck.

On 5/18/2014 7:12 AM, Alex Threlfall wrote:

Interesting, we're not using OpenVPN at present, just the built in IPSEC
stuff in pfSense, what benefits are there in switching to OpenVPN?

So our main branch is say 10.0.4.0, and the other branches are 10.0.5.0,
10.0.7.0, 10.0.2.0 and 10.0.3.0, all /24's - would using this methodology
require me to re-ip the main branch?

--
Alex Threlfall
Cyberprog New Media
www.cyberprog.net



-Original Message-
From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife
Sent: 16 May 2014 07:55
To: pfSense Support and Discussion Mailing List
Subject: Re: [pfSense] pfSense Routing - VPN's

This is exactly what we do.

We make the hub the OpenVPN server, and the spokes the clients because
the hub IP is static, and we can manage all of the OpenVPN listeners on

one

instance.

If your whole network is a /16, and each spoke is a /24, all you need is a

route

directive on each of the spokes for the entire /16.  In OpenVPN Advanced
"route 192.168.0.0 255.255.0.0;"

You don't need any routing directives on the 'hub' because the addition of
each connection will take care of that.

With respect to rules:
We find it best to make the first rule on the hub's OpenVPN interface

this:

"Any source/port NOT destined for THIS hub subnet is allowed to pass".

That

way each branch can manage their ingress policy privately because the hub
will just route anything not destined for its subnet.

We also find it best to set up DNS forwarders to the spoke networks, i.e.
Hub: mybranch.mycompany.com dns dips are at 192.168.11.1.  Spokes can
dip the hub if so configured which can in turn dip OTHER spokes if so
configured.  Inverse lookups work too.  For example, add a dns forwarder

of

10.168.192.in-addr.arpa to allow inverse lookups in the spoke in the

subnet

192.168.10.0/24

It's been rock-solid for many years now!

Good luck.






On 5/16/2014 1:16 AM, A Mohan Rao wrote:


its very simple...!
first u have to configure a main vpn site to site vpn server at your
main branch then u can easily configure a b c etc.
with share key and tunnel network.


On Fri, May 16, 2014 at 2:53 AM, Alex Threlfall 
wrote:


Hi All,



I currently have a number of sites which

have VPN's

between them, with each site having a VPN to one another. This is becoming
harder to manage, we currently have 5 sites, (6 if you include my home)

and

it would make sense to me to adopt more of a star architecture with a

central

site.



However, I can't work out how to configure

this! Each

site has it's own /24 of private address, and I have a central branch. How

can I

configure things so that the if branch B needs to get to branch C, it

knows

that it must go via branch A?



Branch A has the best connectivity - bonded

FTTC's,

so would make sens

Re: [pfSense] pfSense Routing - VPN's

[Karl Fife]

This is exactly what we do.

We make the hub the OpenVPN server, and the spokes the clients because 
the hub IP is static, and we can manage all of the OpenVPN listeners on 
one instance.


If your whole network is a /16, and each spoke is a /24, all you need is 
a route directive on each of the spokes for the entire /16. In OpenVPN 
Advanced "route 192.168.0.0 255.255.0.0;"


You don't need any routing directives on the 'hub' because the addition 
of each connection will take care of that.


With respect to rules:
We find it best to make the first rule on the hub's OpenVPN interface this:
"Any source/port NOT destined for THIS hub subnet is allowed to pass".  
That way each branch can manage their ingress policy privately because 
the hub will just route anything not destined for its subnet.


We also find it best to set up DNS forwarders to the spoke networks, 
i.e. Hub: mybranch.mycompany.com dns dips are at 192.168.11.1. Spokes 
can dip the hub if so configured which can in turn dip OTHER spokes if 
so configured.  Inverse lookups work too.  For example, add a dns 
forwarder of 10.168.192.in-addr.arpa to allow inverse lookups in the 
spoke in the subnet 192.168.10.0/24


It's been rock-solid for many years now!

Good luck.





On 5/16/2014 1:16 AM, A Mohan Rao wrote:

its very simple...!
first u have to configure a main vpn site to site vpn server at your 
main branch then u can easily configure a b c etc.

with share key and tunnel network.


On Fri, May 16, 2014 at 2:53 AM, Alex Threlfall > wrote:


Hi All,

I currently have a number of sites which have
VPN's between them, with each site having a VPN to one another.
This is becoming harder to manage, we currently have 5 sites, (6
if you include my home) and it would make sense to me to adopt
more of a star architecture with a central site.

However, I can't work out how to configure this!
Each site has it's own /24 of private address, and I have a
central branch. How can I configure things so that the if branch B
needs to get to branch C, it knows that it must go via branch A?

Branch A has the best connectivity -- bonded
FTTC's, so would make sense as well as it being our "hub" branch
for the stock control system also.

Any advice would be appreciated!

--

Alex Threlfall

Cyberprog New Media

www.cyberprog.net 


___
List mailing list
List@lists.pfsense.org 
https://lists.pfsense.org/mailman/listinfo/list




___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] using Pfsense as a router

[Karl Fife]

The two ends of your MPLS link are on different subnets, so your MPLS 
provider will have to route for you.  You have to coordinate with them 
on that (OR create your own point-to-point tunnel)


For example, YOUR site1 router needs to know that site2's 172.16.11.0/24 
subnet is reachable via 10.152.8.129, but your MPLS provider's router at 
10.152.8.129 would also need to know that your 172.16.11.0/24 subnet is 
reachable via 10.152.8.118 (plus the return routes).


Your provider should be able to guide you.

This may be a helpful read:
http://blog.ine.com/2010/08/26/mpls-tunnels-explained/

A quick and dirty way to do this without coordinating with your service 
provider would be to create a point-to-point tunnel using Site-to-site 
OpenVPN or IPsec.  If encryption over the MPLS network is a liability, 
you can disable encryption entirely.


Good luck
-Karl



On 5/14/2014 12:27 AM, Faisal Gillani wrote:

Kluas

I apologize for this , yes this was a typo error.

Local Network information is as below.

Local Network IP settings and how can we use  (OSPF / BGP) ?

Site 1
IP 172.16.0.0
Subnet 255.255.255.0
All clients in Site 1 use 172.16.1.16 (Linux Firewall) as its default
gateway it is also connected with MPLS network with above given settings

Site 2
IP 172.16.11.0
Subnet 255.255.255.0
All clients in Site 2 use 172.16.11.17 (Linux Firewall) as its default
gateway it is also connected with MPLS network with above given settings

Requirement
.   Clients on both sites should be able to access each other.
.   Clients on both the Sites should use 172.16.1.16 for their internet
needs

Regards
Faisal


-Original Message-
From: Klaus Wunder [mailto:kl...@net-wunder.de]
Sent: Wednesday, May 14, 2014 10:08 AM
To: faisal.gill...@akesp.org; pfSense Support and Discussion Mailing List
Subject: Re: [pfSense] using Pfsense as a router

Hello,

First of all I have a Question.

Your booth Sites use overlapping Subnets. Is it a typing error?

To come to you Routing Question. In future, are there more branch Offices
scheduled?

I think in this case a Dynamic Routing  Protocol is perfekt (OSPF / BGP)

In the other case the simplest solution is to use Static Routing.

Regards

Klaus


Von meinem iPhone gesendet


Am 14.05.2014 um 06:17 schrieb "Faisal Gillani"

:

Hello All

I am trying to use Pfsense as my premier router to connect my office with
other branch offices on a provider's layer 3 MPLS network.
I have disabled all NAT and packet filtering on both of my Pfsense boxes.
Also uncheck block private schemes on my WAN interfaces as the ip schemes

my

MPLS provider uses  are private ones.

Below is my scenario all I want is help what to define in my static routes
or should I use dynamic routing protocols for this ?

IP Settings given by MPLS provider

Site 1
IP 10.152.8.130
Subnet 255.255.255.252
GW 10.152.8.129

Site 2
IP 10.152.8.118
Subnet 255.255.255.252
GW 10.152.8.117

Local Network IP settings

Site 1
IP 172.16.0.0
Subnet 255.255.0.0
All clients in Site 1 use 172.16.1.16 (Pfsense) as its default gateway it

is

also connected with MPLS network with above given settings

Site 2
IP 172.16.11.0
Subnet 255.255.0.0
All clients in Site 2 use 172.16.11.17 (Pfsense) as its default gateway it
is also connected with MPLS network with above given settings

Requirement

.Clients on both sites should be able to access each other.
.Clients on both the Sites should use 172.16.1.16 for their internet
needs

Thanks
Faisal


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list


___
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list

[pfSense] DNS Forwarder problem in 2.1.0

[Karl Fife]

What I observe:
When a static mapping is created for a DHCP client, the DNS forwarder 
appears to NOT register the mapping (i.e. does not allow DNS resolution) 
unless the client is also manually assigned an IP address.


It is my understanding that if the address value is left blank (i.e. if 
the IP address is not hand-coded by a live animal), the DHCP server will 
dynamically assign an address for the DHCP client, AND will also 
register the name/address mapping in the DNS forwarder.


Is this a bug or expected behavior?

Thanks!



___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] 2.x Traffic shaping

[Karl Fife]

I'm not quite sure where to start with this one, but ever since we 
migrated from version 1.2.3 to 2.0.1, our traffic shaping seems to fail 
under many conditions where 1.2.3 'just worked'.  The endgame is that 
it's fouling up our VoIP telephony.


Essentially, everything's exactly the same as it was with the exception 
of the pfSense version. We have the same hardware, the very same single 
WAN link and the very same shaping rules (bandwidth caps etc.). 
Furthermore, this "failure" has shown up in both of the locations where 
we upgraded.


In testing/observing: 2.0.1 appears to effectively 'clamp' traffic at 
the specified limits, but certain kinds of traffic will still cause 
packet loss audio artifacts where they would not before. For example, a 
simple 'speedtest' on one of the network hosts causes significant packet 
loss audio artifacts (and does so quite reliably).


It occurs to me that this could perhaps be a "bufferbloat" issue 
(www[.]bufferbloat[.]net), perhaps resulting from a change in the 
underlying BSD version.  It seems unlikely, but the thought did occur to 
me.  After all, voice packets older than a few hundred milliseconds 
SHOULD be discarded.


I've changed around numerous settings, including being more conservative 
with the bandwidth guarantees (reducing them), and reducing the 
"Connection up/download" speeds, and I've even changed the schedulers 
around.  I can't seem to find the reliable setup that we enjoyed for 
many years with version 1.x.


Does anyone else experience this? Any hints on what could be going 
wrong, or where I should be looking for hints?


Much obliged,
Karl
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Pfsense Ipad / Iphone - Android - Smartphone App

[Karl Fife]

... At one
point we did look at making the web interface theme for mobile browsers
a lot more finger-friendly, not sure what happened to that. We had a
mock-up screen with some large icons, one per section, and some JS that
would let you pick the menu entries using those.


I think that's all anyone needs. You're right, it can sometimes be a 
kludge on tiny screens.  If a mobile-friendly theme is available, 
somebody might just create the "few dozen of lines of code" to wrap the 
browser-friendly pages in an 'app'.  That might make it very slightly 
more friendly/convenient (for some) to manage/launch the URL's of the 
instances they manage.


-K






Jim
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] Move instance from X to Y, cold spare.

[Karl Fife]

If I have a production system running on hardware X, and I want to move 
it to hardware Y, is there a way to do so by exporting the configuration 
and re-importing it on the other box?  It would appear that the answer 
is YES and it works 100% perfectly UNLESS the hardware interfaces are 
not identical.


In the scenario where the hardware interfaces are NOT the same, is it 
possible to do something simple like search/replace the configuration 
file, substituting the interface names?  Is there any reason to believe 
that process would be less than 100% perfect?  Let's assume I have the 
same NUMBER of interfaces on both machines.


I ask for two reasons:

1. We've got a some production systems running on soekris 5501's, that 
need to be migrated to 6501's for performance reasons. I would prefer as 
little risk of downtime and breakage as possible.


2. It has implications for 'cold spare' strategy in environments where 
high availability is a design priority. IOW, I can keep a 5501 kicking 
around as a cold spare (instead of a SECOND 6501) _IF_ I know with for 
sure that i can quickly re-jigger a backup for a different piece of 
hardware.


Is this feasible, or would it this always require a more iterative 
'hands-on' approach, importing the configurations 'area by area' (dhcp, 
rules, shaper, nat etc) only after the interfaces have been specified?


Thanks
-Karl

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] Got TOE?

[Karl Fife]

 Are there any TCP/IP Offload Engine nic's that pfSense can leverage?  
A TOE in pfSense could function somewhat like the hardware 
packet-forwarding ASICs in the likes of Csco/Juniper etc, No?   If 
supported, it seems that a TOE could be an enabling factor for pfSense 
in some applications where the speed of software switching is a limiting 
factor, and inch pfSense closer parity with commercial high-speed 
switching.  Am I thinking about this correctly?


IIRC, integrating a TOE in any OS is tricky because it violates some 
principles of kernel architecture, no?   I don't know enough about the 
state of the TOE art to know whether it is supported, feasable, or even 
worthwhile (at the current rate of improvement in software switching).  
Does anyone want to take a stab at this?  I would very much appreciate it!


Thanks
-Karl
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Dynamic DNS force update?

[Karl Fife]

The file:
/cf/conf/dyndns_wanzoneedit'my.domain.net'.cache

Indeed contains the cached IP address, but the file system is mounted 
read-only.  I assume this is due to the fact that I am running the 
embedded version.


I'm starting to think that the answer is an unqualified "NO".
-K


On 2/22/2012 1:28 PM, newsgroups.ma...@stefanbaur.de wrote:

Am 22.02.2012 19:06, schrieb Karl Fife:

My question is of course, HOW. How does one change the cached number
without releasing the address on the monitored interface?
-K


Have a look at the files matching /conf/dyndns* and try editing those.

-Stefan

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Dynamic DNS force update?

[Karl Fife]

My question is of course, HOW. How does one change the cached number 
without releasing the address on the monitored interface?

-K

On 2/22/2012 11:47 AM, Bob Gustafson wrote:

Change the cached number, then do as Martin Fuchs suggested.

On Wed, 2012-02-22 at 10:02 -0600, Karl Fife wrote:

Hi Martin. You've hit right on the problem. The IP is NOT different
than the cached IP, thus the client will not update no matter what I
do, even if I delete the entry entirely and re-create it (much less
your simpler suggestion).

My question very specifically was whether is it possible to force an
update WITHOUT changing the interface address (i.e. without changing
the address as a method of making the IP different than the cached IP)

Does anyone know if it is possible?
Should the client be tweaked to check the DNS host in addition to
checking the cached value, or have something like a "force update"
function?

-Karl



On 2/22/2012 6:14 AM, Fuchs, Martin wrote:

Hi !



Try editing the dyndns-provider and just hit the save button J

This should work, if the ip is different from the cached ip



Regards,

martin



Von: list-boun...@lists.pfsense.org
[mailto:list-boun...@lists.pfsense.org] Im Auftrag von Karl Fife
Gesendet: Mittwoch, 22. Februar 2012 06:12
An: list@lists.pfsense.org
Betreff: [pfSense] Dynamic DNS force update?




Is there a way to force the Dynamic DNS client to post an update?
It would appear that the only way to do this is to change the IP
address bound to the montored interface.
My question very specifically is, is it possible to force an update
WITHOUT changing the interface address?

I have a remote installation where I want to configure the DDNS
client, and currently the DNS server currently has the WRONG
address, so naturally I would like the correction to be performed by
the DDNS client as a validation of the initial configuration.  The
problem is that the client will not post an update because it ONLY
looks to see if the cached IP value on the interface has not
changed.  It does not (for example) look to the DNS host to see if
there's a mismatch.

Disabling/Enabling the client will NOT trigger an update because it
still relies only on the cached value of the interface.
DELETING and re-creating the client entry completely will also fail
to trigger an update for the same reason.

Obviously I can't release the remote WAN IP address from the
interface because I would lose my connectivity.

Is there a way to clear this cached value, or force an update? Maybe
from the command line?

Can I put in a plea to include a 'force update' button, in a future
release, or preferably have the client just automatically dip the
DNS host to check to see if there is an initial IP mismatch?   At a
minimum it seems this should happen at the creation of the client,
perhaps also when settings are changed or when the client is
bounced.

If you have an urge to say "Just go change the A record the first
time", please sit on your hands. :-)

Thanks!
-K







___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list



___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Re: [pfSense] Dynamic DNS force update?

[Karl Fife]

Hi Martin. You've hit right on the problem. The IP is NOT different than 
the cached IP, thus the client will not update no matter what I do, even 
if I delete the entry entirely and re-create it (much less your simpler 
suggestion).


My question very specifically was whether is it possible to force an 
update WITHOUT changing the interface address (i.e. without changing the 
address as a method of making the IP different than the cached IP)


Does anyone know if it is possible?
Should the client be tweaked to check the DNS host in addition to 
checking the cached value, or have something like a "force update" function?


-Karl



On 2/22/2012 6:14 AM, Fuchs, Martin wrote:


Hi !

Try editing the dyndns-provider and just hit the save button J

This should work, if the ip is different from the cached ip

Regards,

martin

*Von:*list-boun...@lists.pfsense.org 
[mailto:list-boun...@lists.pfsense.org] *Im Auftrag von *Karl Fife

*Gesendet:* Mittwoch, 22. Februar 2012 06:12
*An:* list@lists.pfsense.org
*Betreff:* [pfSense] Dynamic DNS force update?

Is there a way to force the Dynamic DNS client to post an update?
It would appear that the only way to do this is to change the IP 
address bound to the montored interface.
My question very specifically is, is it possible to force an update 
WITHOUT changing the interface address?


I have a remote installation where I want to configure the DDNS 
client, and currently the DNS server currently has the WRONG address, 
so naturally I would like the correction to be performed by the DDNS 
client as a validation of the initial configuration.  The problem is 
that the client will not post an update because it ONLY looks to see 
if the cached IP value on the interface has not changed.  It does not 
(for example) look to the DNS host to see if there's a mismatch.


Disabling/Enabling the client will NOT trigger an update because it 
still relies only on the cached value of the interface.
DELETING and re-creating the client entry completely will also fail to 
trigger an update for the same reason.


Obviously I can't release the remote WAN IP address from the interface 
because I would lose my connectivity.


Is there a way to clear this cached value, or force an update? Maybe 
from the command line?


Can I put in a plea to include a 'force update' button, in a future 
release, or preferably have the client just automatically dip the DNS 
host to check to see if there is an initial IP mismatch?   At a 
minimum it seems this should happen at the creation of the client, 
perhaps also when settings are changed or when the client is bounced.


If you have an urge to say "Just go change the A record the first 
time", please sit on your hands. :-)


Thanks!
-K




___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list
___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

[pfSense] Dynamic DNS force update?

[Karl Fife]

Is there a way to force the Dynamic DNS client to post an update?
It would appear that the only way to do this is to change the IP address 
bound to the montored interface.
My question very specifically is, is it possible to force an update 
WITHOUT changing the interface address?


I have a remote installation where I want to configure the DDNS client, 
and currently the DNS server currently has the WRONG address, so 
naturally I would like the correction to be performed by the DDNS client 
as a validation of the initial configuration.  The problem is that the 
client will not post an update because it ONLY looks to see if the 
cached IP value on the interface has not changed.  It does not (for 
example) look to the DNS host to see if there's a mismatch.


Disabling/Enabling the client will NOT trigger an update because it 
still relies only on the cached value of the interface.
DELETING and re-creating the client entry completely will also fail to 
trigger an update for the same reason.


Obviously I can't release the remote WAN IP address from the interface 
because I would lose my connectivity.


Is there a way to clear this cached value, or force an update? Maybe 
from the command line?


Can I put in a plea to include a 'force update' button, in a future 
release, or preferably have the client just automatically dip the DNS 
host to check to see if there is an initial IP mismatch?   At a minimum 
it seems this should happen at the creation of the client, perhaps also 
when settings are changed or when the client is bounced.


If you have an urge to say "Just go change the A record the first time", 
please sit on your hands. :-)


Thanks!
-K



___
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list