Hi guys,

So I have a site that has a RB3011 routing their network. Nothing too complex, a few subnets for different parts of their network and an EOIP tunnel for one segment that links them to a remote office in another part of the city. Everything works as expected. The client decided to setup a streaming radio station as part of their community outreach work and i've ended up with a webserver that hosts the stations radio software and webpage via IIS and an IceCast streaming server on another host that does a pile of audio processing and serves client stream connections out. Webserver 192.168.80.94 and Streaming server 192.168.80.55 and everything works fine when connecting through NAT from the WAN side however, although clients on the 192.168.80.0/24 subnet can get to the webserver they can't get the audio stream from the streaming server which runs on 192.168.80.55:8001. If client browsers are explicitly pointed at ip http://192.168.80.55:8001/stream then the connection works.

To explain a little further, client browsers get to the webserver and are then directed via an <audio controls> tag in the station webpage to the e.g. http://domainname.com:8001/stream which is where it seems to break down. As said the NAT works from public side using the domain name just not the same subnet the servers are sitting on.

Hope this makes sense, I know i'm probably missing something pretty basic here and guess that it's being able to get the NAT to detect the port address.

Nat rules in place are;

dst-nat chain=dstnat comment="StreamingPC-Icecast Incoming Clients" dst-port=8001 protocol=tcp to-addresses=192.168.80.55 to-ports=8001
dst-nat chain=dstnat comment="Redirect LAN Http to IIS" dst-port=80 log=yes log-prefix="Radio HTTP" protocol=tcp to-addresses=192.168.80.94

Any help appreciated.

You need hair-pin NAT when clients, residing in same IP subnet as server, want to use public IP address to connect to.

Either need split-dns for your local clients (=run a local DNS service to resolve domainname.com to a 192.x address instead of the public one) or hairpin nat. yep

An alternative to hair-pin nat and split-dns is to put your servers on a different ip scope from the clients.

Yeah was the hairpin NAT that solved it. I think the solution was much faster to implement than my post was to write lol. Much appreciated

Would a hairpin NAT be required for other subnets managed on the same router?

Would a hairpin NAT be required for other subnets managed on the same router?

No. hair-pin NAT is requirement because server (seeing clients on the same subnet) doesn't know it should send return traffic over router (which is necessary to un-do the dst-nat) ... which makes client see return traffic as illegitimate (coming from unsolicited source). If server and client are in different IP subnets (doesn't matter if they are "LAN" or "WAN" or "bananas"), then both naturally use router as intermediate point which gives router opportunity to do its NAT job in both directions.