Routing priority issues I can't solve

Discussion in 'Linux Networking' started by Dirk Stöcker, Nov 26, 2014.

  1. Hello,

    I have a set of devices, which support PPP over serial port to access
    telnet on them.

    All of these have the same IP address 192.168.0.32. Now I have a script
    which is based on iptables/ip, which matches each of these PPP connections
    to a 10.0.x.1 address. It uses "-j MARK" for tracking and then related
    routing rules to assign these to the ppp device. This works fine.

    Now I have a new task - I want to access these addresses external as well
    with the addresses 192.168.0.101...192.168.0.120 and 192.168.0.32 also.

    Now my problem:
    - This works fine for 192.168.0.1xx addresses when I have a dhcp server
    setup for eth0 in the area 192.168.1.x.
    - It no longer works when I change DHCP to static 192.168.1.2.
    - It does not work with my static target address 192.168.0.2.
    - I want 192.168.0.32 addressable external, but adding this breaks
    everything as with the previously working setup.

    Does anybody have some hints what I need to do?

    I want
    192.168.0.2 as the external static address of the system (eth0)
    192.168.0.32 as external address passed to ppp0 and answers going back out
    192.168.0.101 as external address passed to ppp0 and reverse
    192.168.0.102 and more going to ppp1 and more

    I think the routing rules I have prefer the addresses on eth0 instead my
    marked table and thus it does not work.

    Can I increase priority of my own table or decrease priority of the static
    assigned addresses of eth0?

    Any possible outside devices will have 192.168.0.1 and 192.168.0.2xx.

    Please help me. Everything I tried till now failed.

    I currently use following commands (for ppp1, the first device):

    ----
    # make it work at all
    echo 1 >/proc/sys/net/ipv4/ip_forward
    echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter

    DNAT:
    # old local working rule
    iptables -t nat -A OUTPUT -d 10.0.0.1 -j DNAT --to 192.168.0.32
    # new local access rule
    iptables -t nat -A OUTPUT -d 192.168.0.101 -j DNAT --to 192.168.0.32
    # new rule for external requests
    iptables -t nat -A PREROUTING -d 192.168.0.101 -j DNAT --to 192.168.0.32

    MARKS:
    # old working mark
    iptables -t mangle -A OUTPUT -d 10.0.0.0/24 -j MARK --set-mark 100
    # new local access rule
    iptables -t mangle -A OUTPUT -d 192.168.0.101 -j MARK --set-mark 100
    # new rule for external requests
    iptables -t mangle -A PREROUTING -d 192.168.0.101 -j MARK --set-mark 100

    SNAT:
    # set source to 192.168.0.33 (i.e. the server side of PPP connection)
    iptables -t nat -A POSTROUTING -d 192.168.0.32 -m mark --mark 100 -j SNAT --to 192.168.0.33

    ROUTING:
    #old
    ip route add default dev ppp1 table 100
    ip route add -net 10.0.0.0/16 eth0
    ip route add 10.0.0.0/24 dev ppp1
    ip rule add fwmark 100 lookup 100
    #new
    ip addr add 192.168.0.101/24 dev eth0
    ----

    Existing routes: ip route show
    ------------------------------
    default via 192.168.1.1 dev eth0 proto dhcp
    10.0.0.0/24 dev ppp10 scope link
    10.0.0.0/16 dev eth0 scope link
    192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.101
    192.168.0.32 dev ppp10 proto kernel scope link src 192.168.0.33
    192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25
    DEV PPPD Table 100 : default dev ppp10 scope link

    Ciao
     
    Dirk Stöcker, Nov 26, 2014
    #1
    1. Advertisements

  2. Hello,

    Seems parts of my problems have been caused by too much testing. Only the
    main problem remains. I'll quote my last mail, so that the description
    stays complete.
    My set of problems reduced to one: When I add 192.168.0.32 as address to
    the eth0 device, I can't reach the 192.168.0.32 from my PPP connections
    anymore. The local address seems to have precedence over my routing rules.
    Ciao
     
    Dirk Stöcker, Nov 27, 2014
    #2
    1. Advertisements

  3. Of course. Taht has nothing to do with your routing rules but the other
    things (switches/routers) on the network. Remember how an address works.
    It is used to send the packets around, and when they get to the local
    network, as determined by the switch, they are sent via the MAC address,
    not by the IP address. Thus the router must know what the link is
    between address and MAC which it gets by first knowing what the subnet
    address is of all the machines on the local net, and then sending out
    "whois" requests. You cannot suddenly put yourself onto a different
    subnet that everything else does not know about.
     
    William Unruh, Nov 27, 2014
    #3
  4. There is no router or any external network component involved. The
    external address 192.168.0.32 is fine and works for itself. The secondary
    192.168.0.32 are all attached using a PPP connection over serial, so never
    visible to the LAN.

    Problem is only kernel internal. When sending to 192.168.0.32 it should
    not have the address assigned to the eth0 with first priority, but parse
    my routing rules first, so assignment to the different interfaces works
    like it does when I only use the 192.168.0.101 addresses.

    Actually I don't even need the address 192.168.0.32 assigned to eth0 at
    all. It would be enough when everybody else in the network would assume it
    is there. So when I can replace "ip addr add" with something like
    "reliable ARP spoofing" (i.e. answer to requests for 192.168.0.32) it
    would be fine, as then the rest of my rules would work as they are now.

    Ciao
     
    Dirk Stöcker, Nov 28, 2014
    #4
  5. Dirk Stöcker

    detha Guest

    Having the same address on multiple interfaces is asking for trouble. As
    you have discovered.
    What you are seeing is the lookup in the local table. 'ip rule list' will
    probably have something like '0: from all local' in it. So all lookups are
    done starting with the local table, and adding an address to an interface
    automatically adds a rule for that address to this local table. Your rules
    sit at priority 100, somewhere between local and main (which defaults to
    32766)

    You /could/ manually remove that rule, and it might work. Until the
    interface goes down/up for whatever reason.
    I don't know the surrounding network, but I would be running the network
    that eth0 is attached to on a different range (i.e. not 192.168.0.0/24).
    Then, adding a route to 192.168.0.0/24 via <ip of this host> on other
    machines should make things work, without the need for ARP tricks.

    -d
     
    detha, Nov 29, 2014
    #5
  6. I know, but sometimes you need to use what you have :). This a special
    purpose system, and nothing which will be used in normal environments.
    I'll try. Interface up/down is under control and nothing I need to care
    about.
    Yes. That would make things easier. Another idea would be to use this host
    as default gateway and pass any nonrelevant communcation through it. But
    first I'll try and see if I can get rid of the local rule.

    Ciao
     
    Dirk Stöcker, Dec 1, 2014
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.