TomatoUSB

This option is already in Tomato/MLPPP, and is very nice for everyone to access the webinterface of the modem through the router

nice feature, do you have to edit any routing tables in the modem or/and the router? or it does automaticaly?
you access the modem which is in bridge mode i suppose?

This post is a little old, but I would also love to have this feature!

From what I remember, I think the router and the modem need to be in different subnets.
But for a modem at 192.168.1.254, you could set the subnet mask to 255.255.255.128 to seperate them and keep the "default" 192.168.1.1xx for LAN devices.

I'd like to see this supported as a native feature as well. It isn't trivial to implement, as you need a "wizard" or form to collect some information from the user about their modem that the router doesn't inherently have (like the modem's IP address) in the case of a PPPoE connection, and if the network range conflicts with the LAN, there would be additional challenges.

Here's one example implementation where I exposed access to a Zoom DSL modem (10.0.0.2) via an IP alias on the router's LAN port (192.168.1.3). I added this code to Administration->Scripts->Init:

sleep 45
# add IP to modem port
ifconfig vlan2 add 10.0.0.100
# add alias to LAN port
ifconfig br0:0 192.168.1.3
# IP-alias forward to modem
iptables -t nat -I PREROUTING -i br0 -d 192.168.1.3 -j DNAT --to-destination 10.0.0.2
# fake source IP when sending to modem
iptables -t nat -I POSTROUTING -d 10.0.0.2 -j SNAT --to-source 10.0.0.100
# fake source IP when forwarding replies from modem
iptables -t nat -I POSTROUTING -s 10.0.0.2 -j SNAT --to-source 192.168.1.3

The code always worked perfectly when entered manually on the command line, but seemed to succeed sporadically after a reboot. Perhaps the sleep time needed to be increased, or some other command added at the top that would block until the necessary resource is available. (I'm not sure why the delay is needed. Are the LAN interfaces not up when this script runs? It doesn't make sense to put this in the WAN Up box, as you often want to access the modem to diagnose why the WAN isn't up.)

-Tom

I used to use this script that I picked up from an old Toastman thread on the Linksysinfo forum.
This was based on Router IP being 192.168.0.1 and modem set manually to 192.168.1.1

## Toastman Hack to allow route to ADSL modem
sleep 5
ip addr add 192.168.1.13/24 dev $(nvram get wan_ifname) brd +

Here you go ;)
http://repo.or.cz/w/tomato.git/commit/98e54097e54c1625bd10e7d0a8e842b5176d9595

Occamsrazor wrote:

## Toastman Hack to allow route to ADSL modem
ip addr add 192.168.1.13/24 dev $(nvram get wan_ifname) brd +

If I follow, that just assigns 192.168.1.13 to the WAN interface, which I guess will work fine if your LAN doesn't use 192.168.1.x.

With a modem at 192.168.1.1, and 192.168.1.2 assigned to vlan2 (WAN) and 192.168.0.20 on br0 (LAN), it didn't work for me.

Having the router NAT packets from an IP alias, as documented above, does work for me.

Teaman wrote:

Here you go ;)
http://repo.or.cz/w/tomato.git/commit/98e54097e54c1625bd10e7d0a8e842b5176d9595

Nice!

But this boils down to:

+               sprintf(ip, "%.*s%hhu", end-modem_ipaddr, modem_ipaddr, (unsigned char)(c^1^((c&2)^((c&1)<<1))) );
+               eval("ip", "addr", add ?"add":"del", ip, "peer", modem_ipaddr, "dev", iface);

which I think is doing the same thing as the hack that just assigns an IP address to the WAN port, assuming that the address doesn't conflict with the LAN range, and the router will handle routing packets to/from the modem using default routes.

My DSL modem has no option to change its IP address, so if it conflicted, I'd be out of luck with this technique.

Has this patch made it into any mainlines?

-Tom

Route modem IP is a Tomato GUI checkbox in many recent mods, but you only need it you are using a PPPoE modem when the WAN is ppp0, and you don't want packets to/from the router to go down the ppp tunnel to the internet.

192.168.1.2 assigned to vlan2 (WAN)

That's a local IP address - is your DSL modem also a router and you are doing 'double nat +DMZ' ?

…you only need it you are using a PPPoE modem…

Generally, yes. And that's apparently common not just with old technology DSL modems like I have, but also with some fiber network terminals used with services like FIOS.

If the "modem" (or whatever border device resides upstream from your router) has an accessible IP, then obviously no extra steps are required to access it.

I also manage a setup using a fixed wireless WAN link, and for that the wireless transceiver acts as a DHCP server, which assigns the router's WAN port an IP. The transceiver's web UI is accessible at 192.168.0.230, and the LAN there happens to use 192.168.1.x range, so there is no conflict, and the packets route fine through the router.

The problem is what do you do when the two networks conflict? (And you don't want to or can't change the assigned addresses to avoid the conflict.) Normal default routing rules won't handle having the same network ranges on two interfaces.

An added complication is that VPNs typically use private IP ranges, so even if you are lucky that your own LAN doesn't conflict with your modem, a VPN you use might conflict.

This is why I think the Tomato UI should hide this complication by automatically creating a NAT rule to access the modem. It should be optional, because in many cases you won't need any special handling. The documentation would explain that if you are using PPPoE, or have a conflicting address, you should enable the option, and fill in the fields needed to create a NAT rule, IP alias, etc. This way the modem can be made accessible from a address that falls within the LAN's address range.

192.168.1.2 assigned to vlan2 (WAN)
That's a local IP address…

An RFC 1918 private IP? Yes. Because the modem, like many consumer networking gear, uses a fixed IP of 192.168.1.1.

is your DSL modem also a router and you are doing 'double nat

No, the modem operates as a bridge, passing on the PPPoE encapsulated packets from the router.

The IP is only used to access the web administration interface.

-Tom

By the way, a potentially easier solution that avoids creating the NAT rules is to assign an IP to the WAN interface and then use ssh port forwarding to expose the modem's UI on your client machine.

For example, I added this:

LocalForward 8880 192.168.1.1:80

to my .ssh/config for my router's entry, ssh'ed to it, then ran:

ifconfig vlan2 add 192.168.1.2

and I could then access the modem's UI from:
http://localhost:8880/

-Tom