=== BenderRodriguez is now known as RobertMuellerDid === RobertMuellerDid is now known as BenderRodriguez === cpaelzer__ is now known as cpaelzer [15:05] Greetings all [15:05] I am in need of some help.. think my firewall, is... kinda? busted. It appears all allow rules in ufw works perfectly fine.. though, the deny/reject doesn't work at all. [15:06] I used a simple rule to deny my mobile IP to connect to the server, yet I can still load sites just fine. [15:07] we'd need to see your rules you're trying to set up [15:07] also UFW is specifically based on first-match so if your ALLOW rules are before your DROP/REJECT rules it will still allow [15:08] Anywhere DENY 143.179.70.207 - is above the allow rules [15:09] and you're *sure* your phone is using that IP actively? (send your phone to https://ifconfig.co to find out) [15:09] if it's NOT when it goes out to the 'net then that's why your rule doesn't work [15:10] According to that site, my mobile is using 143.179.70.207 [15:10] Which matches with the deny rule. [15:11] https://i.imgur.com/ZCQglP5.png [15:14] Even when I reload ufw, doesn't make much difference. [15:16] `ufw status numbered` please - i think you actually do have a rule ordering issue [15:16] (AND include the headers please) [15:16] (Because reading that output is pain) [15:16] just want to verify the numerical ordering is right [15:17] because I just spun a container up with ufw rules, and did an allow rule for SSH but also a REJECT rule for my IP and it puts the SSH Allow above [15:18] (which is important to note because it will match the 22 ALLOW rule first) [15:19] also make sure your phone isn't using IPv6 if v6 is on your infra [15:19] https://paste.ubuntu.com/p/DhHby6f5F4/ [15:20] Not sure why there are 2x 22'c, I'll erase that later on. But, I do believe the order is correct. [15:21] probably because at one point you specified just port 22 which is any protocol [15:21] All reject/denies are above the allowed rules.. so.. I'm, honestly confused. [15:21] so am I let me do some poking [15:22] what's your box's version? 18.04? [15:22] just to make sure i'm testing the right version :p [15:23] Skyrider: Could you pastebin the output of `sudo iptables-save`? [15:23] that as well [15:24] because ufw might be doing a weirdness behind the scenes [15:25] Skyrider: how're you testing the DENY rule? [15:25] out of curiousity [15:25] because `ping` isn't denied by ufw by default [15:25] so you will always get false info from `ping` [15:25] (just confirmed this in an 18.04 box) [15:26] ya, 18.04 and lemme grab the iptables rules. As testing, using mobile device to check my domains. Should be rejected. [15:27] so, accessing it via HTTP and such then [15:28] yup [15:28] ahhhhh okay i replicated your issue [15:28] I *think* the ALLOW rules get placed in a higher priority in iptables [15:28] which is stupid [15:29] https://paste.ubuntu.com/p/s8tMkSPzpx/ [15:29] somehow [15:33] I guess it is the ufw-user-input chain [15:33] Line 99 [15:34] not local? [15:34] Which happens before line 60 (reject), due to line 57 calling the ufw-user-input chain. [15:37] lordievader: i think there may be other bugs... [15:37] perhaps this is because i'm running in a container BUT [15:37] with a REJECT on my IP and an ALLOW on 80 with apache2 installed it still permits me in [15:38] Interesting fact I just discovered. [15:38] The deny/rejection on IP didn't allow my mobile to connect to SSH. [15:38] but did for HTTP? [15:38] Indeed [15:38] i assume *caching* was eliminated as a factor [15:38] because browsers are evil [15:38] (my tests are with curl :) [15:39] (which seem to suggest the HTTP Allow rule takes precedence) [15:39] Once I erased my cells IP rule, I was able to connect again. [15:40] I assumed all reject/deny were systemwide, even for http(s). [15:41] they should be [15:41] this seems like a bug [15:41] but i need to verify somehow [15:41] (ufw isn't doing logging right even at full levels) [15:45] okay i think something's actually odd on your env [15:45] because I realized I fatfingered a rule on my side [15:45] and it's now working [15:45] https://paste.ubuntu.com/p/H3p6F5PnH6/ [15:45] and a curl rejects to it [15:45] (curl doesn't have a cache) [15:46] Skyrider: they should be [15:46] what you aren't doing is verifying if your browser is caching or not [15:46] If you want a detailed answer why something went through or not look into the trace functionality of netfilter. [15:46] nuke your browser cache [15:46] and try again [15:46] because browsers are NOTORIOUS with caching if you've gone to the page at least once [15:46] Skyrider: readd your REJECT rule in the right spot and then erase your browser cache and try again on your phone [15:46] chances are it'll reject [15:46] and your browser was simply caching content [15:47] (which is usually the case for browsers) [15:48] I shall try.. however, would like to add that last week I mentioned that a deny/reject rule I added with ip range kept scanning my sites. [15:48] Was forced to block the IP range through nginx instead. [15:48] hmmm [15:48] just as an FYI [15:49] this is why I don't use ufw [15:49] it has some... nuances... [15:49] I just control everything via iptables directly :P [15:49] ufw is nice, but it can be weird and glitchy [15:49] Ya.. I find iptables a bit... complicated. [15:49] most users do unfortunately, hence why they use ufw. [15:49] the problem I find is, ufw does a lot of other 'stuff' with its rules that can be glitchy [15:49] and ufw logging is poor :P [15:49] if there are weird glitchy issues in ufw, please file bugs [15:50] jdstrand: you mean like `ufw logging full` not actually logging anything anywhere? :P [15:50] (at least, in LXD containers) [15:50] I re-added the the IP, though no success. Gotta admit, I didn't clean the cache. But I went to forum pages that I never went to before on mobile, even private area's. Wasn't blocked a single time. [15:50] teward: that isn't ufw's fault. unprivileged containers don't have access to kmsg and that is where the kernel logs [15:50] jdstrand: this is a privileged container ;) [15:50] and it still can't access [15:51] again, that is the kernel, not ufw [15:51] Even created a new thread on the forums with my mobile :p, you can't cache that. [15:51] hmm [15:51] let me spin up a VM [15:51] remove the kernel headaches from the equation for testing [15:51] why not use iptables, then you can save it to a file and at any time run it to instantly set it the way you want? [15:51] and get some niiice auditing to try and replicate this [15:51] weedmic: because they find it 'complicated' :P [15:51] most users do [15:52] logging is also complicated by journald [15:52] so depending on the release in the container, there may be some stuff going on with journald [15:52] well, it's just a language (of sorts) - it's only got like 5 things in it - but I could see that - I find it easier than suse's gui for firewall [15:52] If there's something that is similar to ufw (in simplicity), but adds rules as iptables would.. I don't mind. [15:53] Never had any issues with ufw until a few weeks ago. [15:53] * jdstrand also notes that ufw uses iptables-restore syntax under the hood [15:53] (man ufw-framework) [15:53] Skyrider: please file bugs if there are issues [15:53] wellllllllllll [15:54] I was writing a python frontend to `iptables` that does much like what `ufw` does... [15:54] but I got busy/bored/distracted [15:54] I could report a bug, but need to be sure that this isn't my fault XD [15:54] jdstrand: well rsyslogd dumps it to /var/log/ufw.log and that oddly enough works [15:54] Skyrider: let me set up a test env with logging, etc. give me a minute then i'll coopt you to do some testing [15:55] *goes to the Cloud* [15:56] ^_^ [15:56] teward: its gonna depend on what is available in the container, how the container is configured, how logging overall is configured, the kernel, etc. ufw does ship an rsyslog snippet, yes [15:56] right [15:56] but this is why i'm going to the Cloud and VMs for a full env [15:56] thank you cloud VPS deployment xD [15:56] but the imklog [15:57] module from rsyslog might not be able to read the kernel logs [15:57] so, it can't put it in ufw.log [15:57] but again, lots of variables [15:58] the container host should still see it though [15:59] yep which is why i'm spinning a cloud instance up to test with :p [15:59] should help [16:01] Hopefully with results matching my issue... makes things easier. [16:03] just takes a while to launch xD [16:03] Cloud aint that fast ey [16:03] not as fast as I'd like but I don't use predeployed images :P [16:03] I boot the ISOs and deploy my own settings :P [16:19] Skyrider: check your PMs I sent you a location to go to [16:42] jdstrand: i think we've narrowed it down [16:42] but it's not a ufw bug [16:42] it's how their android phone behaves with Internet [16:42] (everything goes via Google Proxies for some reason) [16:42] which makes sense if it's using stock Google Chrome on the Android :P [16:42] Skyrider: ^ [16:57] as to why the /16 wasn't blocking I am unsure, because by all intents and purposes it shouold have [16:57] can't rule out proxies at play though [17:15] teward: oh, interersting. yeah, clouds, their kernels and their logging infra can certainly affect things. good luck tracking it down! [17:15] KVM VPS on OpenStack though... [17:15] Thats full virtualization ;) [17:18] Need some Android Emulator running on top of an instance inside that OpenStack though :D [17:18] Guess my headless server is busted then [17:30] the "google proxies" = AMP stuff ? [17:39] JanC: Not sure, but Skyrider had Google Data Saver on in their Chrome browser [17:39] that was probably a factor [17:52] jdstrand: but Skyrider DOES have something wonky up with their environment, even with the rules in the proper places it still allows connections. Can't rule out caching, but something's up with their system [17:52] not a ufw bug per se, maybe something specific to their config [18:03] Skyrider: note that connection tracking may be an issue. usually this indicates either other firewall software is installed and is competing with ufw or something is not configured correctly in the kernel. you can run 'sudo /usr/share/ufw/check-requirements' for the latter [18:22] jdstrand: Command requests to create rules. [18:22] teward: Does ufw override iptables rules by any chance? [18:22] ufw *is* iptables rules [18:22] it will overwrite any other loaded netfilter rules [18:23] (which is iptables) [18:23] That, I know.. But I noticed ufw lines being used in iptables rule list. [18:23] that's normal [18:23] Maybe just for naming purposes? [18:23] because ufw *uses* netfilter/iptables under the hood [18:23] it's UFW specifics for how it does its tables/namings/etc [18:23] but it's still ultimately iptables, just a user-friendly frontend to manage the iptables rules [18:23] Maybe I should try to create an iptables rule denying my own ip address, directly from iptables. [18:23] Rather than ufw.. see if that works. [18:23] disable ufw first, then apply a ruleset similarly. I can help you write a ruleset as such if you want [18:24] ufw will overwrite any iptables rules you add [18:24] (for the record I use iptables exclusively, but i have reasons xD) [18:24] I assume "iptables -A INPUT -s IP-ADDRESS -j DROP" would work fine. Not sure the order it would add it though. [18:24] Maybe I should just use iptables, and use aliasses to make it more simpler for me. [18:25] `iptables -I INPUT 1 -s IPADDRESS -j REJECT --reject-with icmp-host-unreachable` would be more instantaneously identifiable as a truly effective rule [18:25] of course with sudo :P [18:25] ^_^ [18:25] oki, ufw disabled. [18:26] What about the order? [18:26] Is there a command to set the order like ufw? sudo ufw insert x .. etc, etc, etc. [18:26] the rule I provided adds to the top of the list and there's a default ALLOW by default in `iptables` [18:26] `iptables -I` - `-I CHAIN INDEX` Insert rule into specified chain at specified index/position [18:27] in this case, INPUT is the chain (as expected) and INDEX is 1, meaning top of the chain] [18:28] Skyrider: i'd be happy to give you a crash course in `iptables` syntax at some point :P [18:29] if it turns out this deny/reject actually WORKS [18:29] ... ops? [18:29] ooops* [18:29] i think they killed themselves... if they did i'll have to help them fix it [18:29] * teward reminds himself that ufw can be evil [18:36] *shrugs* [18:36] Forgot, that it would block me from .. .well, everything [18:36] lol [18:36] Was forced to reboot and reset the rules. [18:37] Interesting fact though that blocking my IP in iptables disconnected me almost instantly from everything.. while if I do the same on ufw, it didn't. [18:37] So my guess is.... ufw.. is, busted on my end. [18:41] teward, Skyrider: actually, ufw will *not* overwrite rules you have unless you specify MANAGE_BUILTINS=yes in /etc/default/ufw, which is not the default [18:42] jdstrand: interesting. so it'll what, append rules? [18:42] Skyrider: that depends on where exactly you're adding the drop/reject rules - if they go before a rule using conntrack allowing existing connections, that will terminate all open connections, while after will only make them affect new connections [18:42] last i checked ufw overwrites whatever I put in `iptables` when ufw is disabled [18:42] teward: no, it works on its own chains that are all prepended with ufw-* [18:43] teward: this is how it plays well with libvirt, etc which adds their own rules. but something like iptables-persistent or other things that assume they own the firewall can interfere with ufw [18:43] The rule I was provided to add in iptables disconnected all my connections. [18:44] Let me try again, but only adding the web ports instead rather than a global deny. [18:44] still, the advice is sound to disable ufw and see if something simple is working [18:45] "iptables -A INPUT -p tcp --destination-port {PORT-NUMBER-HERE} -j DROP" ? [18:45] err, no.. lacking ip [18:45] Skyrider: `sudo iptables -I INPUT 1 -s IPADDRESS -p tcp --dport 80 -j REJECT --reject-with icmp-host-unreachable` [18:45] same for 443 (though you can replace the index with `2` [18:45] and that'll ONLY block traffic matching the source IP address heading to port 80 on TCP [18:45] Thanks :) lemme try [18:45] (standard HTTP) [18:46] my apologies for fubaring your access, but at least we know THAT worked xD) [18:46] Simple reboot fixed it XD.. why isn't iptables saved though? [18:46] With that, I mean.. saved on reboot ,etc. [18:46] teward: it depends on how your are disabling ufw. if you disable and do /lib/ufw/ufw-init flush-all or other low level things (or have MANAGE_BUILTINS=yes set), then yes, it will blow stuff away [18:47] because it's not stored in a file anywhere, ufw when it reenables loads data from stored rules/data and reloads it into netfilter [18:47] similar to how `iptables-persistent` does the same on boot (but assumes firewall ownership and blasts things apart) [18:47] oki, I dropped the connection on 80 and 443.. didn't work. [18:47] Skyrider: iptables itself doesn't do anything for saving on boot, if you want that you need to install something like the iptables-persistent package [18:47] Well, it got added.. just didn't block my access on my web stuff. [18:47] do note that just because ufw doesn't stomp on the rules doesn't mean that rule ordering isn't in play. iptables rules are order-dependent. if the ufw chains are first, then ufw will work, if after, they may not (ie, -A (append) vs -I (insert)) [18:48] Skyrider: did you use DROP or REJECT? [18:48] test REJECT [18:48] instead of DROP [18:48] this said, DROP should've worked too [18:48] Skyrider: is this a VPS? Is it containerized (LXD, OpenVZ) or full virtual (KVM)? [18:49] Skyrider: also, make sure you're actually blocking the right IP (remember the google proxy evil?) [18:49] Virtualization: kvm [18:49] Skyrider: how are you testing the connection? is the traffic going through the interface you expect to be firewalling? did you kill off any connection tracking (eg, sudo conntrack -D ...) [18:50] Not sure what conntrack is. [18:50] Skyrider: did you add the rules with -A (append) or -I (insert)? [18:50] jdstrand: would that apply even if the first rule were a global matchall? If they did `-I INPUT 1` like i suggested it'd have put it at first position in INPUT [18:50] Skyrider: it is also possible there are vps rules that are in front of your added rules [18:51] I see Skyrider used iptables -A INPUT... [18:52] ah that might break it [18:52] Copy/pasted, ya :P [18:52] Skyrider: did you use `iptables -A INPUT` or `iptables -I INPUT 1` like i suggested? [18:52] I copy/pasted your line [18:52] So.. with input 1. [18:53] Skyrider: with INPUT 1, it worked and blocked the connection? [18:53] -A INPUT -s xxxxxx/32 -p tcp -m tcp --dport 443 -j REJECT --reject-with icmp-host-unreachable - and another line with port 80 according to iptables -S [18:53] And no, it didn't block my web connection. [18:53] show us the `iptables-save` output (Pastebin it please) [18:54] sure [18:54] `iptables-save -c` ideally :) [18:54] ^ that [18:54] >_> [18:55] ... ooooooooooops i just broke my own email, stupid firewalls and NAT... *goes to fix* [18:55] https://paste.ubuntu.com/p/49hZ53dx4d/ [18:56] the only reason it'd be doing *that* is because your IP(s) accessing the site aren't what we think it is [18:56] Skyrider: how did you disable ufw? [18:56] which is what was happening earlier with our tests skyrider [18:56] sudo ufw disable [18:56] Status: inactive [18:56] Skyrider: and you rebooted? [18:56] Reboot kept ufw disabled. [18:57] jdstrand: shouldn't the first to input lines (24, 25) have caught regardless if the source IP matching was correct? [18:57] 0:0 suggests that it never triggered/matched on sourceIP [18:57] and since those rules are ABOVE the ufw rules, those should be matched regardless of UFW active/inactive [18:57] at least per my nf understanding [18:59] Skyrider: that isn't what a disabled ufw looks like after a reboot [18:59] Don't look at me XD [18:59] (if it is disabled, after a reboot, it should have no ufw chains) [19:00] Skyrider: what release of ubuntu is this? [19:00] 18.04 [19:00] I removed ufw and purged it. [19:00] ufw rules in iptables-save are still there. [19:00] At least, the ufw lines. [19:00] jdstrand: just ran ufw in the command line in a container [19:00] aaaaaaaaaand, the ufw rules are still there when disabled [19:00] even on reboot [19:00] Skyrider: this is a container? [19:00] except on reboot* [19:01] jdstrand: confirming on a VM currently as well [19:01] standby... [19:01] teward: ufw disable pre-reboot will leave chains in place, but empty them. on reboot, they won't be added [19:01] that part i confirm [19:02] Skyrider: you did `sudo ufw disable` and then restarted the server yes? [19:02] Skyrider: what is ENABLED set to in /etc/ufw/ufw.conf? [19:02] because jdstrand *is* right - it won't add those rules if `ufw` was disabled when you rebooted [19:02] Skyrider: did you install iptables-persistent or anything similar? [19:02] if you did, that may have saved the ufw rules for you [19:02] looks to me more like you just rebooted then did `sudo ufw disable` [19:02] tds: yes [19:02] tds: that is often a problem [19:02] `grep ufw /etc/iptables/rules.v4` would tell you :) [19:03] (and won't exist if it's not installed or manually created) [19:03] * jdstrand is reminded he needs to add iptables-persistent detection to /usr/share/ufw/check-requirements [19:03] jdstrand: what's the underlying language for it? [19:03] i might be bored enough to try :p [19:05] python3 for the ufw command, shell for early boot setup and iptables-restore syntax for rules [19:05] Ya, iptables-persistent is installed. [19:05] Skyrider: iptables-persistent and ufw do not work well together. choose one or the other [19:05] I only added it a few hours ago, when I was trying to fix all of this. [19:06] remove iptables-persistent and reboot [19:06] then add the `iptables` rule I stated [19:06] this said [19:06] Do I have to reboot? :P [19:06] jdstrand: my previous question stands. [19:06] jdstrand: shouldn't the first to input lines (24, 25) have caught regardless if the source IP matching was correct? [19:06] because of the ordering in INPUT [19:06] Skyrider: that's fine, but we can only debug what is happening right now [19:07] One moment, will disable/enable some services and reboot. [19:07] teward: yes, they should have [19:07] jdstrand: one of the issues we ran into earlier with Skyrider was their device(s) were being routed via Google's Proxies [19:07] as a result of datasaver, etc. [19:07] when we blocekd the IP of their actual address that was in the access logs from the webserver they couldn't get to it [19:07] This time however, using my own browser on my main desktop system. [19:08] teward: so the incoming ip is NAT'd or something? that is going to make a source ip infeasible [19:08] Wait a sec... [19:08] jdstrand: there's a few different factors [19:08] once I removed persistent, everything started to work [19:08] nvm.. [19:08] when their main computer connected and I blacklisted that in a live system it blocked them [19:08] Just slow connection XD [19:08] but the tricky part here is that i can't verify what's going on on their main desktop [19:09] jdstrand: i also can't rule out Proxy settings at play by ISP or some other VPN or proxy system at play [19:09] in which case if they ARE indeed nat'd we'd have some... headaches with that and you're rightw e'd have to ignore source IP as a valid identifier (because NAT breaks it) [19:09] case in point my IP currently, it shows as my home's IP instead of ym work's IP because I'm VPN'd through home, but HTTP Proxies would behave similarly for HTTP/HTTPS connections in some cases [19:10] Skyrider: confirm you're still rejected on the test IP I provided earlier as well [19:10] sudo tcpdump -i -s 0 -n -vv port 80 [19:10] Not atm (not on my desktop)_ [19:10] that will also be helpful on the server ^ [19:11] Skyrider: just for your own debugging. you'll then see the IPs involved [19:11] jdstrand: i'd agree with what jdstrand says :P [19:11] **rebooting** [19:11] then attempt connecting yourself and see the IP(s) [19:11] blehrewrherw9re [19:11] *yawns* [19:14] jdstrand: ewwww check-requirements is bash >.< [19:14] /bin/sh * [19:14] oh your question was about that. yes, shell [19:14] one of my more hated languages [19:14] behind Ruby and Perl [19:15] Okay, so.. [19:15] Reboot done. [19:15] (Ruby, Perl, pure Dash/sh, C, C++...) [19:15] iptables only shows 3 lines now. [19:15] input, forward and output. [19:15] heh, well, it works ok for that particular debugging purpose :) [19:15] Skyrider: ok, so you now have a completely clean slate [19:16] jdstrand: oh fun fact: you might need to remove the python 2.* checks in this thing for focal if we're sure we're blasting Py2 away [19:16] :P [19:17] I re-added the 80/443 rules. [19:17] * jdstrand notes that the ufw rules that were there before were all 'pass through' but it complicated the output. please, trying to reason around ufw and iptables-persistent at the same time is never good [19:19] teward: yes, ufw itself is all py3, etc, etc. I do need to drop the py2 packaging which I'll do before ff. note that check-requirements looks for any python, it just happened to find py2 on the system [19:19] Skyrider: and the connection is still not blocked? [19:20] Not yet.. just reminded server is using cloudflare.. lemme disable that. [19:21] sudo tcpdump -i -s 0 -n -vv port 443 - Can I ignore the the machines IP? [19:21] Getting spammed with it. [19:21] A lot of them with cksum 0x8d69 (incorrect -> 0x0873), seq 1:194, ack 1, win 229, length 193 [19:22] Specifically the "incorrect" part. [19:25] jdstrand: https://paste.ubuntu.com/p/k5NPprmBv3/ in case you're curious *might* help, since those're the scripts iptables-persistent currently installs - if either of them exists then the package is installed :P [19:25] it's a diff btw [19:26] > server uses cloudflare [19:26] well that explains a lot [19:26] CloudFlare is equivalent to Proxies and VPN, it futzes the endpoint Source IPs [19:26] Side question.. if I allow a port to be used on a specific IP with iptables, does it block the rest? [19:26] so you can't use `iptables` or `ufw` to filter on SourceIP if you're behind CloudFlare [19:26] Which explains the problems you're having [19:27] Skyrider: if you put the default policy to DROP or add a REJECT rule at the end of the rules as a default, then it will [19:27] Okay, that makes it different over UFW. [19:27] no [19:27] because iptables defaults is ALLOW [19:27] teward: re check-requirement, thanks :) [19:27] ufw's 'default' policy is deny incoming ;) [19:27] Adding an accept port / ip rule through ufw, auto denies it for other ip's. [19:27] jdstrand: yep, it's likely to need minor refinement. [19:27] Skyrider: because the default policy is DROP [19:27] in Ufw [19:28] Which I find, better.. in my opinion [19:28] iptables doesn't have that unless you specify it as that, but that's a different discussion [19:28] because you can *set* iptables to default-Deny [19:28] which can cause issues if you're not careful [19:28] Skyrider: you can add 'and host ' [19:29] Ah, that makes it better :D [19:29] Also... still doesn't block my IP >_> [19:29] ****web wise. [19:29] Skyrider: if you're using Cloudflare then it won't [19:29] to reiterate WHY: [19:29] CloudFlare is equivalent to Proxies and VPN, it futzes the endpoint Source IPs [19:29] because the traffic goes through CloudFlare's nginx proxy to try and mitigate DDoS and provide minor CDN functionality [19:29] Oh, I know. :) [19:30] so... :P [19:30] Set it to DNS only [19:30] and you're sure your computer sees the updated DNS? [19:30] Chrome / Firefox appears to be blocked now.. Internet explorer.. not so much. [19:30] ... ewww IExplorer [19:30] *shivers* [19:30] XD [19:30] Using it just for testing. [19:30] Internet Explorer is evil and relies on Windows' DNS cache [19:30] Chrome/FFox both do their own queries lol [19:30] Okay, soo... works now.. so all this time, cloudflare was the issue. [19:31] Really wish iptables would be smarter to check "behind" the proxy... [19:32] it can't. the info is gone from the packet [19:33] Fun times.. can't even use cloudflare XD [19:33] the T in NAT is Transalation. the host doing the translating rewrites the address before sending the packet on its way [19:34]