mirror of
https://github.com/opnsense/docs.git
synced 2026-05-28 04:02:12 -04:00
Another round of corrections (#84)
This commit is contained in:
MichaelDeciso
Ad Schellevis
parent
3756ed16fa
commit
d1c5ac2798
21 changed files with 55 additions and 55 deletions
|
|
@ -43,7 +43,7 @@ make html
|
|||
|
||||
|
||||
#### Changing theme
|
||||
* Install Sass (http://sass-lang.com/), on OSX via ```/Library/Ruby/Gems```
|
||||
* Install Sass (http://sass-lang.com/). On macOS, this is done via ```/Library/Ruby/Gems```
|
||||
```
|
||||
gem install --no-user-install sass
|
||||
```
|
||||
|
|
|
|||
|
|
@ -21,18 +21,18 @@ determine if a page can be accessed by a user:
|
|||
user)
|
||||
#. One or more groups for that user, stored in system/group which
|
||||
contains priv sections.
|
||||
#. A php file binding the priv section content to a page mask (including
|
||||
#. A PHP file binding the priv section content to a page mask (including
|
||||
wildcards)
|
||||
|
||||
Our temporary solution is to keep the user and the group in place and replace the
|
||||
php file with a simple config in the model which uses the same mask construction
|
||||
PHP file with a simple config in the model which uses the same mask construction
|
||||
there was in the old codebase. To bind priv to pages, edit models/OPNsense/Core/ACL\_Legacy\_Page\_Map.txt
|
||||
|
||||
--------------
|
||||
Usage from php
|
||||
Usage from PHP
|
||||
--------------
|
||||
|
||||
Using the system from php is rather simple:
|
||||
Using the system from PHP is rather simple:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ automatically understands the second file.
|
|||
|
||||
(/usr/local/opnsense/mvc/app/models/OPNsense/HelloWorld/HelloWorld.php)
|
||||
|
||||
Not all modules contain additional code in the php class, sometimes all
|
||||
Not all modules contain additional code in the PHP class, sometimes all
|
||||
the standard behaviour is already sufficient for your
|
||||
modules/application.
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ Every OPNsense module should separate presentation from logic, that’s
|
|||
why there should always be multiple controllers per module.
|
||||
|
||||
Our first controller handles the template rendering to the user and
|
||||
connects the user view we just created. We start by creating a php file
|
||||
connects the user view we just created. We start by creating a PHP file
|
||||
in controllers/OPNsense/HelloWorld/ with the following name
|
||||
IndexController.php and contents:
|
||||
|
||||
|
|
@ -630,8 +630,8 @@ code:
|
|||
(/usr/local/opnsense/mvc/app/controllers/OPNsense/HelloWorld/Api/ServiceController.php)
|
||||
|
||||
This validates the type of action (it should always be POST to enable
|
||||
csrf protection) and adds a backend action for reloading the template.
|
||||
When successful the action will return “status”:”ok” as json object back
|
||||
CSRF protection) and adds a backend action for reloading the template.
|
||||
When successful the action will return "status":"ok" as json object back
|
||||
to the client.
|
||||
|
||||
Now we are able to refresh the template content, but the user interface
|
||||
|
|
@ -675,9 +675,9 @@ next step.
|
|||
Controlling the sample
|
||||
----------------------
|
||||
|
||||
In stead of running all kinds of shell commands directly from the php
|
||||
Instead of running all kinds of shell commands directly from the PHP
|
||||
code, which very often need root access (starting/stopping services,
|
||||
etc), we should always communicate to our backend process which holds
|
||||
etc.), we should always communicate to our backend process which holds
|
||||
templates of possible things to run and protects your system from
|
||||
executing arbitrary commands.
|
||||
|
||||
|
|
@ -785,7 +785,7 @@ This works because we are using the gettext library which is available to all GU
|
|||
While the XML based user interfaces are supporting it automatically,
|
||||
there may still the need to call it manually (buttons, tabs etc.).
|
||||
|
||||
If you have a static string, you should add it like this into a classic php page:
|
||||
If you have a static string, you should add it like this into a classic PHP page:
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ General
|
|||
After routing is performed, the controller takes care of the actual code
|
||||
to execute for the request. Because we want to implement some basics for
|
||||
every request that gets processed you should inherit from our base
|
||||
classes to ensure basic functionality such as authorisation and csrf
|
||||
classes to ensure basic functionality such as authorisation and CSRF
|
||||
protection.
|
||||
|
||||
Controllers are placed in the directory /usr/local/opnsense/mvc/app/controllers/<Vendor\_name>/<Module\_name>/
|
||||
|
|
@ -63,7 +63,7 @@ API based controllers
|
|||
For API calls a separate class is used to derive from, which implements
|
||||
a simple interface to handle calls. The main difference with the view
|
||||
controllers is that an action should return a named array containing
|
||||
response data in stead of picking a template.
|
||||
response data instead of picking a template.
|
||||
|
||||
A simple index controller to echo a request back looks like this:
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ A simple index controller to echo a request back looks like this:
|
|||
}
|
||||
|
||||
When placed inside the API directory of Vendor/Sample can be called by sending a
|
||||
post request to /api/sample/test/echo, using jquery:
|
||||
post request to /api/sample/test/echo, using jQuery:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Designing the model
|
|||
|
||||
Creating models for OPNsense is divided into two separate blocks:
|
||||
|
||||
#. A php class describing the actions on our data (also acts as a
|
||||
#. A PHP class describing the actions on our data (also acts as a
|
||||
wrapper to our data),
|
||||
#. The definition of the data and the rules it should apply to.
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ their own namespace at *OPNsense\\Base\\FieldTypes* deriving from *BaseField*.
|
|||
Usage example
|
||||
-------------
|
||||
|
||||
Now let's test our model using a small php script (in /usr/local/opnsense/mvc/script/ ):
|
||||
Now let's test our model using a small PHP script (in /usr/local/opnsense/mvc/script/ ):
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ API routing
|
|||
Routing for API functions is quite similar to routing UI components,
|
||||
just create a Api directory under the app path and place a controller
|
||||
class to handle the request. The only major difference is that it's
|
||||
handled by a separate php file (called api.php) in stead of the
|
||||
handled by a separate PHP file (called api.php) instead of the
|
||||
index.php file used to configure the ui part, details of the routing can
|
||||
be found in /usr/local/opnsense/mvc/app/config/services\_api.php .
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ General Settings
|
|||
|
||||
|
||||
:DNS Forwarders:
|
||||
A list of IP addresses BIND will forward unknown dns request to. If empty BIND
|
||||
A list of IP addresses BIND will forward unknown DNS request to. If empty BIND
|
||||
tries to resolve directly via the root servers.
|
||||
:Logsize in MB:
|
||||
The amount for each logfile it can grow.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ we will explain briefly first:
|
|||
|
||||
Common Address Redundancy Protocol uses IP protocol 112, is derived from
|
||||
OpenBSD and uses multicast packets to signal its neighbours about its
|
||||
status. Always make sure that each interface can receive carp packets.
|
||||
status. Always make sure that each interface can receive CARP packets.
|
||||
Every virtual interface must have a unique Virtual Host ID (vhid), which
|
||||
is shared across the physical machines. To determine which physical
|
||||
machine has a higher priority, the advertised skew is used. A lower skew
|
||||
|
|
@ -59,7 +59,7 @@ security reasons (state injection) as for performance.
|
|||
:name: xmlrpc-sync
|
||||
|
||||
OPNsense includes a mechanism to keep the configuration of the backup
|
||||
server in sync with the master. This mechanism is called xmlrpc sync and
|
||||
server in sync with the master. This mechanism is called XMLRPC sync and
|
||||
can be found under System -> High Availability.
|
||||
|
||||
-----------------------------------------
|
||||
|
|
@ -91,7 +91,7 @@ setup the following addresses and subnets:
|
|||
|
||||
Next we need to make sure the appropriate protocols can be used on the
|
||||
different interfaces, go to firewall -> rules and make sure both LAN and
|
||||
WAN accept at least carp packets (see protocol selection). Because we're
|
||||
WAN accept at least CARP packets (see protocol selection). Because we're
|
||||
connecting both firewalls using a direct cable connection, we will add a
|
||||
single rule to accept all traffic on all protocols for that specific
|
||||
interface. Another option is to only accept traffic to the GUI port and
|
||||
|
|
@ -111,7 +111,7 @@ The backup server needs its own dedicated addresses, we will use these:
|
|||
+----------+-------------------+
|
||||
|
||||
Because we are going to synchronize firewall settings between both
|
||||
hosts, we only need to make sure that the pfsync interface can accept
|
||||
hosts, we only need to make sure that the pfSync interface can accept
|
||||
data from the master for the initial setup. Use the same rule as used
|
||||
for the master on this interface.
|
||||
|
||||
|
|
@ -175,12 +175,12 @@ nat on this page and change the rules originating from the
|
|||
(optional) Setup DHCP server
|
||||
----------------------------
|
||||
|
||||
When using dhcp for the local area network, there are some things to
|
||||
consider. All clients should use the virtual address in stead of the
|
||||
When using DHCP for the local area network, there are some things to
|
||||
consider. All clients should use the virtual address instead of the
|
||||
physical address it's normally propagating. Next thing to consider is
|
||||
there will be two servers active at the same time, which should know of
|
||||
each others pools. If dns requests are also forwarded by OPNsense, make
|
||||
sure the dhcp server sends the right IP address. These are settings used
|
||||
each others pools. If DNS requests are also forwarded by OPNsense, make
|
||||
sure the DHCP server sends the right IP address. These are settings used
|
||||
in our example (on the master server):
|
||||
|
||||
+--------------------+----------------+
|
||||
|
|
@ -196,7 +196,7 @@ Setup HA sync (xmlrpc) and pfSync
|
|||
---------------------------------
|
||||
|
||||
First we should enable pfSync using our dedicated interface using the
|
||||
master firewall. Go to System -> High Availability, enable pfsync and
|
||||
master firewall. Go to System -> High Availability, enable pfSync and
|
||||
select the interface used for pfSync. Next setup the peer IP to the
|
||||
other hosts address (10.0.0.2).
|
||||
|
||||
|
|
|
|||
|
|
@ -2,15 +2,15 @@
|
|||
Setup IPsec Road-Warrior
|
||||
========================
|
||||
Road Warriors are remote users who need secure access to the companies infrastructure.
|
||||
IPsec Mobile Clients offer a solution that is easy to setup with OSX (native)
|
||||
IPsec Mobile Clients offer a solution that is easy to setup with macOS (native)
|
||||
and is know to work with iOS as well as many Android devices.
|
||||
|
||||
For more flexibility use SSL VPN's, OPNsense utilizes OpenVPN for this purpose.
|
||||
For more flexibility use SSL VPNs, OPNsense utilizes OpenVPN for this purpose.
|
||||
|
||||
With this example we'll show you how to configure the Mobile Client Setup in
|
||||
OPNsense and give you configuration examples for:
|
||||
|
||||
* OSX
|
||||
* macOS
|
||||
* iOS
|
||||
* Android
|
||||
|
||||
|
|
@ -272,16 +272,16 @@ Add privilege **User - VPN - IPsec xauth Dialin** by pressing the **+** under
|
|||
-------------------------
|
||||
Step 5 - Configure Client
|
||||
-------------------------
|
||||
To illustrate the client setup we will look at the configuration under OSX, including
|
||||
To illustrate the client setup we will look at the configuration under macOS, including
|
||||
some screenshots. The configurations for Android and iOS will be settings only.
|
||||
|
||||
.. Note::
|
||||
Configuration samples listed here where created using latest OSX, iOS and
|
||||
Configuration samples listed here where created using latest macOS, iOS and
|
||||
Android devices on time of publication in February 2016.
|
||||
|
||||
--------------------
|
||||
Configure OSX Client
|
||||
--------------------
|
||||
----------------------
|
||||
Configure macOS Client
|
||||
----------------------
|
||||
|
||||
Start with opening your network settings (System Preferences -> Network) and
|
||||
Add a new network by pressing the + in the lower left corner.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Setup IPsec site to site tunnel
|
||||
================================
|
||||
|
||||
Site to site VPN's connect two locations with static public IP addresses and allow
|
||||
Site to site VPNs connect two locations with static public IP addresses and allow
|
||||
traffic to be routed between the two networks. This is most commonly used to
|
||||
connect an organization's branch offices back to its main office, so branch users
|
||||
can access network resources in the main office.
|
||||
|
|
@ -513,7 +513,7 @@ Phase 1 works but no phase 2 tunnels are connected
|
|||
---------------------------------------------------
|
||||
|
||||
Did you set the correct local and remote networks. A common mistake is to fill in
|
||||
the IP address of the remote host in stead of its network ending with **x.x.x.0**
|
||||
the IP address of the remote host instead of its network ending with **x.x.x.0**
|
||||
|
||||
Common issues are unequal settings. Both ends must use the same encryption standard.
|
||||
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ Use the following settings:
|
|||
* Member Down
|
||||
*Triggers when the gateway has 100% packet loss.*
|
||||
* Packet Loss
|
||||
*Triggers when the packet loss to a gateway is higher then the defined threshold.*
|
||||
*Triggers when the packet loss to a gateway is higher than the defined threshold.*
|
||||
* High Latency
|
||||
*Triggers when the latency to a gateway higher than its defined threshold.*
|
||||
* Packet Loss or High Latency
|
||||
|
|
@ -195,7 +195,7 @@ To set this option can be set under **Firewall->Settings->Advanced**.
|
|||
Unequal Balancing (Weight)
|
||||
--------------------------
|
||||
If you have a non symmetric setup with one IPS having a much higher
|
||||
bandwidth that the other then you can set a weight on each gateway to change the
|
||||
bandwidth than the other then you can set a weight on each gateway to change the
|
||||
load balance. For instance if you have one line of 10 Mbps and one of 20 Mbps then
|
||||
set the weight of the first one to 1 and the second one to 2. This way the second
|
||||
gateway will get twice as many traffic to handle than the first.
|
||||
|
|
|
|||
|
|
@ -18,5 +18,5 @@ For local analysis using Insight also enable **Capture local**.
|
|||
Depending on the application you would like to use select **Version** 5 or 9.
|
||||
Remember that version 5 does not support IPv6.
|
||||
|
||||
Add your **Destinations** (ip:port then enter) local IP will be added automatic
|
||||
Add your **Destinations** (ip:port then enter) local IP will be added automatically
|
||||
if Capture local is selected.
|
||||
|
|
|
|||
|
|
@ -80,9 +80,9 @@ For a location, the following directives are important:
|
|||
Directive Description
|
||||
=============================== ======================================================================
|
||||
Match Type and URL Pattern How to match the location and the pattern
|
||||
File System Root directory of web applicaton
|
||||
File System Root Directory of web applicaton
|
||||
Upstream Servers Send it to a remote interpreter instead of using the local one
|
||||
Pass Request To PHP Interpreter Check if you want to enable php (runs locally as user www) or remotely
|
||||
Pass Request To PHP Interpreter Check if you want to enable PHP (runs locally as user www) or remotely
|
||||
Router Script Sends all request to a specific script (entry point of application)
|
||||
=============================== ======================================================================
|
||||
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ Step 5 - Configure ICAP
|
|||
To configure ICAP go to **Services->Proxy->Administration** And select **ICAP Settings**
|
||||
for the **Forward Proxy** tab.
|
||||
|
||||
Select enable ICAP and filling the Request and Response URL's.
|
||||
For Symantecs Protection Engine the look like this:
|
||||
Select enable ICAP and filling the Request and Response URLs.
|
||||
For Symantecs Protection Engine they look like this:
|
||||
|
||||
======================== ===================================
|
||||
**Request Modify URL** icap://192.168.2.1:1344/avscanreq
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Step 4 - Configure ICAP
|
|||
To configure ICAP go to **Services->Proxy->Administration** And select **ICAP Settings**
|
||||
for the **Forward Proxy** tab.
|
||||
|
||||
Select enable ICAP and filling the Request and Response URL's.
|
||||
Select enable ICAP and filling the Request and Response URLs.
|
||||
For the C-ICAP plugin, the default URLs will be:
|
||||
|
||||
======================== =========================
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@
|
|||
<value>default</value>
|
||||
</item>
|
||||
<item>
|
||||
<descr>Randomize PID's (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<descr>Randomize PIDs (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<tunable>kern.randompid</tunable>
|
||||
<value>default</value>
|
||||
</item>
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@
|
|||
<value>default</value>
|
||||
</item>
|
||||
<item>
|
||||
<descr>Randomize PID's (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<descr>Randomize PIDs (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<tunable>kern.randompid</tunable>
|
||||
<value>default</value>
|
||||
</item>
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@
|
|||
<value>default</value>
|
||||
</item>
|
||||
<item>
|
||||
<descr>Randomize PID's (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<descr>Randomize PIDs (see src/sys/kern/kern_fork.c: sysctl_kern_randompid())</descr>
|
||||
<tunable>kern.randompid</tunable>
|
||||
<value>default</value>
|
||||
</item>
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ and give you configuration examples for:
|
|||
|
||||
* Two Factor Authentication (2FA)
|
||||
* Multi Factor Authentication ( Client Certificate + Password + OTP )
|
||||
* Client configuration on Windows, OSX, iOS and Android
|
||||
* Client configuration on Windows, macOS, iOS and Android
|
||||
|
||||
.. Note::
|
||||
|
||||
|
|
@ -308,9 +308,9 @@ however you may decide just to allow traffic to one or more servers.
|
|||
Step 3 - Export Client Configuration
|
||||
-------------------------------------
|
||||
|
||||
Mac OSX & Windows
|
||||
macOS & Windows
|
||||
-----------------
|
||||
For Mac OSX & Windows users we recommend using Viscosity from Sparklabs (https://www.sparklabs.com/viscosity/).
|
||||
For macOS & Windows users we recommend using Viscosity from Sparklabs (https://www.sparklabs.com/viscosity/).
|
||||
Viscosity is very easy to setup and use and works well on both platforms.
|
||||
|
||||
Go to **VPN->OpenVPN->Client Export** and select the newly created VPN server from
|
||||
|
|
@ -321,7 +321,7 @@ Now on your Mac or Windows PC unpack the bundle and import the Viscosity.visc fi
|
|||
Double clicking it should be enough to get it imported. When asked for an application
|
||||
to open the file with search and select Viscosity.
|
||||
|
||||
Some sample screenshots (Mac OSX):
|
||||
Some sample screenshots (macOS):
|
||||
|
||||
.. image:: images/viscosity_files.png
|
||||
:width: 100%
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ The device must be the ENTIRE device (in Windows/DOS language: the 'C'
|
|||
partition), and a raw I/O device (the 'r' in front of the device "sd6"),
|
||||
not a block mode device.
|
||||
|
||||
**Mac OS X**
|
||||
**macOS**
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ utility makes the client configuration a breeze.
|
|||
--------------------------
|
||||
Supported VPN technologies
|
||||
--------------------------
|
||||
OPNsense offers a wide range of VPN technologies ranging from modern SSL VPN's to
|
||||
OPNsense offers a wide range of VPN technologies ranging from modern SSL VPNs to
|
||||
well known IPsec as well as older (now considered insecure) legacy options such as
|
||||
L2TP and PPTP.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue