Hi Harald, > The laptop should be able to ping 10.19.96.156 again, but > 10.19.96.156 sends the echo reply to the "old" mac address > known from the wired connection to the roadwarrior. The > laptop can access other hosts in the 10.19.96.0/19 network, > if they hadn't been accessed via the cable network connection > before.
In a proper setup there is no "old" MAC address. What the farp plugin does is respond with the server's MAC address (presumably 80:ee:73:a2:e6:16) to ARP requests for IPs in remote traffic selectors (in your case the virtual IP 10.19.97.9 that's assigned to the client). So it doesn't matter how the client connects to the server or what virtual IP it gets assigned, the returned MAC address in ARP responses will always be the same. The same is not true for the client address in DHCP requests sent by the dhcp plugin, which are either based on the client's identity or random (that the same IP was assigned indicates the former). But that shouldn't matter. > How comes? The first ping from the "new" 10.19.97.9 should > have changed the arp table on 10.19.96.156, but obviously > it didn't. 10.19.96.156 sent the echo reply back to the > old MAC address of the roadwarriors wired network connection, > as it seems. That the internal server responded to the MAC address of the client's eth0 interface should never have been possible in the first place, because it shouldn't have been reachable on layer 2. However, your are doing this in some kind of test/home setup, that is, you are basically on-site with the IPsec gateway. That might have lead to this issue (ARP might have spilled into the network the client was connected to and since the IP is installed like any other it simply responded to it). That wouldn't be the case for actual roadwarriors that aren't close (in terms of layer 2) to your IPsec gateway. By the way, the status output of charon on the roadwarrior is irrelevant as you are using the NM plugin (which uses charon-nm as backend, not charon). Regards, Tobias