Avoiding dynamic IP address woes with a VPN

I’m sick of dealing with dynamic IP issues. My broadband connection at home has a dynamic IP address. I can always find out what my home IP address is. I’m using dns/noip to manage a hostname which points to home. I can always ssh home via the hostname.

The problems arise when I try to restrict access to services provided at home or access to services on external servers. For example, the web server upon which this blog is hosted allows incoming ssh only from a few select IP addresses, one of which is my home address. The webpages for The FreeBSD Diary and FreshPorts are stored in a cvs repository at home. The web servers access cvs through a secure channel provided by stunnel.

I have a nagios installation at home which monitors several servers on the Internet. These servers restrict incoming connections based upon IP address.

All the above services are affected when the IP address at home changes. In short, when the IP address changes, I need to update the following items on each server:

  • /etc/pf.conf – update the IP address of my home gateway
  • /etc/hosts – update the IP address
  • /usr/local/etc/nrpe.conf – allow hosts to connect from the outside
  • restart stunnel – ensure the stunnel over which cvs updates is restarted

Looking at this now, I see I could do away with the nrpe.conf change if I restrict incoming connections through pf.conf. However, in keeping with the Defense in Depth strategy, I should maintain that file.

The options I have considered are:

  1. status quo
  2. create a script to update the files
  3. VPN

I have discarded options 1 and 2. I am now seriously considering option 3.

How would a VPN be useful in this case?

I could create a VPN on which all my servers resided, both at home and at data centers around the world. This would completely negate any IP address changes. My web servers could then directly access my cvs repositories. Nagios could directly access the remote nrpe clients.

I think the best configuration is creating a VPN service on each colocated server. The network at home would then connect to each service. This would be a star arrangment with one connection from home to each server. I had considered one VPN ihosted on one of the servers. But this would require traffic from NY to travel to Austin before heading to Pennsylvania (or similar). No, to avoid length transits each remote server should have it’s own connection.

Why don’t I go with a static IP address? Cost. I’d need to get a business account and that would be +$80.00 a month. No thank you.

Any comments?

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive

8 thoughts on “Avoiding dynamic IP address woes with a VPN”

  1. The major problem so far with using a VPN that is initiated from my home server is that the remote servers need to access the servers at home. In that sense, the setup is reversed. Usually, the OpenVPN client can access the network at the Server. In this case, I want it the other way around. Perhaps I need to rethink this solution.

  2. Why not put the VPN server on one of the dedicated servers in one of the data centers? If I do that, then I’ll have traffic going from one server to the VPN server to $HOME. When it just really needs to go $HOME. All the servers out there just need to contact $HOME over the VPN. nobody else.

  3. If you trust DNS resolution, you can just use the hostname in your pf
    ruleset. With one caveat – it only will be updated when the ruleset is
    loaded. I’ve worked around this scenario by using dyndns names and
    reloading pf rules from cron. If your IP changes very frequently, that
    might not be a suitable solution. Depending on how much the IP changes
    entire subnets (maybe stays within a /21 or something), it may be easy to just
    allow that subnet, or all the IP blocks assigned to your ISP. That’s
    significantly better than allowing the entire Internet, though not
    ideal.

    OpenVPN would be a good solution, as it’s more dynamic IP
    friendly than other VPN options. Setup an OpenVPN server on each of
    your servers, and configure your home firewall/gateway with OpenVPN client
    connections to each. That will give you always on site to site connectivity,
    with routing in both directions. It will need to reconnect when your IP changes.
    pfSense will do this automatically, if you’re running a custom built BSD box,
    there are ways to tie a reconnect into scripts with dhclient, mpd, whatever
    you use to pull your public IP.

  4. Chris: Have you considered a table for that IP address? That way, you can just reload the table instead of the whole rule set. Much like this:

    pfctl -t spamd-mywhite -T replace -f /usr/local/etc/spamd-mywhite

    instead of this:

    pfctl -f /etc/pf.conf

  5. It became useful first to distinguish among different kinds of IP vpn based on the administrative relationships, not the technology, interconnecting the nodes. Once the relationships were defined, different technologies could be used, depending on requirements such as security and quality of service.

Leave a Comment

Scroll to Top