OpenWrt Forum Archive

Topic: Accessing modem through router from PC … and understand the network

The content of this topic has been archived on 30 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

This is about accessing my modem through my router from my PC.

It's also about how I simply don't understand this network thing.

The other day I installed OpenWrt on a TP-Link TL-WR941ND router. (It does have WiFi, but I'm not currently using it.) The router has four LAN ports and one WAN port. The WAN port is connected to my DSL modem, a Siemens C2-010-I. My PC is connected to one of the four LAN ports.

I've been able to access my modem from my PC using a diagnostic program (DMT.exe), which uses telnet. I'd like to also access my modem via the router, as explained on this page:

http://wiki.openwrt.org/doc/howto/acces … hrough.nat

As you might suspect by now, that doesn't work, and trying to solve the issue myself I realize that I simply don't understand this network machine, which is why I'd appreciate some help. So without further ado, let's review the settings:

root@TIBERIUS: ~ > ifconfig
br-lan    Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          inet addr:192.168.33.1  Bcast:192.168.33.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1234 errors:0 dropped:133 overruns:0 frame:0
          TX packets:1244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:203880 (199.1 KiB)  TX bytes:1153818 (1.0 MiB)

eth0      Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2758 errors:0 dropped:0 overruns:35 frame:0
          TX packets:2314 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1441164 (1.3 MiB)  TX bytes:1333851 (1.2 MiB)
          Interrupt:4

lan1      Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          … # nothing plugged in

lan2      Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          … # nothing plugged in

lan3      Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          … # nothing plugged in

lan4      Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1392 errors:0 dropped:22 overruns:0 frame:0
          TX packets:1247 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:240088 (234.4 KiB)  TX bytes:1153956 (1.0 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          …

pppoe-wan Link encap:Point-to-Point Protocol
          inet addr:92.***.***.190  P-t-P:213.191.76.24  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:926 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:1131272 (1.0 MiB)  TX bytes:139200 (135.9 KiB)

wan       Link encap:Ethernet  HWaddr 00:23:CD:20:C3:B0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1366 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1066 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1151432 (1.0 MiB)  TX bytes:163827 (159.9 KiB)

A lot of interface - and precisely where I start to lose ground. Let's pick that apart:

  • * lo = loopback to localhost, that's clear
    * lan1 through lan4 = the four LAN ports on my router, also clear (because there's four of them, and my PC is connected to number 4, and there's traffic on number 4)
    * pppoe-wan = PPP link, 92.***.***.190 being my router's IP, 213.191.76.24 my ISP counterpart

I understand that pppoe-wan somehow is on top of a physical interface (must be the WAN port on my router), but I don't understand how exactly. And maybe I don't have to.

But that leaves us with three more interfaces, to wit br-lan, eth0 and wan.

One of eth0 and wan should be the physical interface of my router's WAN port, but which one? And why does it not have an IP number assigned itself?

As for the other one and br-lan, what is their purpose?

Let's move on to /etc/config/network :

config interface 'loopback'
        … # okay

config interface 'eth'
        option ifname 'eth0'
        option proto 'none'
# The purpose of this one is unclear to me.

config interface 'lan'
        option ifname 'lan1 lan2 lan3 lan4'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.33.1'
        option netmask '255.255.255.0'
# I would probably have to understand what a bridge is.

config interface 'wan'
        option ifname 'wan'
        option proto 'pppoe'
        option username …
# My dial-in configuration for DSL, okay.

# My additions following the instructions given at
# [url]http://wiki.openwrt.org/doc/howto/access.modem.through.nat[/url]
# in order to access my modem, which is configured to 192.168.1.1
# and does listen on TELNET and does respond to PING, all verified
# by connecting my PC directly to the modem:

config alias modem
        option interface wan
        option proto static
        option ipaddr 192.168.1.222
        option netmask 255.255.255.0
        option layer 1

config zone
        option name wan
        option network 'wan'
        option input REJECT
        option output ACCEPT
        option forward REJECT
        option masq 1
        option masq_dest '!modem'
        option mtu_fix 1

Just to verify the config is committed:

$ uci show network
…
network.modem=alias
network.modem.interface=wan
network.modem.proto=static
network.modem.ipaddr=192.168.1.222
network.modem.netmask=255.255.255.0
network.modem.layer=1
network.@zone[0]=zone
network.@zone[0].name=wan
network.@zone[0].network=wan
network.@zone[0].input=REJECT
network.@zone[0].output=ACCEPT
network.@zone[0].forward=REJECT
network.@zone[0].masq=1
network.@zone[0].masq_dest=!modem
network.@zone[0].mtu_fix=1

Please note:

* no changes to /etc/config/firewall
* nothing in /etc/firewall.user

On the router and from the PC, I can ping 192.168.1.222 - but that's the router itself, not the modem. (This IP does not show up in ifconfig - why not?)

I can neither ping nor telnet to 192.168.1.1, which is the modem, neither from the PC nor from the router.

I then add the two rules from the access.modem.through.nat howto, section "Raw iptables variant (required for pppoe setup)":

$ iptables -t nat -I postrouting_rule -s 192.168.33.0/24 -d 192.168.1.1 -j SNAT --to 192.168.1.222
$ iptables        -I zone_lan_forward -s 192.168.33.0/24 -d 192.168.1.1 -j ACCEPT

This does not change my inability to ping or telnet to the modem from either the router or my PC using either 192.168.1.1 or 192.168.1.222 . How is it supposed to work?

I am certain this is not an issue with the modem whose behaviour I tested when connected directly to the PC using DMT.exe, telnet and ping, and there are no problems in that constellation.

It is a routing/firewall issue, and I'd be glad if you could provide help - there's something I simply don't get.

Three posts that appeared related, which I found searching the forum:

2012-10-22 ADSL Modem Acces through WAN port
https://forum.openwrt.org/viewtopic.php?id=40068

2011-06-03 SNAT problem / Can not reach the dsl modem
https://forum.openwrt.org/viewtopic.php?id=30295

2012-09-10 Strange firewall behaviour
https://forum.openwrt.org/viewtopic.php?id=39267

Thanks.

(Last edited by Eumel71 on 13 Nov 2012, 16:01)

I traced the packet till here:

root@TIBERIUS: ~ > iptables -S zone_lan_forward
-N zone_lan_forward
-A zone_lan_forward -p tcp -m tcp --dport 23 … -j LOG --log-prefix "#> f.zone_lan_f** "
-A zone_lan_forward -s 192.168.33.0/24 -d 192.168.1.1/32 -j ACCEPT  <== accepted here
-A zone_lan_forward -p tcp -m tcp --dport 23 … -j LOG --log-prefix "#> f.zone_lan_for "
-A zone_lan_forward -j zone_wan_ACCEPT
-A zone_lan_forward -j forwarding_lan
-A zone_lan_forward -j zone_lan_REJECT
-A zone_lan_forward -p tcp -m tcp --dport 23 … --log-prefix "#< f.zone_lan_for "

So what does that mean, ACCEPT the packet here? Man page says "ACCEPT means to let the packet through." Through to were? I have generated and inserted the same LOG rules into the

nat

table and nothing from that table shows up in the log, so my conclusion is the packet isn't going there.

My trace log for one telnet attempt from my PC to the modem is like this (irrelevant parts snipped):

01:22:18: [39304.630000] #> n.PREROUTING   IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.650000] #> n.prerouting_r IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.670000] #> n.nat_reflecti IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.690000] #< n.nat_reflecti IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.720000] #< n.prerouting_r IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.740000] #> n.zone_lan_pre IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.760000] #> n.prerouting_l IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.780000] #< n.prerouting_l IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.800000] #< n.zone_lan_pre IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.820000] #< n.PREROUTING   IN=br-lan OUT= MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=128 ID=12517 DF
01:22:18: [39304.840000] #> f.FORWARD      IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12517 DF
01:22:21: [39307.650000] #> f.FORWARD      IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.670000] #> f.forwarding_r IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.690000] #> f.nat_reflecti IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.710000] #< f.nat_reflecti IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.730000] #< f.forwarding_r IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.750000] #> f.forward      IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:21: [39307.780000] #> f.zone_lan_f** IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=52 ... TTL=127 ID=12519 DF
01:22:27: [39313.670000] #> f.FORWARD      IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.690000] #> f.forwarding_r IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.710000] #> f.nat_reflecti IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.730000] #< f.nat_reflecti IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.750000] #< f.forwarding_r IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.780000] #> f.forward      IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF
01:22:27: [39313.800000] #> f.zone_lan_f** IN=br-lan OUT=pppoe-wan MAC=... SRC=192.168.33.152 DST=192.168.1.1 LEN=48 ... TTL=127 ID=12536 DF

I think this means the telnet packages are routed out to the Internet … ?

By the way, I read about the iptables TRACE facility and its non-availability in OpenWrt.

Debugging rules in Iptables - Server Fault
http://serverfault.com/a/126078/67956

iptables TRACE problems (Page 1) — General Discussion — OpenWrt
https://forum.openwrt.org/viewtopic.php … 39#p151839

The iptables-debug is not available in binary builds as enabling it slows down all iptables operations, even if not used. … You must compile yourself.

I wrote a script to generate LOG rules as a poor man's TRACE utility:

-- Regeln fuer iptables (TRACE fuer Arme)
-- iptables        -S | grep ^-[PN] | cut -d\  -f2 | lua iptrace.lua filter
-- iptables -t nat -S | grep ^-[PN] | cut -d\  -f2 | lua iptrace.lua nat

function printcmd(tbl, chn, crit, is_insert)
        switch = is_insert and "-I" or "-A"
        marker = is_insert and "#>" or "#<"
        prefix = string.format("%s %s.%s", marker, tbl:sub(0,1), chn)
        print(string.format(
                "iptables -t %-6s %s %-20s %s -j LOG --log-prefix '%-17s '",
                tbl, switch, chn, crit, prefix:sub(0,17))) -- 27
        -- iptables v1.4.10: Maximum prefix length 29 for --log-prefix
        -- Schneidet logread die Zeile ab?
end

tbl = arg[1]
if not tbl then error("table name missing, must be first argument") end

-- iptables packet match criteria
crit = arg[2] and arg[2] or "-p icmp"

repeat
        chn = io.read()
        if chn then
                printcmd(tbl, chn, crit, true)
                printcmd(tbl, chn, crit, false)
        else
                break
        end
until false

Must have been done before but maybe it is useful or inspiring to somebody … My first Lua script ever …

The discussion might have continued from here.