- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Sep 28 2022
Maybe something wrong with this check https://github.com/vyos/vyos-1x/blob/f5a50135f07ac4ec8ed431a757b9c56e607d2132/src/conf_mode/dhcp_server.py#L265-L271
Maybe incorrect parsing of port ranges (comma-separated)
rule 120 {
description "Playstation - 172.16.136.96"
destination {
port 1935,3074,3478,3479,3480
}PRs open to implement this:
Sep 27 2022
vyos@vyos:~$ show configuration
firewall {
interface eth2 {
in {
name OUTSIDE-IN
}
local {
name OUTSIDE-LOCAL
}
}
name OUTSIDE-IN {
default-action drop
rule 10 {
action accept
state {
established enable
related enable
}
}
rule 20 {
action accept
destination {
address 172.16.135.35
port 8123
}
protocol tcp
source {
}
state {
new enable
}
}
rule 21 {
action accept
destination {
address 172.16.135.35
port 443
}
protocol tcp
state {
new enable
}
}
rule 30 {
action accept
destination {
address 172.16.136.16
port 22
}
protocol tcp
source {
address 13.90.97.251
}
state {
new enable
}
}
rule 40 {
action accept
destination {
address 172.16.136.96
port 1935,3478,3479,3480
}
protocol tcp
state {
new enable
}
}
rule 41 {
action accept
destination {
address 172.16.136.96
port 3074,3478,3479
}
protocol udp
state {
new enable
}
}
}
name OUTSIDE-LOCAL {
default-action drop
rule 10 {
action accept
state {
established enable
related enable
}
}
rule 20 {
action accept
icmp {
type-name echo-request
}
protocol icmp
state {
new enable
}
}
rule 30 {
action drop
destination {
port 22
}
protocol tcp
recent {
count 4
time minute
}
state {
new enable
}
}
rule 31 {
action accept
destination {
port 22
}
protocol tcp
state {
new enable
}
}
rule 40 {
action accept
destination {
address 172.16.136.35
port 8123
}
protocol tcp
state {
new enable
}
}
}}
interfaces {
ethernet eth0 {
address 172.16.136.1/24
description INSIDE
hw-id 6c:4b:90:52:32:75
}
ethernet eth2 {
address dhcp
description OUTSIDE
hw-id 7c:c2:c6:42:43:e1
}
loopback lo {
}
wireless wlan0 {
hw-id 50:5b:c2:ca:e1:03
physical-device phy0
}}
nat {
destination {
rule 10 {
description "Port Forward: SSH to 172.16.136.16"
destination {
port 22
}
inbound-interface eth2
protocol tcp
source {
address 13.90.97.251
}
translation {
address 172.16.136.16
}
}
rule 100 {
description "HomeAssistant WAN"
destination {
port 8123
}
inbound-interface eth2
protocol tcp
translation {
address 172.16.136.35
}
}
rule 110 {
description "HomeAssistant Reflection To"
destination {
port 8123
}
inbound-interface eth0
protocol tcp
translation {
address 172.16.136.35
}
}
rule 120 {
description "Playstation - 172.16.136.96"
destination {
port 1935,3074,3478,3479,3480
}
inbound-interface eth2
protocol tcp
translation {
address 172.16.136.96
}
}
}
source {
rule 100 {
outbound-interface eth2
source {
address 172.16.136.0/24
}
translation {
address masquerade
}
}
rule 110 {
description "HomeAssistant Reflection From"
destination {
address 172.16.136.0/24
}
outbound-interface eth0
protocol tcp
source {
address 172.16.136.0/24
}
translation {
address masquerade
}
}
}}
service {
dhcp-server {
shared-network-name LAN {
domain-search drutherford.com
subnet 172.16.136.0/24 {
default-router 172.16.136.1
domain-name drutherford.com
lease 86400
name-server 8.8.8.8
name-server 1.1.1.1
name-server 9.9.9.9
range 0 {
start 172.16.136.50
stop 172.16.136.90
}
static-mapping Backyard-Camera-Wireless {
ip-address 172.16.136.101
mac-address 78:66:9D:7F:D7:73
}
static-mapping Garage-Camera-Wireless {
ip-address 172.16.136.99
mac-address 5C:C3:36:4C:D3:20
}
static-mapping Green {
ip-address 172.16.136.16
mac-address DC:A6:32:6D:20:54
}
static-mapping HomeAssistant {
ip-address 172.16.136.35
mac-address B8:27:EB:81:ED:01
}
static-mapping Playstation4 {
ip-address 172.16.136.96
mac-address 00:D9:D1:FD:E3:C8
}
static-mapping Pool-Camera-Wireless {
ip-address 172.16.136.100
mac-address 78:66:9D:5B:F8:9C
}
static-mapping RasPBX {
ip-address 172.16.136.102
mac-address B8:27:EB:BA:9C:BD
}
static-mapping Roku-3 {
ip-address 172.16.136.98
mac-address B8:3E:59:B3:DF:DB
}
static-mapping Roku-Ultra {
ip-address 172.16.136.97
mac-address 88:DE:A9:C1:C0:41
}
static-mapping client1 {
ip-address 172.16.136.102
mac-address B8:27:EB:BA:9C:BD
}
}
}
}
ssh {
port 22
}}
system {
config-management {
commit-revisions 100
}
conntrack {
modules {
ftp
h323
nfs
pptp
sip
sqlnet
tftp
}
}
console {
device ttyS0 {
speed 115200
}
}
host-name vyos
login {
user vyos {
authentication {
encrypted-password ****************
}
}
}
ntp {
server time1.vyos.net {
}
server time2.vyos.net {
}
server time3.vyos.net {
}
}
syslog {
global {
facility all {
level info
}
facility protocols {
level debug
}
}
}}
Can we see example destination NAT config with the issue?
still no good
vyos@vyos:~$ show nat destination rules
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/nat.py", line 302, in <module> res = vyos.opmode.run(sys.modules[__name__]) File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 147, in run res = func(**args) File "/usr/libexec/vyos/op_mode/nat.py", line 280, in show_rules return _get_formatted_output_rules(nat_rules, direction, family) File "/usr/libexec/vyos/op_mode/nat.py", line 112, in _get_formatted_output_rules if 'prefix' in match['right'] or 'set' in match['right']:
TypeError: argument of type 'int' is not iterable
vyos@vyos:~$ show version
Version: VyOS 1.4-rolling-202209260217
Release train: sagitta
DEMO Notes:
=====================
1) You need to load the XDP program before starting frr so that
it can find the LPM map on plugin initialization.
To keep it simple, the VTY interface was not implemented for now.
XDP side is accessible via `bpftool`
3) I`m monitoring packets for TOS/DSCP changes to see if marking happens
But in another approach tag is associated with the packet and then
read by the TC classifier
4) These are two traffic shaping examples.
The point is that you have two options for marking:
4.1) Modifying the TOS byte and installing the u32 tc filter to match the value.
This has a limited range of possible values (8 bits) + needs to modify the packet.
4.2) Using a custom BPF classifier.
The XDP side extends the packet context and saves the value.
Afterward, the classifier may read the context and control the shaping behavior
by setting the `skb->tc_classid` or one of the fields mentioned below.Therefore, BPF programs attached to the tc BPF hook can, for instance, read or write the skb’s mark, pkt_type, protocol, priority, queue_mapping, napi_id, cb[] array, hash, tc_classid or tc_index, vlan metadata, the XDP transferred custom metadata and various other information. All members of the struct __sk_buff BPF context used in tc BPF are defined in the linux/bpf.h system header. https://docs.cilium.io/en/stable/bpf/#tc-traffic-control
Should be fixed in the commit https://github.com/vyos/vyos-1x/pull/1552/files#diff-9e98077e1229d7a89e26efdc517896728265a8669e8824aaf92611b113fa3516L47
T4605
Try the latest rolling
Should be fixed in the commit https://github.com/vyos/vyos-1x/pull/1552/files#diff-9e98077e1229d7a89e26efdc517896728265a8669e8824aaf92611b113fa3516L47
T4605
Try the latest rolling
Sep 26 2022
It seems like I was wrong about the netfilter rule not working as intended (and in my testing the clamp was broken for some other reason that was an error on my part), the post has been edited to only indicate the remaining issue of an overly strict MSS clamping range.
Sep 25 2022
Send steps to reproduce it or “show conf com | match nat”
Send steps to reproduce it or “show conf com | match openvpn ”
Sep 24 2022
See https://unix.stackexchange.com/questions/672742/why-mss-clamping-in-iptables-nft-seems-to-take-no-effect-in-nftables for additional explanation why the iptables version do not work under iptables-nft.
Relevant PRs:
Sep 22 2022
PR for Jump: https://github.com/vyos/vyos-1x/pull/1553
PR with feature request:
https://github.com/vyos/vyos-1x/pull/1555
@sdev @Netboy3 I'll test if the new implementation is done and if the bug is fixed I'll close this PR, thanks
@jack9603301 I've tested your updated PR and it seems to work well now. Thank you for the quick response.
@sdev I've tested your PR and it seems to also fix both issues. I did not test anything beyond DNAT port only in both ip and ip6 families.
