How to route via eth1?

Software SW help
1

Hi there,

I have a turris omnia with Turris OS 3.11.16.

I bought a DSL Modem and put it in Bridgemode, connected the ethernet side to the WAN of the omnia port and the other side to my provider.
The Turris does pppoe via eth1.7. Up to here everything ist working fine.

The DSL Modem has an administration interface. I bound it to 192.168.2.1. To be able to comfortably configure the modem, I assigned 192.168.2.2 to eth1 of the Turris, lets call it ‘mgmt’ and added a forwarding from zone ‘lan’ (192.168.1.0/24) to zone ‘mgmt’ (192.168.2.0/24).

For some reason, I do not get the routing to work properly.

  • I can access 192.168.2.1 (DSL Modem) from the turris (192.168.2.2), that’s fine
  • I cannot access 192.168.2.1 from any host in 192.168.1.0/24 (lan), which is odd

So how to get the routing working?

What I tried:
/etc/config/network

config interface 'mgmt'
    option ifname 'eth1'
    option proto 'static'
    option ipaddr '192.168.2.2'

/etc/config/firewall

config zone
    option name 'mgmt'
    list network 'mgmt'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option mtu_fix '1'

config forwarding
    option src 'lan'
    option dest 'mgmt'
    option name 'lan-to-mgmt-forward'

Any Ideas, what I am missing?

Thanks in advance

2

Packets from the O’s clients need to be routed to 192.168.2.1 and require a gateway. Perhaps check the O’s routing table with

  • ip -d r, a/o
  • route -ne, a/o
  • netstat -rne
3

For me this looks good so far:

root@turris:~# ip -d r
unicast default via <WAN PEER IP> dev pppoe-wan  proto static  scope global 
unicast <WAN PEER IP> dev pppoe-wan  proto kernel  scope link  src <WAN IP>
unicast 192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
unicast 192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.2 
root@turris:~# route -ne
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         <WAN PEER IP>   0.0.0.0         UG        0 0          0 pppoe-wan
<WAN PEER IP>   0.0.0.0         255.255.255.255 UH        0 0          0 pppoe-wan
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
root@turris:~# netstat -rne
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         <WAN PEER IP>   0.0.0.0         UG    0      0        0 pppoe-wan
<WAN PEER IP>   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

The client’s default route points to 192.168.1.1 (the omnia), which is of course also selected for as route from 192.168.1.0/24 to 192.168.2.0/24. A traceroute from the client shows this:

⋊> ~ traceroute -n  192.168.2.1                                                                                                                                                                                 
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  192.168.1.1  0.821 ms  0.756 ms  0.873 ms
 2  * * *
 3  * * *
 <repeating * * * but not reaching the target>

Maybe also interesting. This is a traceroute from a client in the LAN to the omnias interface in 192.168.2.0/24, which also works. So this look also fine for me.

⋊> ~ traceroute -n 192.168.2.2
traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 60 byte packets
 1  192.168.2.2  0.956 ms  0.890 ms  0.861 ms
4

On the O try

  • ip r add 192.168.2.0/24 dev eth1, or
  • ip r add 192.168.2.0/24 via 192.168.2.2
5

Tried that, but it did not change anything. Actually both routes existed before:

root@turris:~# ip r add 192.168.2.0/24 dev eth1
RTNETLINK answers: File exists
root@turris:~# ip r add 192.168.2.0/24 via 192.168.2.2
RTNETLINK answers: File exists
6

Likely not going to remedy the matter but nonetheless remove (and afterwards restart firewall)

since it is only necessary for the xDSL upstream connectivity on the WAN interface.

You could also try:

  • enable firewall logging for the mgmt zone and see in the logs whether anything gets blocked

  • to eliminate the firewall as cause:

    • stop the firewall (which should flush the rules) and as a precaution flush the rules
      fw3 stop ; fw3 flush

    :warning: recalled though that in the past this caused loss of connectivity with the O (by design)

    not sure whether that still happens since departed from TOS3.x and IPTables long ago

  • delete the mgmt zone and assign an IP from the 192.168.1.0/24 subnet to the DSL Modem administration interface

7

Exactly this, I want to avoid, because the modem is a bridge. Putting it into the same subnet will basically make my LAN exposed on the provider side. Actually, that was my initial setup, which I now want to change.

However, stopping the firewall and flushing iptables, does not change anything. Still no connection from lan to mgmt.

However, the following is interesting and suggests, that the modem does some magic to not reply:

root@turris:/etc/config# tcpdump -i eth1 -v 'src or dst 192.168.2.1'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
20:58:29.938632 IP (tos 0x0, ttl 63, id 26951, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.160.59404 > 192.168.2.1.443: Flags [S], cksum 0xadc2 (correct), seq 140625349, win 64240, options [mss 1460,sackOK,TS val 2889397811 ecr 0,nop,wscale 7], length 0
20:58:30.948518 IP (tos 0x0, ttl 63, id 26952, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.160.59404 > 192.168.2.1.443: Flags [S], cksum 0xa9d0 (correct), seq 140625349, win 64240, options [mss 1460,sackOK,TS val 2889398821 ecr 0,nop,wscale 7], length 0
20:58:30.963620 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.2, length 28
20:58:30.964073 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.1 is-at 00:1d:aa:97:f5:d0 (oui Unknown), length 46
20:58:32.996507 IP (tos 0x0, ttl 63, id 26953, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.160.59404 > 192.168.2.1.443: Flags [S], cksum 0xa1d0 (correct), seq 140625349, win 64240, options [mss 1460,sackOK,TS val 2889400869 ecr 0,nop,wscale 7], length 0
20:58:37.028537 IP (tos 0x0, ttl 63, id 26954, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.160.59404 > 192.168.2.1.443: Flags [S], cksum 0x9210 (correct), seq 140625349, win 64240, options [mss 1460,sackOK,TS val 2889404901 ecr 0,nop,wscale 7], length 0
20:58:45.412470 IP (tos 0x0, ttl 63, id 26955, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.160.59404 > 192.168.2.1.443: Flags [S], cksum 0x7150 (correct), seq 140625349, win 64240, options [mss 1460,sackOK,TS val 2889413285 ecr 0,nop,wscale 7], length 0

tcpdump says, the their is an arp-reply for 192.168,2.1 and a tcp handshake is tried. But the modem simply does not answer to anything but arp.

8

Whilst the bridge mode on the modem (DrayTek Vigor 130 ?) should eliminate NAT/Packet inspection on WAN connectivity there might be however firewall rules still in place for its (modem) LAN (zone)?

9

no special fw rules on the modem. The only thing, I could imagine, is that the modme lacks a route. But I have not found a place to make the omnia the default gateway of the modem.

Yes, your right, it is a Vigor 165

10

Ok, got it. It was indeend the routing table at the modem, that did not provide a route back to 192.168.1.0/24. It took me a while to figure out, how to configure this on the modem.

I just added a route

192.168.0.0/16 via 192.168.2.2

and it suddenly worked.