Age | Commit message (Collapse) | Author |
|
There is no legit reason to not allow ports < 1024.
|
|
|
|
previous state
|
|
(cherry picked from commit 742da889afa4375d5b6cb98dada7f2d3ec2f0326)
|
|
(cherry picked from commit 85c9e0200a4619f0388b7fd7ba9a03f4be933ef5)
|
|
(cherry picked from commit 2cd0498f50296d5d9e80b6acafb63dd3d45fb5cd)
|
|
(cherry picked from commit 87ddd50f55cd80873e295d66803ceb072de6fd74)
|
|
- RADIUS shaper settings
(cherry picked from commit d4556b31e920197e1c58febb8d87a1765bfea81f)
|
|
- implementation for locally definied users
(cherry picked from commit c1dc93391b9ec1785ab648fa7685521c85774d28)
|
|
(cherry picked from commit 47c368136342f235765e1a0b611f0783a73ce299)
|
|
(cherry picked from commit 6b7453ea7d2b17e3988895e4fd8a5e8b634a8f90)
|
|
(cherry picked from commit 334677572aef752b0bf2c893bd14bdf6f801bb4b)
|
|
Conflicts:
Makefile
|
|
(cherry picked from commit 8ae02a738df9746ad648a9611ae03e62b5af9e5d)
|
|
(cherry picked from commit 6b25ed2a44dde77f5cbfbf68fb4f5f661a34c1c0)
|
|
|
|
Poessinger et al.
|
|
The SNMPv3 TSM is very complex and I know 0 users of it. Also this is untested
and I know no way how it could be tested. Instead of carrying on dead and
unused code we should favour a drop of it using a proper config migration
script.
(cherry picked from commit 556b528ef9cc1eca9d142ebe1f8f88cd02d536da)
|
|
As of the SNMP specification an SNMP engine ID should be unique per device.
To not make it more complicated for users - only use the global SNMP engine ID.
(cherry picked from commit d523111279b3a9a5266b442db5f04049a31685f7)
|
|
(cherry picked from commit 7f9dceaa7898d6418edcdf148b52b66ccd3bd36a)
|
|
(cherry picked from commit 03c09b1b0d7dfdab9fc87bc7b017455c45141ced)
|
|
(cherry picked from commit 6a6634b02d73cc93cd7368cf2290940b57fae9c7)
|
|
(cherry picked from commit 87df87e3983e120ad171ae9dc2966309fc14fcd8)
|
|
|
|
to follow the established convention.
|
|
Implementation by Daniil Baturin and John Estabrook.
|
|
|
|
Netmasks (both IPv4 and IPv6) that are allowed to use the server. The default
allows access only from RFC 1918 private IP addresses. Due to the aggressive
nature of the internet these days, it is highly recommended to not open up the
recursor for the entire internet. Questions from IP addresses not listed here
are ignored and do not get an answer.
https://docs.powerdns.com/recursor/settings.html#allow-from
Imagine an ISP network with non RFC1918 IP adresses - they can't make
use of PowerDNS recursor.
As of now VyOS hat allow-from set to 0.0.0.0/0 and ::/0 which created an open
resolver. If there is no allow-from statement a config-migrator will add
the appropriate nodes to the configuration, resulting in:
service {
dns {
forwarding {
allow-from 0.0.0.0/0
allow-from ::/0
cache-size 0
ignore-hosts-file
listen-address 192.0.2.1
}
}
}
(cherry picked from commit dc0f641956d002fa8588ef8d1213791cf36e92f2)
|
|
(cherry picked from commit 36f8a1e4e5966c43c5330ff223fa2ef07d346b6e)
|
|
- added a validator for checking if the address is any cidr noted address
(cherry picked from commit 2ee0eff1bd04ef02b0769341eee22543f8011b68)
|
|
(cherry picked from commit d99bf6a3a623433e743bb2d1d72e2ef3e0ab5057)
|
|
|
|
|
|
Conflicts:
src/conf_mode/host_name.py
|
|
* clamp MSS IPv4
set firewall options interface pppoe0 adjust-mss '1452'
* clamp MSS IPv6
set firewall options interface pppoe0 adjust-mss6 '1452'
* disable entire rule
set firewall options interface pppoe0 disable
Output
------
$ sudo iptables-save -t mangle
# Generated by iptables-save v1.4.21 on Sun Apr 21 12:56:25 2019
*mangle
:PREROUTING ACCEPT [1217:439885]
:INPUT ACCEPT [290:52459]
:FORWARD ACCEPT [920:375774]
:OUTPUT ACCEPT [301:100053]
:POSTROUTING ACCEPT [1221:475827]
:VYOS_FW_OPTIONS - [0:0]
-A FORWARD -j VYOS_FW_OPTIONS
-A VYOS_FW_OPTIONS -o pppoe0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
COMMIT
Completed on Sun Apr 21 12:56:25 2019
|
|
Add support for relaying a DHCPv6 packet to multiple servers on one upstream
interface.
(cherry picked from commit d5b113923aaa776f89749c820d6283b593e80c3a)
|
|
using fully-qualified domain name
|
|
(cherry picked from commit 0fefe3c3b9250ad2ba841287a94036119728c708)
|
|
disable' to disable single peers
Conflicts:
debian/changelog
|
|
|
|
Conflicts:
debian/changelog
|
|
(cherry picked from commit 31b1b2cb8873f62f8054c87953cd8bd59b59add1)
|
|
The name-server option under "service dns-forwarding" was never mandatory so
users never needed to specify an upstream server. With the recent switch to
PowerDNS recursor in VyOS 1.2.0 we will act as a full DNS recursor when
there is no upstream DNS server configured.
(cherry picked from commit 3c563b3ae8397da33a03c0429c17b97eb9625c5f)
|
|
This reverts commit 51f61991092a163f680e4ec8f122e73f4074ddf9.
It's not how it's done, those templates are generated by a script in
vyatta-cfg-firewall.
If we are planning a firewall overhaul in 1.3.x, there's no reason to
transplant the old approach to new code.
|
|
|
|
|
|
|
|
|
|
|
|
|