| 8 Apr 2024 |
 effendy | So it will just communicate over vmbr1, even if the destination IP is that assigned on vmbr0. Because it's using the local table, you mean to say. | 14:44:15 |
 iam_tj | Yes | 14:44:37 |
| iam_tj | I was tracking packets recently and found the nft tracing framework really helpful | 14:51:10 |
| iam_tj | iptables has TRACE target | 14:51:54 |
| iam_tj | From man iptables-extensions:
TRACE
This target marks packets so that the kernel will log every rule which match the packets as those traverse the tables, chains, rules. It can only be used in
the raw table.
With iptables-legacy, a logging backend, such as ip(6)t_LOG or nfnetlink_log, must be loaded for this to be visible. The packets are logged with the string
prefix: "TRACE: tablename:chainname:type:rulenum " where type can be "rule" for plain rule, "return" for implicit rule at the end of a user defined chain and
"policy" for the policy of the built in chains.
With iptables-nft, the target is translated into nftables' meta nftrace expression. Hence the kernel sends trace events via netlink to userspace where they may
be displayed using xtables-monitor --trace command. For details, refer to xtables-monitor(8).
| 14:52:46 |
| effendy | Yeah, this is what I'm using in iptables too. | 14:55:24 |
| effendy | I guess what eventually stood out was that the "GROUP-node-mgmt-IN" rule in the "PVEFW-HOST-IN" chain didn't match and that was the only rule that permitted access to the Proxmox interface. | 14:56:10 |
| effendy | So it did help, but I just didn't understand why that happened and, as I saw, I just mechanically added the rule using -i vmbr1 without fully understanding the flow. | 14:56:41 |
| effendy | * So it did help, but I just didn't understand why that happened and, as you saw, I just mechanically added the rule using -i vmbr1 without fully understanding the flow. | 14:56:49 |
| effendy | But yes, I feel nft tracing is more elegant and easier to follow all in all. | 14:57:21 |
| iam_tj | I wish there was a way to trace routing as well; if there is I haven't found it. With even simple policy routing tracing in netfilter doesn't help | 14:58:09 |
| effendy | Yeah, I've come across this issue too :) | 14:58:44 |
| effendy | I still can't say I fully understand what's going on with the local table, to be honest. What would have happened if the kernel was set in such a way as to refuse packets whose ip destination doesn't match the expected interface, just like you have with "normal" routing and rp_filter? | 15:00:35 |
| effendy | I guess the reason why this work is effectiveness, performance and all that, so that it wouldn't have to add useless processing? | 15:02:04 |
| effendy | * I guess the reason why this works is effectiveness, performance and all that, so that it wouldn't have to add useless processing? | 15:02:09 |
|  binarypatrick joined the room. | 15:34:46 |
| 9 Apr 2024 |
| effendy | I guess I'm not seeing this correctly anyway. rp_filter refers to the ip source, not the ip destination, so the analogy is not correct. It would have applied if the packet whose ip source is 10.99.0.10 (lxc-container) directly reached vmbr0 interface (public/internet facing interface). | 07:13:48 |
| effendy | * I guess I'm not seeing this correctly anyway. rp_filter refers to the ip source, not the ip destination, so the analogy is not correct. It would have applied if the packet whose ip source is 10.99.0.10 (lxc-container) had directly reached vmbr0 interface (public/internet facing interface). | 07:14:06 |
| iam_tj | effendy: I guess the thing we should have thought to do before anything else is ip route get $dest_ip_address since that will show the routing table to be be used and the interface | 08:36:06 |
| effendy | Run on the Proxmox host? | 09:01:58 |
| effendy | Sure, that will show me that the public ip (100.100.100.1) will use the local table and the loopback :) | 09:03:27 |
| effendy | But that's a good hint in any case. I need to use that more often and have it at hand when I'm debugging stuff like that. | 09:03:42 |
| iam_tj | I often forget that but getting better at making it first now I use a lot of policy routing | 09:04:32 |
| iam_tj | one thing to remember about it is check both IPv4 (the default) and IPv6 (ip -6 rule show; ip -6 route show table local) when appropriate so as not to miss something - especially if working with hostnames that may be resolved/preferred on IPv6 (at least locally) | 09:06:25 |
| effendy | I haven't yet got to the point to try out ipv6 unfortunately. I mean, apart from the fact that I think there are still too many implementation issues in general (I know we've talked about that), I would still very much be interested in understanding it. I'd like that at some point. | 09:10:02 |
| effendy | * I haven't yet got to the point to try out ipv6 unfortunately. I mean, apart from the fact that I think there are still too many implementation issues in general (I know we've talked about that alraedy), I would still very much be interested in understanding it. I'd like that at some point. | 09:10:14 |
| effendy | * I haven't yet got to the point to try out ipv6 unfortunately. I mean, apart from the fact that I think there are still too many implementation issues in general (I know we've talked about that already), I would still very much be interested in understanding it. I'd like that at some point. | 09:10:16 |
| effendy | But yeah, I remember seeing ip route get when you were describing a debugging process a while ago and that draw my attention. And then immediately fell into oblivion :D | 09:11:16 |
| iam_tj | I've operated IPv6 only for several years and its been fine; in fact I find it easier to grok compared to IPv4 since ICMPv6 encompasses protocols like ARP that are separate concerns, and uses well-defined multicast groups for Router advertisements and so forth | 09:11:55 |
| effendy | by grok you mean.. basically debugging, understanding what's going on> | 09:12:20 |
