IP-Cam not accessible from LAN with WAN URL

[lwizard]

I'm with latest Merlin firmware on AC68U.
Factory resetted and applied config manually.

There is a strange thing.
I have an WiFi IP camera. I have set a DHCP reservation on 192.168.1.150 and a portforwarding to be able to access it from WAN.

Now I can access its interface from LAN with 192.168.1.150 : port and from WAN with my internet static IP +port.

I am not able to access it from LAN using WAN url. So my android app which is setted with WANURL : port can't access the camera when connected to LAN, but can access it when using data instead of WiFi (from WAN).

What can I do?
Before upgrading I hadn't got this problem.
Other services like transmission are accessible from LAN through WAN ip...

EDIT: i disabled the AC68U firewall and it was accessible from LAN>WAN>LAN as i wanted.
I than re-enabled the firewall and still works.

Is it a bug of new merlyn firmware (or also an asus bug)?

 

[lwizard]

Still problems

After restarting router the problem is againg there.
But after restarting firewall (changing a simple setting like DOS protection) the camera is again accessible from LAN with internet IP.

Some info from log:

* Invalid signature of oopsbuf: 42-A5-43-0A-4A-00-44-58 (len 3187712)
...
Dec 1 01:00:14 kernel: External imprecise Data abort at addr=0x0, fsr=0x1c06 ignored.
...
rc_service: udhcpc 902:notify_rc start_firewall
...
rc_service: waitting "start_firewall" via udhcpc ...
...
Dec 1 01:00:46 admin: sh /opt/S95transmission.1 firewall-start
(I have a firewall rule for transmission through Optware)
...
Feb 20 12:20:30 rc_service: httpd 685:notify_rc restart_firewall
Feb 20 12:20:31 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Feb 20 12:20:31 dnsmasq[980]: exiting on receipt of SIGTERM
Feb 20 12:20:32 dnsmasq[1340]: started, version 2.73test6 cachesize 1500
Feb 20 12:20:32 dnsmasq[1340]: warning: interface ppp1* does not currently exist
Feb 20 12:20:32 dnsmasq[1340]: asynchronous logging enabled, queue limit is 5 messages

Any ideas?

 

[ontwowheels]

I'm with latest Merlin firmware on AC68U.
Factory resetted and applied config manually.

There is a strange thing.
I have an WiFi IP camera. I have set a DHCP reservation on 192.168.1.150 and a portforwarding to be able to access it from WAN.

Now I can access its interface from LAN with 192.168.1.150 : port and from WAN with my internet static IP +port.

I am not able to access it from LAN using WAN url. So my android app which is setted with WANURL : port can't access the camera when connected to LAN, but can access it when using data instead of WiFi (from WAN).

What can I do?
Before upgrading I hadn't got this problem.
Other services like transmission are accessible from LAN through WAN ip...

EDIT: i disabled the AC68U firewall and it was accessible from LAN>WAN>LAN as i wanted.
I than re-enabled the firewall and still works.

Is it a bug of new merlyn firmware (or also an asus bug)?

Welcome to the party. Have seen this exact issue on the 68U running both the latest Marlin non beta and stock Asus firmware. This is called NAT loopback and seems to be extremely buggy.

 

[ontwowheels]

On an older router running DD-WRT there was a fix for this issue, running a firewall script.

 

[RMerlin]

On an older router running DD-WRT there was a fix for this issue, running a firewall script.

You are probably thinking about Phuzi0n's NAT loopback implementation, which is was I was using, and had to revert because it's not compatible with the closed-source DPI engine.

 

[ontwowheels]

You are probably thinking about Phuzi0n's NAT loopback implementation, which is was I was using, and had to revert because it's not compatible with the closed-source DPI engine.

You are exactly correct sir:



Save the following commands to the Firewall Script on the Administration->Commands page to fix loopback.

insmod ipt_mark
insmod xt_mark
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark
iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE



If you have a block of static IP's using 1:1 NAT then you also need to add another iptables rule to cover your IP block. Edit the bolded netblock to be your static IP block and add the rule before the CONNMARK rule.

iptables -t mangle -A PREROUTING -i ! `get_wanface` -d 1.1.1.0/24 -j MARK --set-mark 0xd001

 

[ontwowheels]

What's funny is NAT loopback worked perfectly in my RT-AC68U when it was a TM-AC1900.

 

[RMerlin]

What's funny is NAT loopback worked perfectly in my RT-AC68U when it was a TM-AC1900.

The problem lies in the addition of the new DPI engine. That script you posted won't work reliably. The DPI engine will flush out the PREROUTING chain when it resets itself. Also, the QoS implementation now uses masks, so marks with a random value such as d001 might not work properly either.

As I said, that's exactly what the firmware was previously using, and it no longer works, hence my removal.

 

[ontwowheels]

The problem lies in the addition of the new DPI engine. That script you posted won't work reliably. The DPI engine will flush out the PREROUTING chain when it resets itself. Also, the QoS implementation now uses masks, so marks with a random value such as d001 might not work properly either.

As I said, that's exactly what the firmware was previously using, and it no longer works, hence my removal.

Tmobile/Asus's TM-AC1900's firmware I assume was based on a version of Asus's firmware. That did not have the DPI engine?

I guess the good news is, NAT loopback isn't just totally hosed in your firmware, it's hosed in Asus's as well.

 

[RMerlin]

Tmobile/Asus's TM-AC1900's firmware I assume was based on a version of Asus's firmware. That did not have the DPI engine?

I guess the good news is, NAT loopback isn't just totally hosed in your firmware, it's hosed in Asus's as well.

The DPI engine was only added to the RT-AC68 after firmwares 378_xxxx.

Sent from my Nexus 4 using Tapatalk

 

[ontwowheels]

The DPI engine was only added to the RT-AC68 after firmwares 378_xxxx.

Sent from my Nexus 4 using Tapatalk

Gotcha...thanks for the feedback.

 

[ontwowheels]

The DPI engine was only added to the RT-AC68 after firmwares 378_xxxx.

Sent from my Nexus 4 using Tapatalk

Not sure why, but running the latest Asus firmware for the AC68U, if I stop port forwarding and apply, and enable port forwarding and apply, loopback will work but for about a day.

 

[netmik3]

Not sure why, but running the latest Asus firmware for the AC68U, if I stop port forwarding and apply, and enable port forwarding and apply, loopback will work but for about a day.

Me too then rc service restarts and kills it. I haven't reset my router after the latest firmware though. So I'm blaming myself.

Also somewhere along the line I lost my lan dhcp range setting.

 

[ontwowheels]

Me too then rc service restarts and kills it. I haven't reset my router after the latest firmware though. So I'm blaming myself.

Also somewhere along the line I lost my lan dhcp range setting.

No, I have done full factory resets AND power on holding WPS button. Don't think that will help you.

 

[netmik3]

No, I have done full factory resets AND power on holding WPS button. Don't think that will help you.

Oh ok. Good I won't be resetting until I get my ac3200 soon.

This rc error only happened on the final firmware not the betas afaik.