Technical Discussion
  >> Home Networking, Internet Connection Sharing, etc.


Register (or login) on our website and you will not see this ad.


  Print Thread
Standard User 2E0VEB
(newbie) Thu 19-Dec-24 00:37:29
Print Post

Hairpin nat?


[link to this post]
 
Posted this over at my ISP (plusnet) community forum but am not expecting an answer, so thought it would fit here in case any wandering network experts are passing.

I know someone will probably pop up with the "ooh don't have a /16 network, think of the broadcast traffic" line but really, its ok. I'm just trying to figure out a way around this.


Had a reason to change from a /24 to /16 on my local network.

I run a number of services locally which i use nginx to reverse proxy.

This worked absolutely fine until the change.

Locally i can still access these services through the local ip address/path.

Using another network, i can access these services with sub.domain.tld.

However, internally, i cannot. I can ping them, they all resolve to my static ip no problem.

Spent many hours trying to tweak settings - everything else works absolutely no problem, but this is a niggle for me and doesn't help with testing to ensure these services work from outside my network.


I had wondered if this was something to do with nginx not liking to route traffic across subnets but i'm reading more about hairpin nat and wonder if anyone knows if this is relevant or has any other thoughts?

I run pihole so i *could* setup some local DNS records BUT not all these services are accessible from a simple IP, they require a path. For example http*://192.168.3.1/servicename.

*These services are all exposed to the web as https with valid certificates - which i can still generate.

I've tested using a vpn and can access these no problem.


Ran out of ideas so if anyone has any thoughts, they'd be appreciated!
Standard User DFScale
(committed) Thu 19-Dec-24 08:53:32
Print Post

Re: Hairpin nat?


[re: 2E0VEB] [link to this post]
 
I know nothing whatsoever about nginx. So I'm commenting on what I know.

1] Do you need a /16? /20 would be the next move or even just a /23

2] Why is a /24 not good enough? Is it number of machines? Or is it that you want to route across your network?

I once thought I needed to route across my network because I want to keep some machines away from the public internet and to keep my wireless guest network away from those machines and ended up with a complex setup that always had another gotcha for every gotcha I fixed.

I got it all working as I want when finally I realised the distinction between bridging [mac addressing] and routing [tcpip routing] and let everything except the wireless guest network operate with bridging. The machines I don't want to have public internet access have static IP addresses on an unrouted subnet and the machines with access to the public internet which need to access those machines have an additional IP address on the unrouted subnet.

Of course, without knowing a lot of detail about your setup and exactly why you have gone to a /16, it is difficult to comment further. But on problems like this, for me it always helps no end to focus on requirements - what I want to do eg isolate X from Y - rather than on making solutions work, when those solutions might not actually meet the requirement.

edited to add: Your router may be a problem here. Some consumer grade routers might be predicated on the assumption that the LAN side is a /24 and it may be that this assumption is not consistently applied, so that it might all appear to work apart from say hairpin NAT.

Edited by DFScale (Thu 19-Dec-24 08:59:39)

Standard User TwiggyLobster
(newbie) Thu 19-Dec-24 11:22:55
Print Post

Re: Hairpin nat?


[re: 2E0VEB] [link to this post]
 
Check what subnet mask you have set - if it's a /24 then you are going from 255 to 0 in that third octet... it might be that it's just not routing wink

Start with the basics - can you access (with a cert error unless you have alt names) via an IP?


I'm guessing that you have an nginx proxy with an interface to the internet and your static public IP and you are forwarding internally to other sites/hosts/ports?


Register (or login) on our website and you will not see this ad.

Standard User danielhyde
(committed) Fri 20-Dec-24 16:35:54
Print Post

Re: Hairpin nat?


[re: 2E0VEB] [link to this post]
 
Some routers don't support this, what router do you have?

Thanks
Dan
Standard User Pheasant
(eat-sleep-adslguide) Fri 20-Dec-24 16:47:01
Print Post

Re: Hairpin nat?


[re: danielhyde] [link to this post]
 
Presumably OP has the same router as when it was working previously with a /24...
Standard User jabuzzard
(experienced) Mon 23-Dec-24 22:45:16
Print Post

Re: Hairpin nat?


[re: 2E0VEB] [link to this post]
 
You can't take the 192.168.0.0/16 private IP address assignment, use it like a class B network, and expect it to work. It is 256 separate class C networks. You will need to take a class B address assignment out of either the 172.16.0.0/12 or 10.0.0.0/8 as I understand it. Some stuff will likely work giving the appearance of it working but you will get wacky brokenness all over the place.
Standard User DFScale
(committed) Mon 23-Dec-24 23:26:24
Print Post

Re: Hairpin nat?


[re: jabuzzard] [link to this post]
 
In reply to a post by jabuzzard:
You can't take the 192.168.0.0/16 private IP address assignment, use it like a class B network, and expect it to work. It is 256 separate class C networks. ...


AIUI, no reason why not. Network classes have been deprecated for decades and no longer play any part in routing or anything. Subnet and mask are sufficient.
Standard User jabuzzard
(experienced) Wed 25-Dec-24 20:43:21
Print Post

Re: Hairpin nat?


[re: DFScale] [link to this post]
 
In reply to a post by DFScale:
AIUI, no reason why not. Network classes have been deprecated for decades and no longer play any part in routing or anything. Subnet and mask are sufficient.


You are right in theory; practice says otherwise, as not everyone has got the message, and there is a ton of kit and software out there that still assumes RFC 1918 is in force. I would wager this is the issue the original poster is running into.
  Print Thread

Jump to