How do I obtain a "busybox linux" router WAN ip address?

Usalabs · 08-19-2006, 05:51 PM

I'm trying to write a small script for someone, incorporating iptables, so that they can do like I do, and test their web server from behind a NAT router, the script is small, but I need to be able to find a way to use a variable to look at the router's ppp0 setting and return the WAN IP address, EG.

$WAN_IP = [the ppp0 setting]
$LAN_IP = web server static LAN IP
$PORT = port used for various services, IE, 80 = web, 21 = FTP, etc etc

iptables -t nat -A PREROUTING --dst $WAN_IP -p tcp --dport $PORT -j DNAT --to-destination $LAN_IP

iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $PORT -j SNAT --to-source $WAN_IP

He used the above command directly into the router via telnet (substituting the $ variables with the actual IP addresses), but during a storm, the router would need to be powered down thus resulting in a change of WAN IP address when the router is powered back up, hence the need for the script and a variable to read the ppp0 setting to return the router WAN IP address.

I can't just use WAN_IP=xx.xx.xx.xx as that would be defeating the object, xx.xx.xx.xx has to return the WAN IP address value somewhere in the router, so that when the WAN IP address in the router changes, the contents of the $WAN_IP variable also changes.

Any suggestions?

win32sux · 08-19-2006, 11:19 PM

Quote:

Originally Posted by Usalabs

I'm trying to write a small script for someone, incorporating iptables, so that they can do like I do, and test their web server from behind a NAT router, the script is small, but I need to be able to find a way to use a variable to look at the router's ppp0 setting and return the WAN IP address, EG.

$WAN_IP = [the ppp0 setting]
$LAN_IP = web server static LAN IP
$PORT = port used for various services, IE, 80 = web, 21 = FTP, etc etc

iptables -t nat -A PREROUTING --dst $WAN_IP -p tcp --dport $PORT -j DNAT --to-destination $LAN_IP

iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $PORT -j SNAT --to-source $WAN_IP

He used the above command directly into the router via telnet (substituting the $ variables with the actual IP addresses), but during a storm, the router would need to be powered down thus resulting in a change of WAN IP address when the router is powered back up, hence the need for the script and a variable to read the ppp0 setting to return the router WAN IP address.

I can't just use WAN_IP=xx.xx.xx.xx as that would be defeating the object, xx.xx.xx.xx has to return the WAN IP address value somewhere in the router, so that when the WAN IP address in the router changes, the contents of the $WAN_IP variable also changes.

Any suggestions?

i'm a newbie as far as scripting, but these commands seem to do the trick for me:

Code:

ifconfig | grep -A 1 ppp0 | grep inet | awk '{print $2}' | sed -e 's@addr:@@'

i don't have a ppp0 interface, but i tried it with my eth1 and it worked:

Code:

win32sux@carly:~$ ifconfig
eth1      Link encap:Ethernet  HWaddr 11:47:54:82:9C:B0
          inet addr:201.74.194.216  Bcast:255.255.255.255  Mask:255.255.255.0
          inet6 addr: fe85::242:53ff:fe21:9bb0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:239753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24852 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:34149576 (32.5 MiB)  TX bytes:4104436 (3.9 MiB)
          Interrupt:10 Base address:0x4f00

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:51981 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51981 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:31078752 (29.6 MiB)  TX bytes:31078752 (29.6 MiB)
win32sux@carly:~$ ifconfig | grep -A 1 eth1 | grep inet | awk '{print $2}' | sed -e 's@addr:@@'
201.74.194.216

i'm not sure if the ifconfig busybox uses has the same output layout, but if it does, then it should work... if it doesn't have the same layout, then either adjust my commands, or post the output of ifconfig and i'll do the adjusting for you if you want...

EDIT: here's another (simpler) approach i came-up with:

Code:

ip addr show ppp0 | grep "inet " | awk '{print $2}'

on my box (with eth1) it looks like:

Code:

win32sux@carly:~$ ip addr show eth1 | grep "inet " | awk '{print $2}'
201.74.194.216/24

win32sux · 08-19-2006, 11:31 PM

also, keep in mind that if the interface only has one IP address at a time (whether dynamic or not), there's no need to specify it in your iptables rules... in other words, this would work fine:

Code:

iptables -t nat -A PREROUTING -p TCP -i ppp0 --dport $PORT \
-j DNAT --to-destination $LAN_IP

as for your POSTROUTING rule, it looks kinda weird... could you please explain what you are doing with that rule??

Usalabs · 08-20-2006, 02:17 AM

Quote:

Originally Posted by win32sux

as for your POSTROUTING rule, it looks kinda weird... could you please explain what you are doing with that rule??

As far as I can gather,

Code:

iptables -t nat -A PREROUTING --dst $WAN_IP -p tcp --dport $PORT -j DNAT --to-destination $LAN_IP

sends the http request out from the LAN IP address to the outside WAN IP address, thus the opposite is needed to return that http request back to the web client from behind the NAT router, thus this line:-

Code:

iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $PORT -j SNAT --to-source $WAN_IP

Thus bypassing masquerade, if only the first line is used, then the http request can only get out, so how would it get back to the client if there's no route for it to return.

Without the 2 lines, entering the LAN servers url into a web browser would only open the routers control panel, but by using both the lines, the servers url can successfully be entered and the LAN server's web site be tested from behind the NAT router, without using the hosts file.

I tested it by deleteing the 2 rules, and entering my www url into firefox, and I got the routers sign in for the control panel, but after entering the 2 iptables lines I enter the same url into firefox and I got the home page of the LAN server, (after first buying a domain, and setting up the dns service to point to my WAN IP address).

