I am replacing a private T1 link with a new firewall device with an ipsec tunnel for a branch office. I am trying to figure out the right way to transition folks at the new site over to the new connection, so that they default to using the much faster tunnel.

Existing network:, gw (Cisco router plugged in to private t1)

Test network I have been using with ipsec tunnel:, gw (pfsense fw plugged in to public internet), also plugged in to same switch as the old network.

There are probably ~20-30 network devices in the existing subnet, about 5 with static IPs. The remote endpoint is already the firewall--I can't set up redundant links to the existing subnet. In other words, as soon as I change the tunnel configuration to point to, all devices in the existing subnet will stop working because they point to the wrong gateway.

I'd like some ability to do this slowly--such that I can move over a few clients and verify the stability of the new link before moving critical services or less tolerant users over.

What's the right way to do this? Change the netmask on all of the devices to /16, and update gateway to point to the new device? Could this cause any problems? Also, how should I handle DNS? The pfsense box is not aware of my Active Directory environment. But if I change DNS to use the local servers, it will result in a huge slowdown as DNS queries will still be routed over the private t1. I need some help coming up with a plan that's not too disruptive but will really let me thoroughly test the stability of the IPSEC tunnel before I make the final switch.

The AD version is 2008R2, as are the servers. Workstations are mostly Windows XP SP3. I have not configured the as a site in AD sites and services.


The best way to migrate is to assign your users to different Vlans with addressing managed by DHCP; Vlans are required because you need a way to contain DHCP broadcasts within the boundary of your Cisco / pfSense FW. If you do not contain the DHCP broadcasts between these subnets, you will get chaos and unpredictable connectivity.

To accomplish this plan you need the following HW that wasn't explicitly mentioned in your question:

  • A switch that supports Vlans
  • A Central DNS / DHCP server

IPSec Migration

Configure the following items:

  • On the Cisco router:

    • Assume Eth0 is connected to your switch, the Cisco must support Vlan trunking
    • Interface Eth0.10 is (default gw for Vlan10)
    • Interface Eth0.30 is (transit subnet between pfSense / Cisco)
    • Default route to the HQ router
    • DHCP forwarding to on Eth0.10 (ip helper-address
    • Route to the pfSense LAN intf: ip route
  • On the pfSense FW

    • Assume Eth0 is connected to your switch, pfSense supports Vlan trunking
    • Interface Eth0.20 is (default gw for Vlan20)
    • Interface Eth0.30 is (transit subnet between pfSense / Cisco)
    • Default route to the HQ router via IPSec tunnel
    • IPSec configuration
    • DHCP forwarding to on Eth0.20
    • Route to the Cisco LAN intf via
  • HQ Router(s)

    • Route via the Cisco
    • Route via the pfSense IPSec tunnel
    • Route via the Cisco (for troubleshooting, just in case...)
  • On the HQ AD/DNS/DHCP server

    • DHCP Scope for
    • GW:
    • DNS:
    • DHCP Scope for
    • GW:
    • DNS:

After you have done this, Vlan10 (green) will pull DHCP in, and Vlan20 (pink) will pull DHCP in Vlan10 and Vlan20 will use as a transit subnet in case Vlan10 and Vlan 20 need to send traffic within that remote office (thus preventing a WAN delay for local intra-vlan traffic).

Anything that has a static address needs to use DNS to to be sure you get as seamless migration as possible between Vlan10 and Vlan20.

When you want to migrate people over to the pfSense IPSec connection, just put them in Vlan 20 on the ethernet switch; if they aren't happy for whatever reason, you can move them back to the T1 WAN by putting them in Vlan10.

  • I ended up just moving everybody over. The other solutions were not reliable enough or introduced too much complication. However, the VLAN option may have been the best one if I had a managed switch at this site. – Quinten Jul 4 '12 at 14:10
  • FYI, the printer addressed as in the diagram is a typo; the printer should be addressed as – Mike Pennington Jul 16 '12 at 17:29

Changing the subject to a /16 would create a massive broadcast range and probably cause new problems that would make it hard to diagnose how your new tunnel is performing.

It seems glaringly simple, but is there any reason why you can't add some policy routes on the Cisco to selectively route some IPs via the pfsense box rather than default gw?

Or again, probably too simple, but is there any reason you can't just add a second IP in the new range, to whatever machines are being tested, with a gateway of lower metric? Then they could access either subject simultaneously without complication?

  • While the maximum possible size of the broadcast domain will increase, the amount of broadcast traffic will stay the same unless a bunch of devices magically appear on the subnet. – MDMarra Jun 27 '12 at 19:30
  • True. I would guess it depends on if the remote network(s) on the tunnel is bridged (and thus shares the same subnet) or routed. Then it could mean more devices are present as a result. – Ben Lessani - Sonassi Jun 27 '12 at 19:36
  • I've just tried doing that (adding a secondary IP) and it seems to be pretty unstable. I'm not sure why, but it looks like Windows is changing which IP the traffic goes out over at regular intervals. Adding a route on the Cisco, assuming you mean in the existing subnet, won't work because once I update the tunnel on the main office side, it will route ALL traffic bound for over the tunnel, and won't route anything over the Cisco box. Maybe my only option is just to cut-over everybody at once. Good food for thought though. – Quinten Jun 27 '12 at 20:37
  • For the first option you could delete the route to the Cisco gw, but if the metric is lower on the other gw - it shouldn't consider routing through it anyway. For the second option, I specifically said policy route, not static route. Ie. You can conditionally forward based on source/destination IP. – Ben Lessani - Sonassi Jun 27 '12 at 21:05
  • I'll explore that. I'm also going to try keeping the dual IPs for a while on a test workstation and doing some availability monitoring. In order to make any changes on the remote router unfortunately I have to visit the site in person and hook up a serial cable. Remote management was never configured by my predecessor. – Quinten Jun 27 '12 at 21:28

I would go with Sonassi in terms of setting up a secondary range and then I would move one client over to it for testing. If you cant afford to totally reconfigure even one client then adding a static route and secondary IP to the client for your testing via the new gateway would allow you to leave it on the old network and test the new range.

  • There's no problem with moving over one client or a dozen to the new subnet--the issue is letting them access the local network resources as well as the remote and Internet resources once I've done that. – Quinten Jun 27 '12 at 20:41
  • Keep them on both ip ranges by configuring it as a secondary range then, and use specific routing configurations if necessary to force remote network traffic to use the new gateway. this can be done with the 'route add' command from the command prompt on xp, I'm not currently on a pc so can't give you the exact syntax, I'm pretty sure its 'route add -p' where is the remote range. You can check the syntax from the command prompt with 'route /?' – Sam Jun 27 '12 at 21:19
  • @sam, the far end will still try to route back over the T1 – quadruplebucky Jul 3 '12 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.