When connecting to a VPN you may have a DNS server which serves split horizon for a particular domain. For example when connected to your companies VPN, your local DNS config in /etc/resolv.conf is updated with:

nameserver 192.168.1.1

The DNS server 192.168.1.1 is your companies internal DNS server which resolves admin.example.org to 192.168.1.100. You need to access admin.example.org on 192.168.1.100 but don’t necessarily want to have all DNS queries go to 192.168.1.1. You also don’t want manage /etc/hosts entries which can become stale over time.

Security Warning

It’s important that you trust the server that you are connecting to before changing the default StrictHostKeyChecking & UserKnownHostsFile options. All an attacker would need to do is poison your DNS and import your SSH public key to fake what you would expect to be the server you are connecting to.

192.0.2.0/24 – This block is assigned as “TEST-NET-1″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.
…
198.51.100.0/24 – This block is assigned as “TEST-NET-2″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.
…
203.0.113.0/24 – This block is assigned as “TEST-NET-3″ for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation.

So next time you write some documentation, create a diagram or reference a network in example code consider using one of the networks in RFC5735.