Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - NOYB

Pages: [1] 2 3 4 5 ... 18
1
Feedback / SFF Friendliness
« on: May 27, 2017, 05:09:04 am »
Not a big "smart" phone user but SFF friendliness would be nice.

2
General Questions / Missing Link
« on: May 14, 2017, 09:22:29 pm »
What is the purpose of this link to nowhere?

Code: [Select]
[2.3.4-RELEASE][root@pfSense.localdomain]/: ls -la
lrwxr-xr-x   1 root  wheel           11 Apr 11  2016 sys -> usr/src/sys

[2.3.5-DEVELOPMENT][root@pfSense.localdomain]/: ls -la
lrwxr-xr-x   1 root  wheel           11 Apr 11  2016 sys -> usr/src/sys

[2.4.0-BETA][root@pfSense.localdomain]/: ls -la
lrwxr-xr-x   1 root  wheel           11 Sep  9  2016 sys -> usr/src/sys

3
Installation and Upgrades / makewhatis not found
« on: May 05, 2017, 04:01:26 pm »

Is makewhatis supposed to e installed?

[5/42] Extracting perl5-5.24.1:..........done
makewhatis: not found
makewhatis: not found
[6/42] Upgrading pcre from 8.39_1 to 8.40...

4
Feedback / 502 Bad Gateway
« on: April 20, 2017, 06:04:56 pm »
Getting some 502 bad gateway on the forum's today.

5
webGUI / Sys Info Widget Getting Out of Hand
« on: April 14, 2017, 10:46:09 pm »
The system information widget is getting out of hand.  It needs to be split out by info and operational.

System/Serial number, BOIS, and CPU type could initiate  a new informational section.  No doubt there would be other future additions.

6
General Discussion / Secure Zone Monitor
« on: April 05, 2017, 12:23:54 am »
I know there are online tools for monitoring the trust chain.  But in the spirit of my handle (NOYB); It is None Of Their Business.  i.e. don't like relying on third party tools for monitoring.  Like for it to be in house service.

Think it would make a good addition to pfSense.  Maybe something as simple as just periodically requesting a specified record and generating an alert if the response cannot be validated.

7
General Discussion / "True" VPS Provider
« on: March 15, 2017, 07:53:37 pm »
Looking for a good VPS provider that supplies "true" VPS.  Not an OpenVZ container etc.

Just for personal use.  Sort of a hobby/sandbox.  So don't need a high end system.
maybe up to a gig RAM
7-10 GB storage
single core
1 maybe 2 static IP addresses
reverse resolve IP to my domain, and reverse PTR.
Linux CentOS 7

Current provider supplies OpenVZ.  It works, but has some limitations and quirks that I'd prefer not to endure.


8
Feedback / Message Time Format
« on: March 11, 2017, 09:13:35 pm »
Is it possible to drop the leading zero in the message time hour field?  When I see a '0' there I immediately think AM.  Since 12 hour format with AM/PM designation is being used there is no need for the leading zero.

9
Development / SSH GitSync
« on: March 02, 2017, 04:14:21 pm »
To use SSH for gitsync rather than the GIT protocol.

1) Place the OpenSSH private key file in the /root/.ssh directory similar to this example and set permissions to either 0000 or 0400.  If permissions are too open it will be rejected.
Code: [Select]
/root/.ssh/MYGIT_OpenSSH_Private_Key

2) Create the file /root/.ssh/config with content similar to this example.
Code: [Select]
# GitHub git/MYGIT account
Host github.com-git
    HostName github.com
    User git
    IdentityFile ~/.ssh/MYGIT_OpenSSH_Private_Key

3) SSH gitsync should now work with a playback command similar to this example.
Code: [Select]
playback gitsync --minimal --diff --show-files --dry-run git@github.com-git:MYGIT/pfsense.git master

This can also be used with a personal private git server to avoid running a git daemon that exposes the repos to the world.

Notes:
   Replace "MYGIT" with user name.
   The "Host" is case sensitive.
   The "-git" suffix can be omitted from the host.  It is used in examples for clarity.
   If the user ID (git@) is omitted from the playback command URL, then the "User" ID specified in the config file will be used.

10
General Discussion / Power Outage
« on: February 28, 2017, 06:01:27 pm »
Notebook pfSense and UPS supported network is great.  Just survived a 40 minute power outage.

Power outages don't occur very often and are usually only a few minutes with they do.  But this one had me wondering how much longer the UPS would hold up.  After about 15 minutes though I did shutdown unnecessary equipment to help stretch battery life.  Otherwise I'm guessing it would only last about 30 minutes.

11
A colleague just IM'd me this.

Cloudflare reports a security problem with edge servers. Seeing corrupted web pages being returned by some HTTP requests run through Cloudflare.
https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
" our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies   "
Code fix:   One character—an instance of "==" that should have been ">=". That was it.

12
Development / sprintf or direct assignment
« on: February 11, 2017, 07:18:26 pm »
Assuming internationalization (gettext translation) is not needed.  Is it better to use sprintf or direct assignment to build up str?  Especially if there are many to do.  Say few a dozen.

Are there any lurking gotchas that would make one or the other less desirable?
I know it would not be user perceptible, but which one takes less processing to accomplish?

Just thinking why make a bunch of sprintf calls if no benefit.

Code: [Select]
$str .= sprintf ("Some text %s\n", $var);
$str .= "Some text ". $var . "\n";

