Make sure you test this from outside your network and not simply by using the public IP, but from inside your LAN. Odds are your ISP modem doesn't support NAT loopback (also known as NAT hairpin).
Selfhosted
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:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
I tested with my Mobile with LTE and got the same results
Why do you have public ip-span configured as LAN?
Ah sry, bad choise but i masked my real LAN IPs
Its possible, depending on how you've setup your NAT, that the traffic cant return due to coming from a public ip.
There is one DNAT rule at the public OPNsense routing the HTTP/s traffic to my proxy. Inside my DMZ an LAN is no NAT, only routing. Back out again there is a Masq/SNAT rule for my local IPs
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.
Hm, could be a little bit much but Public IP -> WG0 -> Proxy -> Router -> Server and back should not be ok?
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.
Should the nginx Proxy receive that package? If i trace between the LAN Host and GW, there are no Public IP's
I think the packets take one way in, and get routed a different way out.
Check DNS, MTU and do a full wireshark capture from the Client using both curl and the browser.
green boxes are IP, red are FQDN
Curl capture (made first so DNS is captured aswell)
Firefox capture
You have a loopback. Says it right there.
From your diagram it looks like you're have two reverse proxies chained together...why?
Never got the time to learn to read Captures :'(
At a time I tried to use two proxies but I changed it back to one. The host I try to reach is a Docker Host with Immich running. So the only real proxy should be "192.168.1.1".
If it's 192.168.1.1, then your DNS has the wrong address somewhere. It's looking for 35.242
What? That's totally confusing. Took my Laptop (192.168.35.242), tethered to my Mobile (192.168.35.116) and wiresharked. 192.168.35.0/24 should never ever be a part of my Network.
Read your own screenshot
If you want to simplify things, do this:
- Remove all the proxy mess in between the service and network
- Make sure it works properly, and you can address it by name
- Add proxy back and point to DNS to it
- Test again
Then just keep adding things back and find where it's breaking. I'm positive you have a hostname mismatch, or a messed up DNS record if you're using multiple proxies. Curl output would be helpful. Also check dig (hostname)
to see what your DNS is responding with.
I think I let it rest for a day, I'm confused