Re: Routing in a VPN-Roadwarrior configuration

[christos%zoulas.com@localhost (Christos Zoulas)]

On Mar 17,  2:15pm, frank%phoenix.owl.de@localhost (Frank Wille) wrote:
-- Subject: Re: Routing in a VPN-Roadwarrior configuration

| Christos Zoulas wrote:
| 
| > I knew someone would eventually discover this... Yes, things don't
| > work very well on the machine that has the IPSEC endpoint.
| 
| Indeed. I also noticed that traceroute(8) doesn't work, even when the
| destination is a perfectly accessible host from the VPN LAN.
| 
| 
| > I meant to debug this too but it was not very important to me to spend
| > the time so far :-)
| 
| Of course it would we great to get this working, since we already fixed so
| many IPsec related issues during the last days. It's nearly perfect now! ;)
| 
| 
| > Using ping -I to select the source address should work, but it seems
| > that it does not (last time I tried it).
| 
| It can confirm that it does work.
| 
| # 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 need
to make source that things originate in the interface it expects.

christos