Selfhosted

39435 readers

7 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

[email protected]

rDNS, how? (feddit.dk)

submitted 1 year ago by [email protected] to c/[email protected]

47 comments fedilink hide all child comments

I'm on at least 2 blocklists at this point for the crime of not having reverse DNS set up. I don't know how rDNS works. No amount of reading Wikipedia is helping me understand what I have to do.

I have a domain at a registrar which gives me bog standard DNS.
I have Apache running on my network.
I have PiHole running on my network.

My understanding is that rDNS is not set up at my registrar, but somewhere in my network. What do I do?

Thank you for your time.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 year ago (1 children)

We're making progress!

Looks like connection are being made, so it isn't routing after all!

Looking at the first recording, based on the different packet length, I'd guess it is doing SSL handshake properly; whereas the second one seems to be all 0 length and so something is not working out. At least on a cursory glance, your settings seems to be pretty permissive, so unless your friend's using a super old system, it shouldn't be an issue. Do you know what OS your friend is using, and if it has up-to-date root certificates? Are they on a system with openssl cli available? Judging by the unifi network, probably? Try openssl s_client -connect drkt.eu:443 -prexit (and ctrl + c to quit after it stops) and see if you can see any oddities with the SSL handshake process.

[–] [email protected] 1 points 1 year ago (2 children)

He's running Windows 10, unfortunately- but wouldn't SSL errors show up in Apache logs? His IP appears 0 times in all apache error and access logs dating back 8 months (the beginning of recorded logs).

Here's another example of a working request to https://drkt.eu, and his non-working request respectively.

21:06:10.038213 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [S], seq 383581601, win 65535, options [mss 1460,nop,nop,sackOK,nop,wscale 11], length 0
21:06:10.038225 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [S.], seq 1228608203, ack 383581602, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:06:10.062959 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [.], ack 1228608204, win 32, length 0
21:06:10.068861 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [P.], seq 383581602:383582119, ack 1228608204, win 32, length 517
21:06:10.068878 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [.], ack 383582119, win 501, length 0
21:06:10.069190 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228608204:1228611124, ack 383582119, win 501, length 2920
21:06:10.069272 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228611124:1228612300, ack 383582119, win 501, length 1176
21:06:10.069905 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228612300:1228613496, ack 383582119, win 501, length 1196
21:06:10.093915 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [.], ack 1228611124, win 35, length 0
21:06:10.094156 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [.], ack 1228612300, win 37, length 0
21:06:10.095161 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [.], ack 1228613496, win 38, length 0
21:06:10.096357 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [P.], seq 383582119:383582245, ack 1228613496, win 38, length 126
21:06:10.096588 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228613496:1228613547, ack 383582245, win 501, length 51
21:06:10.121482 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [P.], seq 383582245:383582345, ack 1228613547, win 38, length 100
21:06:10.121749 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228613547:1228614978, ack 383582345, win 501, length 1431
21:06:10.146792 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [P.], seq 383582345:383582376, ack 1228614978, win 40, length 31
21:06:10.146907 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [P.], seq 1228614978:1228615009, ack 383582376, win 501, length 31
21:06:10.146931 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [F.], seq 1228615009, ack 383582376, win 501, length 0
21:06:10.147568 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [F.], seq 383582376, ack 1228614978, win 40, length 0
21:06:10.147573 IP 192.168.78.164.443 > 185.21.217.51.34034: Flags [.], ack 383582377, win 501, length 0
21:06:10.171696 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [R], seq 383582376, win 0, length 0
21:06:10.171722 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [R], seq 383582376, win 0, length 0
21:06:10.172482 IP 185.21.217.51.34034 > 192.168.78.164.443: Flags [R], seq 383582377, win 0, length 0

21:49:09.999249 IP 5.186.33.87.51592 > 192.168.78.164.443: Flags [S], seq 2577736519, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:09.999412 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:10.254112 IP 5.186.33.87.51594 > 192.168.78.164.443: Flags [S], seq 2174498243, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:10.254425 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:11.000511 IP 5.186.33.87.51592 > 192.168.78.164.443: Flags [S], seq 2577736519, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:11.000624 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:11.262009 IP 5.186.33.87.51594 > 192.168.78.164.443: Flags [S], seq 2174498243, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:11.262135 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:12.010686 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:12.266608 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:13.014793 IP 5.186.33.87.51592 > 192.168.78.164.443: Flags [S], seq 2577736519, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:13.014920 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:13.265504 IP 5.186.33.87.51594 > 192.168.78.164.443: Flags [S], seq 2174498243, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:13.265645 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:15.046677 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:15.274640 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:17.022305 IP 5.186.33.87.51592 > 192.168.78.164.443: Flags [S], seq 2577736519, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:17.022424 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:17.277539 IP 5.186.33.87.51594 > 192.168.78.164.443: Flags [S], seq 2174498243, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:49:17.277663 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:21.226692 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:21.482700 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:29.414663 IP 192.168.78.164.443 > 5.186.33.87.51592: Flags [S.], seq 3425825559, ack 2577736520, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
21:49:29.670628 IP 192.168.78.164.443 > 5.186.33.87.51594: Flags [S.], seq 1029590757, ack 2174498244, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

[–] [email protected] 2 points 1 year ago

See this page here that explains the Flags: https://opensource.com/article/18/10/introduction-tcpdump

Typically, in a TCP connection, you'd SYN, SYN+ACK, ACK, then transfer actual data over. In the successful sequence, you see this happening as expected.

In the unsuccessful sequence, it seems to be stuck in SYN, SYN+ACK, but there is no ACK that follows (Flags [.]).

Where is the second one captured? On the user's system, or on your system? Something in between is determining the packet isn't intended for the destination and dropping it. It may be a firewall, it may be something else.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Thinking about this some more, could it be asymmetric routing?

If so, does this help?

[–] [email protected] 1 points 1 year ago (1 children)

Replying to both of your comments:

These are captured on both my gateway and the Apache LXC container. The captured packets are identical as far as tcpdump is aware on both of these systems. As far as I can tell, unless there are shenanigans at the firewall WAN NIC, this is how the packets arrive to my firewall.

And I don't think this is asymmetrical routing if I understand it correctly, as I only have one firewall. My interfaces are configured correctly according to that netgate article.

[–] [email protected] 1 points 1 year ago (1 children)

Sorry I got slammed by work last couple of days and didn’t check back.

I wonder if it could be asymmetrical routing by your ISP? You mentioned your setup was okay before but it doesn’t work since you changed location.

I think your friend with the UniFi network has a static IP. Can you try traceroute to their IP and see if the route is similar to the one taken by their ISP? I’m not sure if this is how you’d test for asymmetrical routing but if nothing else the symptoms sound similar.

[–] [email protected] 1 points 1 year ago

This project has hit a bit of a dead end but I appreciate your input a lot. I may get an opportunity to run tcpdump from within their network soon- which is what I was waiting for and why I didn't reply yet, but things aren't really happening.

My ISP gave me an rDNS and I was off several of those dumb blocklists within the hour. One person who could not previously connect to me now can, so that was the issue for that user at least. They were using Mullvad VPN, so Mullvad blocks based on uceprotect or a similar blocklist.