Hairpin nat broken not working properly

Well..I don't see how the OpenWrt is even involved.

I was confused about the re-add if the OpenWrt was untouched, my apologies.

i dont understand whats the issue at all ,, all these posts are incomplete / no final solution just broken pieces of information.

so basically there is no solution for a case that was fully working? As it doesnt work apparently something is broken.

Its primitive port forwarding; works for other services but yes i cant access my hass from local network. as mentioned in above posts they are clearly saying that hairpin nat has to be enabled ...

Hairpin NAT

At this point of setting up we need to check one capability of your router: Hairpin NAT (otherwise known as NAT reflection or NAT loopback). What this means is the ability of your router to mirror a request from its inside (LAN) interface to its outside (WAN) address back to an internal IP address (in this case, your Home Assistant), thus reflecting or hairpinning the traffic. It's easy to check if this works: Just open a browser on your phone or PC while connected to your home network and opening http://my-home.duckdns.org:8123 - if it works, you have hairpin NAT working and can go on to the next section. Most current routers will support NAT hairpinning out of the box, there are however some routers (especially if you got your router from your ISP) that do not have this ability or have it disabled. If this is the case, you need to check if you can enable it on your router or, if you can't, you will need to set up Split Brain DNS.

I thought I said that you should check the device that was actually touched when the problem occurred - the ISP router. If you want to troubleshoot the OpenWrt needlessly, my apologies, I didn't understand you may be exhausting options with the device that was working.

My bad and apologies for interrupting, as I see you have a similar rule.

@lleachii what do u want to check ... its one ip forward rule....

ok, basically it doesnt work because openwrt is broken https://bugs.openwrt.org/index.php?do=details&task_id=1645

If you haven't provided that information from the new ISP router...but that's not related to OpenWrt. I would verify that not that you have this new ISP that you actually have public IP address.

Or...you can say it only works for the single IP you set (e.g. you setup a personal webserver on your desktop, and test from the desktop)...but sure, call it "broken".

As I noted:

This works exactly as people desire (I assume those calling it a bug need the developers to identify exactly what each person else wishes to redirect - besides the IP itself, without creating a security hole).

@lleachii sorry i dont understand any sentense you wrote.

And i will repeat it again

  1. i can access my local IP from internet without problem using dynamic dns alias (https://xxx.xy)
  2. using the same dynamic dns alias (https://xxx.xy) from local network DOESNT WORK.
  1. whatismyip.com
  2. verify this Public IP matches IP on new ISP router

Did you add the rule?

Where is 10.0.1.104 (Network and zone)?

omg ... what are u trying here is nonsense.

  1. as i can ACCESS my local ip from Internet it means that dns record correctly matches my isp router IP and isp router correctly port forwarding it to local IP

repeating again i cant just access it from within local computer.

I understand, please answer.

104 is exactly there as on the image provided. On the same lan as local pc trying to access it.

the rule you are pasting is Incorrect, whats the point of srp ip as subnet ...

Is it possible to do an inbound test for another machine?

This would be to see if the loopback works on the port in question.

what do u want to answer.

host xxx.yz from internet provides same ip as executing host xxx.yz from local host.

dont know what do u mean by inbout test for another machine ...

but i know that tcpdump exists instead of your proposals ... i was expecting that someone know what the error is and can propose solution, apparently xy threads discussing similar issue, bug opened and no conclussion / solution.

I understand.

I want to see if setting a rule TO WAN works. That would be the redirect needed.

Packet:

  • From lan to wan
  • By default, this is firewalled
  • This rule would allow the packet ad change it's DST to 10.0.1.104
config redirect                                          
        option target 'DNAT'                                         
        option src 'wan'                                           
        option proto 'tcp'                
        option src_dport '8123'                                        
        option dest_port '8123'                                      
        option src_ip '10.0.1.0/24'    
        option dest 'wan'          #<--------NOTE WAN                             
        option dest_ip '10.0.1.104'                              
        option name 'REDIRECT_HTTP_LAN'

I apologize - you didn't configure the example rule for your scenario. Please try this.

whats the point of such a rule/config...
src and dest both wan? that doesnt make a sense as dest_ip is inside LAN not wan.

Again:

I apologize if that hasn't been made clear before.

BTW, you need to add an allow rule :wink:

Reason:

:spiral_notepad: In your case - WAN.

what is allow rule/ or add where?

firewall.@redirect[21]=redirect
firewall.@redirect[21].dest_port='8123'
firewall.@redirect[21].src='wan'
firewall.@redirect[21].name='hass'
firewall.@redirect[21].target='DNAT'
firewall.@redirect[21].dest_ip='10.0.1.104'
firewall.@redirect[21].proto='tcp'
firewall.@redirect[21].src_dport='8123'
firewall.@redirect[21].dest='wan'
firewall.@redirect[21].src_ip='10.0.1.0/24'

this is still not working. it doesnt work as i said... .
and using that rule i cant access it from remote machine anymore ...
so its Completely broken now.

:warning: and an allow rule.......

(I usually don't make the rules for people too....so please be patient with me creating a rule for you because you want to override traffic from WAN into LAN........this is the security risk I noted... :warning: )

config rule                                                        
        option target 'ACCEPT'                                                       
        option src 'wan'                                        
        option dest 'lan'                                          
        option name 'Allow_his_stuff'                                                
        option family 'ipv4'                                         
        option proto 'tcp'                                         
        option src_ip '10.0.1.0/24'                                                  
        option dest_ip '10.0.1.104'                               
        option dest_port '8123'

Reason, again....

(this is why this is not a suggested method to get around the firewall)

:warning: verify/test this rule - as I already explain the issue with this setup, and by looking at the rule, you hopefully understand why