Join Log in
Score:-1
Maxim Khokhryakov avatar Server

Why does this routing setup not working

cn flag
Maxim Khokhryakov

I have two interfaces on server machine. The output of ip route is next:

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

and ip address is next (MACs are hidden):

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

The /proc/sys/net/ipv4/ip_forward value is 1; firewall is disabled.

That I want is to access 192.168.100.1 from 10.8.0.100. Accessing web-server (which is listening all ports on this machine) through curl --interface 10.8.0.100 http://10.8.0.1 works fine. But curl --interface 10.8.0.100 http://192.168.100.201 output is Network unreachable.

Curl initiates an tcp handshake and push packet to 10.8.0.100 interface. The packet then reaches server machine on 10.8.0.1. The server looks into packet dest and sees that it is 192.168.100.201. Then it look into routing table and sees that 192.168.100.201 is local. Now the answer is going back. The sender was 10.8.0.100. Looking to the routing table we can found that it accessible through tap0, which is local. So now it pushes into tap0 and reaches 10.8.0.100.

But actually - it isn't. Is this because my train of thought is wrong? I thought that the information provided by described table is enough to determine how to forward packets. Is this actually incomplete?

124
1 + 0
Score:1
avatar Server
np flag
NStorm

First of all, supplying IP address & interface with -I parameter to the ping aren't synonyms. First tells which source IP to pick. It will route it according the net flow, including local addresses & routing tables. Second tells to directly pick the interface to send packet to (and it will pick first assigned IP as the source).

Next what are you doing has nothing to do with packet forwarding. Forwarding means that the packet has to actually arrive from the "outside". As you are generating a packet from this host there is no forwarding involved. It's a locally generated packet. As your destination IP are one of the locally assigned addresses when you aren't forcing ping to send packet to a specific interface "outside" (with -I interface option) kernel will process this packet flow internally. It just won't try to output it to a real interface as it's destination are "already here". So this is what happens and why it works in one case and not in another.

PS: Also check out the -r option of the ping tool in case you know that you're doing and both interfaces are attached to a same broadcast domain (I doubt this with the TAP interface).

0 + 6
Maxim Khokhryakov avatar
cn flag
Maxim Khokhryakov
That i really want is to access `192.168.100.1` from `10.8.0.100` So the route will be next: 10.8.0.100 --ip--> 10.8.0.1 --kernel-->192.168.100.201-->ip --> 192.168.100.1.
0
Reply
np flag
NStorm
Then you have to add a route on the `10.8.0.100` to the `192.168.100.0/24` through `10.8.0.1` (your router) and similar backwards route on the `192.168.100.1`. And ping from there (`10.8.0.100`). That are you trying to do now is to ping router from the router.
2
Reply
Maxim Khokhryakov avatar
cn flag
Maxim Khokhryakov
the problem is that i can't add any routes on 192.168.100.1. And the more important problem is that i can't understand why this config not work. Let's execute this command on 10.8.0.100: `ping -I 10.8.0.100 192.168.100.201`. This should create an ICMP packet, push it to 10.8.0.100 interface and deliver to 10.8.0.1. 10.8.0.1 should forward it to 192.168.100.201 (cuz they both on same machine). But it doesn't! `ping -I 10.8.0.100 10.8.0.1` works fine, so the problem is definitely lies between 10.8.0.1 and 192.168.100.201, i.e. in routing table.
0
Reply
np flag
NStorm
@MaximKhokhryakov does the `10.8.0.100` has `10.8.0.1` as the default route? You didn't mentioned it. "10.8.0.1 should forward it to 192.168.100.201 (cuz they both on same machine)" - it's not a forwarding as I've already told. The problem is that the packet reaches machine on the `tap0` interface, while the destination IP are on the `enp1s0`. Most likely kernel drops those packets due to `rp_filter`. Try to disabling it by doing `sysctl -w 'net.ipv4.conf.all.rp_filter=0'`
0
Reply
np flag
NStorm
@MaximKhokhryakov also, does the `192.168.100.1` has the `192.168.100.201` listed as the gateway? If not, you have to configure NAT on the `192.168.100.201` or you won't be able to reach `192.168.100.1` from the `10.8.0.1` as first won't be knowing how to route packets back to 10.8.0.0/24.
0
Reply
np flag
NStorm
Also, you can try doing `ping -r -I 10.8.0.100 192.168.100.201` from `10.8.0.100`.
0
Reply
Score:0
Maxim Khokhryakov avatar Server
cn flag
Maxim Khokhryakov

The problem was with misunderstanding of difference between --interface IP and --interface dev. The first one uses routing table:

with --interface 10.8.0.100 the packet will not be forwarded to tap0 interface (which this ip belongs to). Instead, according to routing table it will be forwarded to 192.168.100.58 (the lan interface). So the route is 10.8.0.100 -> 192.168.100.58 -> 192.168.100.201. Even the fact that SYN was delivered, the server strangely will not respond with SYN-ACK - that's the reason of curl fail.

Using --interface tap0 i.e. link layer address it will be work as intended: 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201. The SYN-ACK will be delivered back using the same route.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.