1

I'm trying to set up a Ubuntu-based gateway between clients and the core router, the ideal traffic flow should be:

ClientGroup 1 (10.0.0.0/24) -> Ubuntu gateway (10.0.0.2) -> Core router (10.0.0.1) -> Internet

ClientGroup 2 (10.0.1.0/24) -> Ubuntu gateway (10.0.1.2) -> Core router (10.0.1.1) -> Internet

ClientGroup 3 (10.0.2.0/24) -> Ubuntu gateway (10.0.2.2) -> Core router (10.0.2.1) -> Internet

Clients use Ubuntu instance as their gateway.

The following netplan configuration routes internal traffic properly, however for Internet traffic, it defaults to eth0.1 (10.0.1.1) because of gateway4.

network:
    version: 2
    ethernets:
        eth0:
            addresses: [10.0.0.2/24]
            routes:
                - to: 10.0.0.0/24
                  via: 10.0.0.1
                  table: 101
            routing-policy:
                - from: 10.0.0.0/24
                  table: 101
            dhcp4: false

    vlans:
        eth0.1:
            id: 1
            link: eth0
            addresses: [10.0.1.2/24]
            gateway4: 10.0.1.1
            routes:
                - to: 10.0.1.0/24
                  via: 10.0.1.1
                  table: 102
            routing-policy:
                - from: 10.0.1.0/24
                  table: 102
            dhcp4: false


        eth0.2:
            id: 2
            link: eth0
            addresses: [10.0.2.2/24]
            routes:
                - to: 10.0.2.0/24
                  via: 10.0.2.1
                  table: 103
            routing-policy:
                - from: 10.0.2.0/24
                  table: 103
            dhcp4: false

Any ideas on how to route all traffic to its corresponding next-hop on the core router? Namely, all traffic (0.0.0.0/0) from 10.0.0.0/24 should be routed to 10.0.0.1 whereas 10.0.2.0/24 should be routed to 10.0.2.1.

I'm happy to use plain ip route rules as well.

Thanks in advance!


Edit 13/05/20:

I have added a default route to each routes, the routing is working as expected but traceroute output seems weird:

routes:
  - to: 0.0.0.0/0
    via: 10.0.0.1
    table: 101

1st test:

traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  10.0.0.2 (10.0.0.2)  0.896 ms * *
 2  10.0.0.1 (10.0.0.1)  1.361 ms  1.126 ms  0.879 ms

2nd test:

traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  * * *
 2  10.0.0.1 (10.0.0.1)  1.353 ms  1.062 ms  0.825 ms
GreenVine
  • 23
  • 3

1 Answers1

0

Easy enough, particularly since you're already using multiple routing tables:

(Sorry, didn't convert my example to netplan; but since you're game to use regular ip route rules, it should suffice - and this example assumes you're starting from scratch)

So, your netplan is already creating three routing tables, so we'll use the first routing table you have:

ip route flush 101
ip route add table 101 to 10.0.0.0/24 dev eth0
ip route add table 101 to default via 10.0.0.1

And the third routing table you have:

ip route flush 103
ip route add table 103 to 10.0.2.0/24 dev eth0.2
ip route add table 103 to default via 10.0.2.1

Then create two rules to send traffic to each table based on the traffic's source IP address:

ip rule add from 10.0.0.0/24 table 101 priority 101
ip rule add from 10.0.2.0/24 table 103 priority 103

This should do it. Note that you can keep adding destination routes to the two tables and only traffic from the associated sources will hit those entries - enough of those and you may choose to remove the default routes on each table.

Omar Buhidma
  • 348
  • 1
  • 8
  • Thanks heaps, I have followed your advice and the routing seems working as expected. However `traceroute` no longer works. Could you please check out my updated post? – GreenVine May 13 '20 at 13:34
  • I did. To be honest, that's more appropriate to a whole new question, not an edit on an existing question - likely it's as much about the configuration on the receiving end of your traffic as it is about the router we just configured. Given all the details you're going to need to provide to answer your "edit" (sysctl output on all involved nodes, route config on the receiving end, etc), the approoriate approach will be to accept my above answer (since it solved your first issue) and create a new question for your new problem – Omar Buhidma May 13 '20 at 14:32