Context: I am trying to emulate my Arlo base station with my router. However, the camera itself will try to connect the the API that runs on router at port 5000. So I need to find a way to map the port at .0.1:5000 to the actual server.
The server is running at 192.168.0.2:5000. It is connected to the router (192.168.0.1) via ethernet. Arlo camera is connected to the router's wireless network. The camera is trying to connect to the ...1:5000 for the API and I would like to route all the traffic to ...2:5000 with openwrt.
Can you change the address that the camera uses to reach the server? In other words, can you tell the camera that the server is at a different address?
Nope. More context, the whole process is a hack to get the RTSP link from Arlo cameras which they decided not to expose. The limitation is that I cannot control the camera itself but only to emulate the station. The way the camera works is it finds a predefined SSID, and connects the AP router's 5000 port for API.
It works on my laptop when I was starting the server and using hostapd to create a wifi network. But unfortunately when I tries to have a more permanent setup by setup the same network on my router and start the server on another machine i need to find a way to workout the port mapping.
There is no way to port map from lan to lan.... but you could change the address of the router and then put the server at 192.168.0.1. There are no absolute rules about the IP address that the router itself takes on your network, but convention dictates that it is often either the first or last valid host address on the network (.1 or .254). It is critical, though, that the router's address is not within the DHCP range.
How will hairpin help? The addresses are local. Hairpin helps when the address that is being accessed from within the lan is the effective wan address that is then port forwarded.
root@192.168.1.1:~# uci add firewall redirect
root@192.168.1.1:~# uci set firewall.@redirect[-1].target='DNAT'
root@192.168.1.1:~# uci set firewall.@redirect[-1].name='test'
root@192.168.1.1:~# uci set firewall.@redirect[-1].family='ipv4'
root@192.168.1.1:~# uci set firewall.@redirect[-1].src='lan'
root@192.168.1.1:~# uci set firewall.@redirect[-1].src_dport='5000'
root@192.168.1.1:~# uci set firewall.@redirect[-1].dest_ip='192.168.1.5'
root@192.168.1.1:~# uci set firewall.@redirect[-1].dest_port='5000'
root@192.168.1.1:~# uci commit
root@192.168.1.1:~# reboot
root@desktop:~# nc 192.168.1.1 5000
hi
^C
root@192.168.1.5:~# tcpdump -nni eth0 'tcp port 5000'
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP 192.168.1.1.54092 > 192.168.1.5.5000: Flags [S], seq 501927521, win 64240, length 0
IP 192.168.1.5.5000 > 192.168.1.1.54092: Flags [S.], seq 1008686772, ack 501927522, win 65160, length 0
IP 192.168.1.1.54092 > 192.168.1.5.5000: Flags [.], ack 1, win 502, length 0
IP 192.168.1.1.54092 > 192.168.1.5.5000: Flags [P.], seq 1:4, ack 1, win 502, length 3
IP 192.168.1.5.5000 > 192.168.1.1.54092: Flags [.], ack 4, win 2037, length 0
IP 192.168.1.1.54092 > 192.168.1.5.5000: Flags [F.], seq 4, ack 1, win 502, length 0
IP 192.168.1.5.5000 > 192.168.1.1.54092: Flags [F.], seq 1, ack 5, win 2037, length 0
IP 192.168.1.1.54092 > 192.168.1.5.5000: Flags [.], ack 2, win 502, length 0
Looks fine to me.
Only thing to notice is that the source IP when the traffic lands on 192.168.1.5 is not my desktop machine where the traffic comes from (desktop = simulating your camera), but rather 192.168.1.1. I guess I have masquerading enabled on the "lan" zone.
Try enabling masq on lan zone and see if the port forwarding rule starts working I guess?...
Thanks! I tried this and interestingly, without masq there are packets gets forwarded to the server on my side as well. I could repro your tcpdump results.
However, the thing is that it doesn't work for a webserver, and I guess probably the server (1.5) doesn't know where it should route the reply to? I am very confused now but feel it's getting close. I could also tested to have a reverse proxy but thought it might not be needed.
Where does 192.168.1.5 fit into the equation? You earlier said that the server is at 192.168.0.2 and the router is at 192.168.0.1. I'm also a bit confused at how this API is supposed to work... you said that it is running on the router itself, emulating the Arlo base station. But then the server is at a different address... shouldn't the API be on the same machine as the server?
Correct, if you simply destination-nat from a src-ip to a dst-ip in the same subnet, the destination will try and route reply packets directly to the origin, in other words you get asymmetric routing. The origin will see the reply traffic, but with an unknown (to it) source-ip and therefore drop the reply. You will likely only get as far as SYN-ACK. Port numbers might also get mangled by destination-nat. In other words, you need to enable masquerading or it won't work.
That would also work if you don't want masq enabled on the lan zone.
I think OP just copy-pasted from the test run that I did.