13
NAT / NAT Reflection Controversy
« on: February 03, 2017, 06:07:47 pm »
People can rail against NAT reflection ("hairpinning") all they want.  But from what I see in the RFC's it is a NAT requirement.  It is a legitimate capability to be used for meeting certain requirements.  Not everyone's requirements center around elegance and performance, etc.  Though from a configuration and management standpoint it is fairly elegant.

Those who have a problem with NAT reflection being an RFC NAT requirement/standard should take it up with the IETF.  Making emotional demagoguery rants about it here does little good for anyone.  Though I do appreciate seeing who has closed minds with what essentially amounts to an emotional do it "this way" or you're an idiot mentality.  Without any consideration for what the specific requirements are.

NAT reflection ("hairpinning") has been an RFC compliance requirement since at least 2007 (RFC 4787).  And continued in 2008 (RFC 5382).  Far as I could find has not be rescinded in any subsequent updates.  These folks involved with the RFC's probably know a thing or two on the subject.


https://tools.ietf.org/html/rfc4787
Network Working Group                                      F. Audet, Ed.
Request for Comments: 4787                               Nortel Networks
BCP: 127                                                     C. Jennings
Category: Best Current Practice                            Cisco Systems
                                                            January 2007

https://tools.ietf.org/html/rfc4787#section-12
12.  Requirements

   The requirements in this section are aimed at minimizing the
   complications caused by NATs to applications, such as realtime
   communications and online gaming.  The requirements listed earlier in
   the document are consolidated here into a single section.

   It should be understood, however, that applications normally do not
   know in advance if the NAT conforms to the recommendations defined in
   this section.  Peer-to-peer media applications still need to use
   normal procedures, such as ICE [ICE].

   A NAT that supports all the mandatory requirements of this
   specification (i.e., the "MUST"), is "compliant with this
   specification".  A NAT that supports all the requirements of this
   specification (i.e., including the "RECOMMENDED") is "fully compliant
   with all the mandatory and recommended requirements of this
   specification".

REQ-9:  A NAT MUST support "Hairpinning".

      a) A NAT Hairpinning behavior MUST be "External source IP address
         and port".



https://tools.ietf.org/html/rfc5382
Network Working Group                                       S. Guha, Ed.
Request for Comments: 5382                                    Cornell U.
BCP: 142                                                       K. Biswas
Category: Best Current Practice                            Cisco Systems
                                                                 B. Ford
                                                                 MPI-SWS
                                                            S. Sivakumar
                                                           Cisco Systems
                                                            P. Srisuresh
                                                          Kazeon Systems
                                                            October 2008


https://tools.ietf.org/html/rfc5382#section-7.2
7.2.  Hairpinning Behavior

   NATs that forward packets originating from an internal address,
   destined for an external address that matches the active mapping for
   an internal address, back to that internal address are defined in
   [BEHAVE-UDP] as supporting "hairpinning".  If the NAT presents the
   hairpinned packet with an external source IP address and port (i.e.,
   the mapped source address and port of the originating internal
   endpoint), then it is defined to have "External source IP address and
   port" for hairpinning.  Hairpinning is necessary to allow two
   internal endpoints (known to each other only by their external mapped
   addresses) to communicate with each other.  "External source IP
   address and port" behavior for hairpinning avoids confusing
   implementations that expect the external source IP address and port.

   REQ-8:  A NAT MUST support "hairpinning" for TCP.
      a) A NAT's hairpinning behavior MUST be of type "External source
         IP address and port".

   Justification:  This requirement allows two applications behind the
      same NAT that are trying to communicate with each other using
      their external addresses.
      a) Using the external source address and port for the hairpinned
         packet is necessary for applications that do not expect to
         receive a packet from a different address than the external
         address they are trying to communicate with.


https://tools.ietf.org/html/rfc5382#section-8
8.  Requirements

   A NAT that supports all of the mandatory requirements of this
   specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP],
   is "compliant with this specification".  A NAT that supports all of
   the requirements of this specification (i.e., included the
   "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully
   compliant with all the mandatory and recommended requirements of this
   specification".

REQ-8:  A NAT MUST support "hairpinning" for TCP.
      a) A NAT's hairpinning behavior MUST be of type "External source
         IP address and port".


14
General Discussion / Magnetic storage - Future
« on: January 19, 2017, 02:11:20 am »
Came across this today when looking up something.  Kind of interesting what may be in store (pun intended) for the future.

Magnetic storage - Future
https://en.wikipedia.org/wiki/Magnetic_storage#Future

15
Toying with the idea of tweaking the URL alias tables RAM disk backup to run as a cron job rather than as part of the URL alias tables download code (/etc/inc/pfsense-utils.inc).

This would complete the stripping of the last bit of RAM disk code out of "pfSense" (/etc/inc/pfsense-utils.inc).  Totally managing it all at the new more central system level.  So "pfSense" itself would be RAM disk unaware.  Other than config settings knobs of course.  Far as it is concerned it is just a disk.

Since the URL alias tables are typically fairly static and downloaded on a schedule, the backup script (/etc/rc.backup_aliastables.sh) only creates a new backup if it is older than the current table.  Or if there is no existing backup.  So a cron job schedule could be as frequent as desired without causing undue write cycles.


Requesting feedback.

Would this be desirable change?

Should the cron job schedule be user configurable along with the others?  Or should it be a statically configure schedule?  If so what would be the preferred backup interval?

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