NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Routing in a VPN-Roadwarrior configuration



In article <47dfad1c759.761f2531%mail.owl.de@localhost>,
Frank Wille  <frank%phoenix.owl.de@localhost> wrote:
>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?

No please file one!

christos



Home | Main Index | Thread Index | Old Index