That does seem excessive. Change it so that it only sends an update to dyndns when it actually changes.
Having a new ip every 30 hours also seems pretty aggressive. I guess the DNS change might be slow to populate servers in that time if it is a “weird” top level domain.
Dyndns really shouldn’t affect your connection, as long as you have a local client that updates your record automatically.
I use jellyfin together with caddy and it was pretty seamless to setup. I configured the caddyfile to redirect my incoming domain to my local ip and the rest worked automatically. It sets up a legitimate certificate for the domain using lets encrypt and automatically renews it.
When you have an encrypted connection, the isp can’t see what is being sent between you and the webserver. They can however see your dns-requests unless you have dns over encryption enabled.
The only security measure beyond keeping things up to date that i would recommend is to have a geo-blocker enabled for incoming traffic to your network.
Well. The segmentation is to avoid security holes from Rogue third party devices. If you can access my pc vlan that only exists on my wired pcconnection, then you have indeed broken in to my domain. Letting the things that doesn’t give a shit about security have their own network is just sanity/sanitary.
I mean. Someone will have to maintain the same kind of infrastructure that visa and mastercard does. It would require a monumental amount of investment. Not to mention that it can, under no circumstances, go down during peak use.
I think the packets take one way in, and get routed a different way out.
It looks incredibly convoluted. My best guess is that traffic hits 172.168.1.254 and gets routed out on the internet and doesn’t pass the dmz.
Then i assume there is something wrong in the routes from your lan when returning traffic that got initiated through the internet opnsense. If you can see traffic hit the LAN network, all should be well on the way in.
Perhaps some sessions on the way time out due to low TTL. I’ve experienced drops of traffic when there are too many hops.
Its possible, depending on how you’ve setup your NAT, that the traffic cant return due to coming from a public ip.
Why do you have public ip-span configured as LAN?
It has to do with link priority on the server. You’d imagine that a server that receives a packet that has a return address on the same subnet as it self logically would use that interface instead.
A similar thing happens in switches. For example if you have two vlans on a switch and both vlans have an ip assigned, connect a computer to one of the vlans. You will only be able to reach the switch on the non-routed connection. Even if you also are allowed to reach the second vlan through a router/Firewall.
My guess is that the server receives the packet from the client with src .11.101 dst .10.102 and tries to respond over the interface that has .11.102 assigned. The client expects a response from src .10.102 and drops the packet. But I would turn on a packet sniffer in the gateway to see if the returning traffic even passes the Firewall in scenario 1.
Reset the AP to make sure it uses dhcp for its own ip and update firmware from unifi network after adopting the AP again.
Test it by swapping places of the access points to find out if the issue is related to the access points or something else.
Do you get enough oxygen in that large intestine you live in?
Take the win and move on.