6 ms·

> nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.8 -- rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12 Why is Linux accepting packets coming f

> nping --tcp --flags SA --source-ip 192.168.12.1 --dest-ip 10.8.0.8 -- rate 3 -c 3 -e ap0 --dest-mac 08:00:27:9c:53:12 Why is Linux accepting packets coming from one interface into an IP address belonging to a different interface? It feels like it is "forwarding" the packets internally, but `ip_forward` is turned off. Is there any case where this behavior is legitimately useful?

ajross 7y ago
IP addresses don't "belong" to interfaces in the general case. It's just a hard problem. In fact there are lots of multi-homed use cases where you want to internally route packets across interfaces without an affirmative mapping of what address is supposed to be used where. For the specific case of point to point VPNs, there's a rule that makes sense. But that's not part of the network stack per se and there's no way to enforce it generically.
- loeg 7y ago
  Do network stacks drop 127.0/8 packets from external interfaces today? Superficially (I'm not an experienced TCP/IP or routing stack developer, although I do work in the kernel) it seems like the same treatment could be used for VPN-registered interface addresses. You just need an API to specify "I'm a VPN interface" when the device is created or the IP assigned, no?
- arielb1 7y ago
  Is there a place where I can read about these cases?
loeg 7y ago
From the referenced systemd commit, > such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).
- arielb1 7y ago
  How is this supposed to work? How will the packet destined to the WiFi IP address get to the Ethernet interface?
  - loeg 7y ago
    The kernel internally routes it to the logical IP address. Since it's an internal address, the packet never goes down to the NIC.
    - arielb1 7y ago
      What's the configuration you're talking about? In the Wifi+Ethernet case, how do the routers know to send the packets towards the "right" interface, without the computer having the "right" IP address? I mean, suppose the computer has WiFi IP address 10.0.0.3 & Ethernet IP address 10.0.0.5, then after NAT the return packets will go to 10.0.0.3, and therefore should go to the WiFi interface, not to the Ethernet interface (or, if they don't, how do they know which interface they should go to?).
      - inetknght 7y ago
        > how do the routers* know to send the packets towards the "right"* The described attack utilized a malicious router. I imagine, in theory, that any middle router (such as your ISP) could then be used for such an attack. Imagine Comcast being able to inject their garbage [0] into even VPN sessions. Or a government actor that Comcast is known to route for. [0]: https://tools.ietf.org/html/rfc6108 https://tools.ietf.org/html/rfc6108
      - arielb1 7y ago
        > The described attack utilized a malicious router. I understand how cross-interface packets can be used maliciously. I'm just trying to figure out the non-malicious use cases for them.
        zrm 7y ago
vetrom 7y ago
I use this behavior in production systems where I have 'well-known' RFC1918 addresses I use for service bootstrapping/configuration. In the network engineering world, extra loopback interfaces are also used for similar reasons.

ajross 7y ago

IP addresses don't "belong" to interfaces in the general case. It's just a hard problem. In fact there are lots of multi-homed use cases where you want to internally route packets across interfaces without an affirmative mapping of what address is supposed to be used where. For the specific case of point to point VPNs, there's a rule that makes sense. But that's not part of the network stack per se and there's no way to enforce it generically.

loeg 7y ago
Do network stacks drop 127.0/8 packets from external interfaces today? Superficially (I'm not an experienced TCP/IP or routing stack developer, although I do work in the kernel) it seems like the same treatment could be used for VPN-registered interface addresses. You just need an API to specify "I'm a VPN interface" when the device is created or the IP assigned, no?
arielb1 7y ago
Is there a place where I can read about these cases?

loeg 7y ago

From the referenced systemd commit, > such as keeping connections via one default route alive after another one appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).

arielb1 7y ago
How is this supposed to work? How will the packet destined to the WiFi IP address get to the Ethernet interface?
- loeg 7y ago
  The kernel internally routes it to the logical IP address. Since it's an internal address, the packet never goes down to the NIC.
  - arielb1 7y ago
    What's the configuration you're talking about? In the Wifi+Ethernet case, how do the routers know to send the packets towards the "right" interface, without the computer having the "right" IP address? I mean, suppose the computer has WiFi IP address 10.0.0.3 & Ethernet IP address 10.0.0.5, then after NAT the return packets will go to 10.0.0.3, and therefore should go to the WiFi interface, not to the Ethernet interface (or, if they don't, how do they know which interface they should go to?).
    - inetknght 7y ago
      > how do the routers* know to send the packets towards the "right"* The described attack utilized a malicious router. I imagine, in theory, that any middle router (such as your ISP) could then be used for such an attack. Imagine Comcast being able to inject their garbage [0] into even VPN sessions. Or a government actor that Comcast is known to route for. [0]: https://tools.ietf.org/html/rfc6108 https://tools.ietf.org/html/rfc6108
    - arielb1 7y ago
      > The described attack utilized a malicious router. I understand how cross-interface packets can be used maliciously. I'm just trying to figure out the non-malicious use cases for them.
      - zrm 7y ago

vetrom 7y ago

I use this behavior in production systems where I have 'well-known' RFC1918 addresses I use for service bootstrapping/configuration. In the network engineering world, extra loopback interfaces are also used for similar reasons.