Hairpin nat broken not working properly

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

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. 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.
  2. verify this Public IP matches IP on new ISP router

Did you add the rule?

Where is (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.


  • From lan to wan
  • By default, this is firewalled
  • This rule would allow the packet ad change it's DST to
config redirect                                          
        option target 'DNAT'                                         
        option src 'wan'                                           
        option proto 'tcp'                
        option src_dport '8123'                                        
        option dest_port '8123'                                      
        option src_ip ''    
        option dest 'wan'          #<--------NOTE WAN                             
        option dest_ip ''                              
        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.


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

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


:spiral_notepad: In your case - WAN.

what is allow rule/ or add where?


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 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 ''                                                  
        option dest_ip ''                               
        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

so how is it possible it was working before i changed isp router? i dont get it at all.

there is no point to adding Messed rules;
it should work using Hairpin NAT not with some kind of mess ...