I hope all this makes sense, as I don't actually know the full ins and outs of how iptables work, but based on common sense a lot of reading, and testing, I came up with those 2 lines.

win32sux · 08-20-2006, 05:30 PM

Quote:

Originally Posted by Usalabs

As far as I can gather,

Code:

iptables -t nat -A PREROUTING --dst $WAN_IP -p tcp --dport $PORT -j DNAT --to-destination $LAN_IP

sends the http request out from the LAN IP address to the outside WAN IP address, thus the opposite is needed to return that http request back to the web client from behind the NAT router, thus this line:-

Code:

iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $PORT -j SNAT --to-source $WAN_IP

Thus bypassing masquerade, if only the first line is used, then the http request can only get out, so how would it get back to the client if there's no route for it to return.

Without the 2 lines, entering the LAN servers url into a web browser would only open the routers control panel, but by using both the lines, the servers url can successfully be entered and the LAN server's web site be tested from behind the NAT router, without using the hosts file.

I tested it by deleteing the 2 rules, and entering my www url into firefox, and I got the routers sign in for the control panel, but after entering the 2 iptables lines I enter the same url into firefox and I got the home page of the LAN server, (after first buying a domain, and setting up the dns service to point to my WAN IP address).

I hope all this makes sense, as I don't actually know the full ins and outs of how iptables work, but based on common sense a lot of reading, and testing, I came up with those 2 lines.

when you say "behind the NAT router" you mean "from the WAN side", right??

if so, then it sounds like you are trying to do a typical HTTP port-forwarding here... AFAICT, one of the reasons why you have been using the weird POSTROUTING rule is because of this:

Quote:

sends the http request out from the LAN IP address to the outside WAN IP address, thus the opposite is needed to return that http request back to the web client from behind the NAT router, thus this line:
Thus bypassing masquerade, if only the first line is used, then the http request can only get out, so how would it get back to the client if there's no route for it to return.

the POSTROUTING rule you have there isn't needed... the generic MASQUERADE rule is all you need... this is because of netfiler's state table... netfilter keeps track of connections in the state table, so iptables doesn't need to tell it anything about the outgoing packets, as it will just check the state table to see if those packets belong to an already initiated connection... here's an example of how it's done:

Code:

iptables -P FORWARD DROP

iptables -t nat -A PREROUTING -p TCP -i $WAN_IFACE --dport $PORT \
-j DNAT --to-destination $SERVER_IP

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -p TCP -i $WAN_IFACE -o $LAN_IFACE --dport $PORT \
-d $SERVER_IP -m state --state NEW -j ACCEPT

iptables -t nat -A POSTROUTING -o $WAN_IFACE -j MASQUERADE

notice how $WAN_IP was never used or needed...

a new (syn) HTTP packet hitting the WAN side of the router will have its destination address changed to $SERVER_IP by the DNAT rule... i used $SERVER_IP instead of $LAN_IP to avoid confusion, as it needs to be the IP address of the HTTP server on your LAN, not the IP of your router's LAN side...

the packet then leaves the PREROUTING chain and goes into the FORWARD chain... the FORWARD chain's policy is set to DROP, so any packet not matching a rule will die... the first rule the packet hits here is the ESTABLISHED,RELATED rule... netfilter will check the state table to see if this packet is part of an established connection, but since this packet is new (in fact, it's initiating a connection), it will not match that rule and will continue traversing the chain...

the next rule is precisely the one we've made to handle this kind of packet... netfiler will see that the packet's state is indeed NEW, that it's incoming interface is $WAN_IFACE and it's outgoing one is $LAN_IFACE, that it's protocol is TCP, it's destination port is 80, and its destination address is $SERVER_IP... so the packet will match this rule and will get sent to ACCEPT...

now the server will send back packets intended for the client which initiated the connection on the WAN side... the packets coming-in from the server will hit the router's LAN side and will go into the FORWARD chain (since it hasn't been matched by any chains in the NAT table, etc)... the packet hits the first FORWARD rule, and netfilter checks the state table... the packet is determined to in fact be part of the already ESTABLISHED connection and the packet is sent to ACCEPT right away...

before the packet gets put on the wire, it hits the POSTROUTING chain, where its source IP address (currently $SERVER_IP) is changed to be the one which $WAN_IFACE (ppp0) is currently using...

then the process is repeated over and over, except that now the packets which the client sends back will not be of state NEW anymore, so they will get matched against the first rule of the FORWARD chain until that connection in particular is ended...

win32sux · 08-20-2006, 06:09 PM

please ignore everything i have posted (except the commands to insert the IP address)... cuz yeah, i think i understand what you are doing now (sorry, i was lost in space there for a while)... i won't delete the stuff i posted above, in case someone else might find it useful... but i note that i am now aware that it's irrelevant to your issue (getting the effect of being in front of your firewall, while being in fact behind it)... so anyhow, i hope my commands to get the IP helped... good luck...

Usalabs · 09-15-2006, 06:53 PM

Thanks for everyones help, but I found a better solution.

After getting fed up with manually telnetting into the router everytime there's a power failure, I decided to get an old machine, and install windows 2003 server being used as a web and dns server, connected to the LAN, with a static ip address and my isp dns addresses entered into the servers TCP/IP settings then, using that static IP address of the server, entered into the DSN settings of the TCP/IP settings of all the clients that's connected to the LAN, I was able to test the web server without using iptables of the router or the hosts file.