3 ms·

not op but one issue i have with it is that it ignores the routing table as soon the packet hits the interface. what i mean is if i tell the linux network stack

not op but one issue i have with it is that it ignores the routing table as soon the packet hits the interface. what i mean is if i tell the linux network stack to route packets "via" some address (which normally would involve arp) this configuration is completely ignored and the packet gets routed to whatever endpoint has the destination address as (confusingly named) AllowedIP address set. I expected it to do the lookup based on that via address and was trying to figure out what went wrong way too long. I think it would be kinda trivial to do this as i expected it after some minor research but that also led me to think it is supposed to be this way for some reason or another.

yokem55 6y ago
Yes, that's the normal behavior. If you have 172.16.10.0/24 that you are accessing via a wg peer at 172.16.1.10, then that peer needs to have both the 172.16.1.10/32 and the 172.16.10.0/24 in that peers allowedips. Then you can set a kernel route of 172.16.10.0/24 via 172.16.1.10 an the routing should work correctly.
- mercora 6y ago
  no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables. i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.
  - yokem55 6y ago
    Ahh. If you are using wg-quick, the the script automatically adds interface level routes to the routing table that would override any manual static routes. You could add a Table=off flag to the wg interface config, and then you won't have the automatically generated route table entries based on the AllowedIPs flags, and your manual routes will be respected.
    - mercora 6y ago
      i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).

yokem55 6y ago

Yes, that's the normal behavior. If you have 172.16.10.0/24 that you are accessing via a wg peer at 172.16.1.10, then that peer needs to have both the 172.16.1.10/32 and the 172.16.10.0/24 in that peers allowedips. Then you can set a kernel route of 172.16.10.0/24 via 172.16.1.10 an the routing should work correctly.

mercora 6y ago
no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables. i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.
- yokem55 6y ago
  Ahh. If you are using wg-quick, the the script automatically adds interface level routes to the routing table that would override any manual static routes. You could add a Table=off flag to the wg interface config, and then you won't have the automatically generated route table entries based on the AllowedIPs flags, and your manual routes will be respected.
  - mercora 6y ago
    i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).