PfSense Based OpenVPN on top of Existing MPLS WAN
Im in a confusing spot. We have an existing MPLS based WAN running on just bonded T1s with four locations.
People want way more speed, but the MPLS service provider can only give us more T1 lines.
Each office has high speed cable (Comcast) for internet connections via proxy server. These connections are about 120Mb/20Mb up, so WAY faster than 3Mb/3Mb.
To solve the performance issues I would like to setup a pfSense based OpenVPN WAN using the Comcast connections.
I have actually setup a working OpenVPN connection between one remote office and our HQ using Comcast on
one endboth ends to test, and it works, sort of.
1. When I setup a remote system to use the new pfSense gateway I can see servers at HQ but data transfers are all wonky, and Outlook's connection to the Exchange server (in HQ) drops out then reconnects constantly… UNLESS I change the HQ servers to use the pfsense gateway in which case no other location could reach it, unless I setup static routes to those subnets on every server. I assume this is normal since sending and receiving gateways are different, right?
Works, but Poorly: Remote Office -> pfsense GW -> HQ -> MPLS WAN GW -> Remote Office
Works Perfectly: Remote Office -> pfSense GW -> HQ -> pfSense GW -> Remote Office
2. If so, is there no way to transition one office at a time to the new pfsense WAN, or is it all or nothing?
How about a little different variant - is there any way to feed the MPLS connection into pfsense along with the Comcast?
This would give you a dual WAN setup that could be configured to route specific traffic (Outlook, etc.) via MPLS and everything else via Comcast.
It'll take another NIC in the pfsense box, but it should give you ultimate control over how and where traffic is routed.
Thanks for the reply. I can indeed do that but the underlying problem still remains with the transition. I am transitioning from one gateway to another. I think the packets dont like going out via pFsense and back via the MPLS firewall/router. So, as it currently stands, I would have to go all or nothing in the move from one gateway to another.
I can make the transition, one office at a time by temporarily adding routes to ALL of our servers for remote office subnets that are not on the new gateway, but I thats a messy solution.