you got it.
I want to use the gateway of the phone not of openwrt.
The gateway of the phone is dynamic, it keeps changing on reboot of phone.
I need to keep putting the new gateway in all clients manually.
I want openwrt to redirect from lan ip to gateway, so I can change gateway in openwrt and not have to change in all the clients
masquerading is working for router ip not gateway
ok, but why ?
if your OpenWRT is configured as it should be, then your right side (LAN) will be on 192.168.1.x
OpenWRT will be on 192.168.1.1, as GW for LAN
and WAN (WWAN) port of OpenWRT will act as a DHCP client with masquerading, this way, your LAN will hit OpenWRT and then router will translate these request and send toward Android, and nobody care what IP Android giving on USB
and WAN (WWAN) port of OpenWRT will act as a DHCP client with masquerading, this way, your LAN will hit OpenWRT and then router will translate these request and send toward Android, and nobody care what IP Android giving on USB
I care, because, the webui of the apps on android can be accessed only via IP android is giving, not only the ip but more specifically the gateway of USB/Wan(left side)
There is a way to redirect a fixed ip of openwrt to a specified gateway, I just dont know how to do it
either using
Network > Routing
or
Network > DHCP and DNS > Static leases
or
Network > Firewall > NAT Rules
One thought which springs to mind is something along these lines:
If you're trying to get OpenWRT to use your phone as its upstream router (its Internet gateway), then how about this?
ifconfig eth0 | awk -F'[ \t:]' '/inet / {print $13;}' - replace the interface name and array index if necessary, according to your own setup.route | awk '/default/ {print $2;}' - replace the array index if necessary, according to your own setup.If you can obtain those details programmatically, you can then use them in any other scripts you may wish to execute, to control traffic flow to your desired applications.
thanks, appreciate the input
I currently use
ip route | grep default | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | tail -1
for mounting a ftp drive that is on android
There are other places I need to manually enter the ip and can't do it programmatically, but it s what it is 
So let's try to think around the problem.
As I understand it, from your original description and your subsequent diagram, your Android phone is both your Internet gateway and a host for some applications that you want to access from other devices on the network:
Note, the LAN IP addresses are representative for the purpose of discussion; don't worry if yours are different.
If I understand correctly, one application hosted on your Android phone is Plex, and the Web UI listens on (I assume) port 8888. So your challenge is to be able to connect to http://x.x.x.x:8888/ but x.x.x.x changes every time.
You could, with some experimentation, configure OpenWRT to intercept http://192.168.1.1:8888/ and redirect the traffic to the Android phone.
The tethering gateway address isn't fixed every time, so port forwarding from OpenWRT's LAN interface to Android will be tricky to achieve directly. But what else could you do?
This is where obtaining the Android phone's IP address programmatically within OpenWRT might help, with a little bit of ingenuity.
One possibility which comes to mind is using iptables or nftables (depending on your OpenWRT version) to intercept and redirect traffic to the intended destination. If that approach is possible, it would involve some work with scripts on the command line.
One example, using iptables:
Detect the WAN gateway (next hop) once only, on OpenWRT boot:
/etc/rc.local:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
GATEWAY=`route | awk '/default/ {print $2;}'`
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1 --dport 8888 -i eth0 -j DNAT --to-destination $GATEWAY:8888
exit 0
You may also find success using crontab to schedule a regular iptables command, but bear in mind that the above example will keep adding PREROUTING directives; you may need to spend some time working out how to remove unneeded PREROUTING directives so that you end up with only the one(s) you need. One possibility might be to restart the firewall service each time, which will flush the table, but that's a bit of a crude blunt instrument and might interfere with other traffic which is flowing at the same time.
You might have success with some form of link detection, so that iptables runs only when the WAN link status changes. Again, as above, you'll need to find a way to detect and remove unneeded iptables entries.
The latest versions of OpenWRT no longer use iptables, but use nftables. The syntax for nftables is different to iptables, and I have not yet spent enough time with nftables to be confident of offering specific advice on it. However, the principle (intercept 192.168.1.1:8888, redirect to Android phone) is the same, even if the exact syntax to achieve it is different.
It may be an exercise for the reader to learn nftables and, in turn, provide advice on nftables to the rest of the forum...
sincerely appreciate the time you have spent in explaining this to me.
I have 3 ports,
Plex Media Server running on port 32400
Material files ftp server on port 2121
ttorrent app running on 1080 port
based on your input, I guess the following would work
GATEWAY=`route | awk '/default/ {print $2;}'`
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1 --dport 1080 -i usb0 -j DNAT --to-destination $GATEWAY:1080
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1 --dport 32400 -i usb0 -j DNAT --to-destination $GATEWAY:32400
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.1 --dport 1080 -i usb0 -j DNAT --to-destination $GATEWAY:1080
I changed ports and interface to usb0 or should it be wan so lost 
Anyway, rebooting to flush the iptables is not an issue.
I will try this.
I'm on the latest version of openwrt, so I'm guessing the 'iptables' won't work, but thank you for conceptually pointing me in the right direction!
Does this hardcoded way look correct?
The interface name in those code examples should be the interface name reported by the operating system (e.g. the output of "ifconfig" or "ip addr"), not the "lan"/"wan" names used to abstract their function.
The "-i" parameter in iptables indicates the incoming interface. If "-i" is used, then the rule will match on incoming traffic. The complementary option "-o" indicates the outgoing interface. But "-o" isn't necessary here, as it doesn't apply to this type of scenario.
So, if your LAN (i.e. incoming) interface is "usb0" then use "usb0" in those examples. But if your WAN is "usb0" then rethink which interface name you ought to use.
It may help to think of the problem this way:
Your examples contain two interceptions of port 1080, but no interceptions of port 2121. Your post indicated that you want ports 32400, 2121, and 1080.
No. You cannot achieve your stated goal (or, at least, what I believe your stated goal to be) with hard-coded NAT rules in the GUI. The GUI is good, and can do a lot, but it has some limitations where dynamic situations obtain.
Hard-coded NAT rules would work if you could guarantee that the phone's IP address (and therefore the router's upstream gateway) would never change. But, by your own admission, the phone's IP address does change, so your challenge is to be able to work with that limitation.
In addition, your rule is for Source NAT (SNAT), where the source of the traffic is - or should remain - unknown to the target. But your scenario calls for Destination NAT (DNAT), where the ultimate destination of the traffic is not the destination the client first tries to connect to.
I meant, if I manually change(edit/save) the rule, on reboot the phone, the phone usually requires a reboot twice a month.
It would still be much less harrowing to change the rule than to change the multiple places I have to now.
I totally get your point, dynamically, is the smartest way to go, at the moment, I just want to see if this is correct and will work, using UI.
later on, playing with the new standard, nftables, is what I was thinking
Ah, I see. Well, if you don't mind putting in some manual effort, then sure, it shouldn't be too difficult to configure a DNAT rule manually. As long as the phone's IP address doesn't change, the rule should keep working.
To configure a DNAT rule, you would need to keep this in mind:
That SNAT rule appears to says:
if SRC 192.168.1.1 and DST is 192.168.1x.xxx rewrite SRC to 192.168.1.1
That rule won't do anything. Also, there's no need to obscure a Private IP address, it just makes it difficult to assist you.
Well, stone the crows, it doesn't look like DNAT is an option in the GUI. All I can find is SNAT, MASQUERADE, and ACCEPT.
In this screenshot, 10.20.30.40 is assumed to be the upstream IP address of the gateway (in your case, your phone). Hopefully it illustrates the concept, even if there's no GUI option for DNAT.
Note: the Source Address can be left empty if desired; populating it with specific IP addresses or an entire subnet simply limits the rule to apply to any traffic originating from those devices/subnets. In that way, you could have some reasonably clever processing going on, whereby some clients get to use the NAT rule and other clients don't, depending on the sort of traffic control you desire.
As for that missing DNAT, once I configure the SNAT rule, I'm going to dive into the config files directly and see if I can fiddle around there.
Right. Here's what's in /etc/config/firewall for that SNAT rule:
config nat
option name 'Plex Media Server DNAT'
option family 'ipv4'
list proto 'tcp'
option src 'wan'
option src_ip '192.168.1.0/24'
option dest_ip '192.168.1.1'
option dest_port '32400'
option target 'SNAT'
option snat_ip '10.20.30.40'
option snat_port '32400'
I'm going to change it to this, and see what happens:
config nat
option name 'Plex Media Server DNAT'
option family 'ipv4'
list proto 'tcp'
option src 'wan'
option src_ip '192.168.1.0/24'
option dest_ip '192.168.1.1'
option dest_port '32400'
option target 'DNAT'
option dnat_ip '10.20.30.40'
option dnat_port '32400'
Okay. That didn't work:
root@vm-openwrt:/etc/config# /etc/init.d/firewall restart
Section @nat[0] (Plex Media Server DNAT) specifies unknown option 'dnat_ip'
Section @nat[0] (Plex Media Server DNAT) specifies unknown option 'dnat_port'
Section @nat[0] (Plex Media Server DNAT) has invalid target specified, defaulting to masquerade
This might be a defect in OpenWRT (or a defect in my understanding of fw4 / nftables, which is entirely possible).
fw3 / iptables included built-in support for DNAT - https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_nat
So, gentle reader, it looks like my oh-so-brilliant idea of using scripts and DNAT to intercept and redirect traffic automatically might be a non-starter. Hmph.
Apologies; I honestly thought it would work (because I have done it successfully on fw3 / iptables in the past).
yup
root@OpenWrt:~# /etc/init.d/firewall restart
Section @nat[0] (Plex) has invalid target specified, defaulting to masquerade
Section @nat[0] (Plex) must not use 'snat_ip' for non-snat target, ignoring section
I appreciate you
If one issues fw4 print or nft list ruleset there is a dstnat chain in the table. But I have been unable to insert a DNAT rule into that chain using the nft command line.
If I try, I get no response (which usually implies success, since it's a common Unix convention to provide a response only on an error):
root@vm-openwrt:/# nft add rule inet fw4 dstnat dif "eth1" ip daddr 192.168.1.1 tcp dport 32400 dnat 10.20.30.40:32400 comment "Plex"
Error: No symbol type information
add rule inet fw4 dstnat dif eth1 ip daddr 192.168.1.1 tcp dport 32400 dnat 10.20.30.40:32400 comment Plex
root@vm-openwrt:/# nft add rule inet fw4 dstnat iif "eth1" ip daddr 192.168.1.1 tcp dport 32400 dnat 10.20.30.40:32400 comment "Plex"
root@vm-openwrt:/#
Based on my experience of Linux over the years, that absence of any error suggests that the command should have been accepted. But the dstnat chain remains empty:
root@vm-openwrt:/# fw4 print
table inet fw4
flush table inet fw4
table inet fw4 {
[...]
#
# NAT rules
#
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
}
[...]
}
Now, as indicated previously, I'm nowhere near as familiar with nftables as I am with iptables. So I am unsure whether this is a consequence of a defect in the product, or in my understanding of the product.
And there's more...
Searching the forum for "fw4 dnat" (on the basis that someone else might have had a similar challenge and solved it) turned up this thread:
The example in that thread got me thinking, so I tried this, in /etc/config/firewall:
config redirect
option name "Plex"
list proto 'tcp'
option dest 'wan'
option src 'lan'
option src_dip '192.168.1.1'
option src_dport '32400'
option dest_ip '10.20.30.40'
option dest_port '32400'
option target 'DNAT'
You'll note the stanza of "redirect" instead of "nat".
This is the relevant excerpt from fw4 print, after restarting the firewall:
#
# NAT rules
#
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
iifname "eth1" jump dstnat_lan comment "!fw4: Handle lan IPv4/IPv6 dstnat traffic"
}
chain dstnat_lan {
ip daddr 192.168.1.1 tcp dport 32400 counter dnat 10.20.30.40:32400 comment "!fw4: Plex"
}
And this is the corresponding GUI entry:
So... maybe it's possible after all, but using "Port Forward" instead of "NAT Rules". After all, most "port forward" configurations are to open ports for inbound traffic and send them to the real recipient, the very essence of DNAT. The fact that you want to perform DNAT in the other direction doesn't change the concept, it just changes where you configure it.
I assume you mean there no LuCI menu tab named "DNAT"?
In OpenWrt, it's here:
Port Forwards
