This is 100% expected behaviour. In order to route all traffic through your VPN connection, a default route is added with the virtual interface as a target. But this presents a problem - the network packets used to carry the VPN connection itself would also get routed to the VPN interface, creating a kind of routing loop. To resolve this a static host route to the VPN server is added using your normal Internet gatway as target. This way the packets created by OpenVPN could travel to the OpenVPN server over Internet while everything else gets directed over the VPN link.
Because of the host route, if you try to SSH to the Internet address of your VPN server, the connection will go over your regular Internet connection and you will see your IP in the output from
last. On the other hand, if you SSH to the other end of the VPN tunnel, your connection will appear to originate from the IP address assigned to the client's end of the tunnel.
For example, this is how a typical OpenVPN virtual interface is configured:
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.10.11.9 --> 10.10.11.10 netmask 0xffffffff
open (pid 48658)
The remote end of the VPN tunnel in this case is
10.10.11.10. This is a BSD-style
ifconfig output (actually OS X). The output on Linux is a bit different. And this is the corresponding host route (again in BSD format):
$ netstat -rn
Destination Gateway Flags Refs Use Netif Expire
0/1 10.10.11.9 UGSc 0 0 tun0
default 10.0.1.1 UGSc 22 0 en0
10.0.1/24 link#4 UCS 1 0 en0
10.10.11/24 10.10.11.9 UGSc 0 0 tun0
10.10.11.9 10.10.11.10 UHr 5 0 tun0
yy.yy.yy.yy/32 10.0.1.1 UGSc 1 0 en0
The first route directs all traffic (except the one directed to the local network
10.0.1/24) to the
tun0 interface, i.e. to OpenVPN. The static route to the OpenVPN server is the one on the last line.
10.0.1.1 in this case is the Internet gateway.