Christos Zoulas wrote: > | # ping -I 192.168.45.21 8.8.8.8 > | PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes > | 64 bytes from 8.8.8.8: icmp_seq=0 ttl=53 time=29.130956 ms > | ... > | > | 192.168.45.21 is my real LAN IP, while 192.168.0.213 was my VPN IP. > | The packet travels unenctypted over my usual private LAN gateway > | (192.168.45.254), which makes sense, as the policies affect packets > | from/to 192.168.0.213 only. > | > | So it is probably a matter of selecting the interface's alias or not. > | Currently it looks like the alias is always used, once it is present. > > Yes, since IPSEC is handled without an entry in the routing table, you
One entry was added for IPsec by the phase1-up script: Destination 1.2.3.4 (VPN-gateway) over Gateway 192.168.45.254 (my real default gateway). But further tests show that it is not required to keep IPsec working. Indeed, no modification of the routing tables is needed. > need to make source that things originate in the interface it expects. This works for ping(8) with -I. It even works for ssh(1) with -b. But usual tasks like using a web browser are still difficult. Somehow the default routing is confused, when IPsec is active. Sursprisingly I can make it work when adding additional routes for the addresses I want to access: Destination Gateway Flags Refs Use Mtu Interface default 192.168.45.254 UGS - - -L re0 8.8.8.8 192.168.45.254 UGHS - - -L re0 Looks stupid, but now pinging 8.8.8.8 works in parallel with IPsec. So the kernel seems to know that is has to use a 192.168.45.0/24 LAN source address to reach the gateway, but it does no longer work for the default route, where it prefers the alias. BTW, it doesn't seem to be a problem of the alias alone. I made a test with IPsec disabled and just added an alias. The default route still worked as intended! Is there already a PR about that? -- Frank Wille
