Anything Special to Migrate From IPsec VPN to OpenVPN Site-to-Site?
-
I think I remember reading in the pfSense book that traffic will be directed to IPsec tunnels before OpenVPN. I'm wondering if I want to change the tunnel, can I just set up the OpenVPN, wait for it to establish the tunnel and then disable the IPsec tunnel and everything will start flowing over the OpenVPN tunnel? Assuming I have OpenVPN configured correctly on both sides of course.
A little background: I currently have one central site that all 20+ other sites connect to with IPsec. I'd like to move from IPsec to OpenVPN mostly for the ability to do routing over the tunnels. I will set this up as much as I can in a test environment but I am interested to know if there are any pitfalls.
Thanks!
-
I have done exactly this with an 8-site setup.
You can setup the OpenVPN network in parallel and test the connectivity to the pfSense systems themselves, but in order to route to the LAN/internal subnets, you will just need to disable the IPsec tunnels on each end of a connection.
In my case, I used a PKI setup. If you go this route, on the main site you'll need a route statement in the custom options for each remote site subnet, and you'll need to set a CSC entry for the CN of each site's client certificate which contains an iroute statement for its network as well. Just remember to set "client-to-client" when making the tunnel so your sites can talk to each other also.
-
Thanks Jim. It's good to hear this has been done this way before. I did set up my first site-to-site OpenVPN using PKI in the lab and it took me a while but I got it working just the way you describe.
-
Hi jimp,
its always the better way to use OpenVPN between (pfsense) sites? u would prefer Openvpn instead of IPSEC?
What about problems?
I used OpenVPN Roadwarrior Connection in past and it works fine.
Is OpenVPN Site to Site an stable solution for productive environment?
Cya
-
I prefer OpenVPN all-around when I have the option. It's a lot easier to diagnose, and there is less to go wrong. It's also a lot easier to route however I want.
IPsec is good, it has its place, especially connecting with third-party devices, but it's hard to beat OpenVPN when you can use it.
-
Just to report back, I finally got around to making the change last Friday night and it went quite smoothly just as Jim said. I could see from the logs that the OpenVPN tunnel was up and I had the route statements in place. I disabled IPSec on one side and wondered why it didn't work but then remembered to disable it on the other side and then it came back up.
It has stayed up the whole weekend and things are going well today. I am curious if there are any tips for diagnosing when something does go wrong with one of these tunnels. I'm used to my usual steps with IPSec, such as deleting SAD entries if a site shows up but no traffic is passing, or if I'm really desperate, restarting the racoon service. With OpenVPN I don't see the service listed so the only way I see to restart is disabling/enabling OpenVPN completely. Of course I don't expect any problems but I'd like to be prepared if possible.
-
If you edit/save an openvpn instance, it will restart.
The logs tell you anything you need to know, there's really not much more to it than that. It will automatically timeout and try to reconnect (I think it defaults to 60 second timeout)
There's not a lot to go wrong that would require anything fancy like IPsec. :-)
-
Thanks!
@jimp:There's not a lot to go wrong that would require anything fancy like IPsec. :-)
I guess I'm too used to the complexities of IPSec to trust anything simple yet. :P
It is helpful to hear that it should "just work".
-
I simply cannot get this to work. I have only two sites: home office and a satellite office in another city. I have been trying for the past 4+ hours to get an OpenVPN site-to-site tunnel up and working with no success. Some background:
I initially setup my site-to-site tunnel using IPSEC. My remote users are also using IPSEC VPN clients (Shrew Soft) for now. Some of my remote users with Lenovo ThinkPad T410s are having issues with the Shrew Soft VPN client, so I've set up an OpenVPN server, created a CA and generated keys and certs. For now, I'm running both in parallel until I can migrate everyone over to OpenVPN. So far, so good. The OpenVPN server works: A remote user can connect to the home office with OpenVPN server and access the home office LAN. The problem is getting access for the remote user to the satellite office LAN. Home office users can access the satellite office and vice-versa over the IPSEC tunnel when physically located at either location. However, a remote user cannot access the satellite office LAN using the OpenVPN server in the home office. With IPSEC, all I had to do was create a separate profile in the Shrew Soft Client for the satellite office. With OpenVPN, this isn't an option.
So, I followed the instructions in Chapter 15 of pfSense guide and attempted to setup a site-to-site tunnel on my home office pfSense box. I configured the server side at the home office and created a FW rule allowing WAN access to the OpenVPN server:
UDP
1194
172.31.55.0/30
satellite office LAN network 1.2.3.4/24
shared key
route (satellite office LAN network) 255.255.255.0
Home-Sat1 TunnelFirewall rule: UDP x.x.x.x * WAN Address 1194 *
Using the existing IPSEC tunnel, I setup client side on the satellite office pfSense box. This is where things get screwy. The pfSense guide states that all you need to setup is the following:
UDP
home office IP
1194
interface IP (pfSense won't save without this - book says it's not needed) 172.31.55.0/30
3128
BF-CBC 128-bit
authentication: shared key
shared key
route (home office lan network) 255.255.255.0
Sat1-Home TunnelSince the satellite office is in another city, I have been disabling the IPSC VPN on the home office side to test. With the IPSEC tunnel down, the OpenVPN site-to-site fails to connect. No tunnel is displayed under Diagnostics - Routes and the OpenVPN logs look like this:
Jul 19 13:42:20 openvpn[13525]: x.x.x.x:1194 TLS Error: TLS handshake failed
Jul 19 13:52:05 openvpn[63242]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Jul 19 13:52:05 openvpn[63242]: WARNING: file '/var/etc/openvpn_server1.secret' is group or others accessible
Jul 19 13:52:05 openvpn[63242]: TCP/UDP: Socket bind failed on local address [undef]:1194: Address already in use
Jul 19 13:52:05 openvpn[63242]: ExitingIf I drop the IPSEC tunnel on both ends, I will need to travel back and forth between the two offices in order to re-establsh the tunnel which is what I'm trying to avoid. Any ideas as to what I'm doing wrong here? Thanks in advance.
-
Just briefly read over your problems so sorry if I missed something. One thing is that you don't need to disable IPSec until you know the OpenVPN tunnels are up so make sure you see the status showing they are good and the logs look good before you go disabling IPSec and have to drive remotely so set it back up.
-
Thanks. That saves me a commute. I tried a few things when I was at my satellite office the other day. Nothing works but I discovered that the client side is connecting just fine and that the problems appear to lie on the server side in the home office. The server fails to negotiate a connection. I re-read the pfSense manual and thought that the issue was that I was trying to use the same server port for both the remote VPN users and the site-to-site VPN tunnel. So I tried changing the UDP port number from 1194 to 1195 for the site to site link. Again, no tunnel is established and the server keeps trying to connect on port 1194. Then I tried to connect using PKI. I generated keys for both offices and set them up using the instructions in the sticky article at the top of this section. Again, nothing - no tunnel is even created so I have deleted all site-to-site settings at both locations. That's where I've left things until I can determine why the OpenVPN server on pfSense cannot handle more than one server in my environment. From everything I have seen, this should work. It works on IPSEC just fine. But, if this isn't possible with OpenVPN, I'll be forced to look at moving OpenVPN off pfSense to a dedicated Linux box or purchase a Cisco ASA appliance because I need the ability for remote VPN users connecting to the home office to be able to access the networks in both locations.
-
OK, I just tried something different. I generated a new static key on the CA running on my Linux system. Previously I was using the one on pfSense. I then recreated the site-to-site tunnel using this key. The tunnel now appears to come up sorta:
Home Office:
Jul 22 16:46:28 openvpn[47597]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Jul 22 16:46:28 openvpn[47597]: WARNING: file '/var/etc/openvpn_server1.secret' is group or others accessible
Jul 22 16:46:28 openvpn[47597]: LZO compression initialized
Jul 22 16:46:28 openvpn[47597]: gw 1.2.3.4
Jul 22 16:46:28 openvpn[47597]: TUN/TAP device /dev/tun1 opened
Jul 22 16:46:28 openvpn[47597]: /sbin/ifconfig tun1 10.0.100.1 10.0.100.2 mtu 1500 netmask 255.255.255.255 up
Jul 22 16:46:28 openvpn[47597]: /etc/rc.filter_configure tun1 1500 1545 10.0.100.1 10.0.100.2 init
Jul 22 16:46:29 openvpn[47613]: UDPv4 link local (bound): [undef]:1195
Jul 22 16:46:29 openvpn[47613]: UDPv4 link remote: [undef]
Jul 22 16:46:47 openvpn[47613]: Peer Connection Initiated with 5.6.7.8:1194
Jul 22 16:46:49 openvpn[47613]: Initialization Sequence CompletedSatellite Office:
Jul 22 16:49:05 openvpn[15967]: /etc/rc.filter_configure tun0 1500 1545 172.31.55.2 172.31.55.1 init
Jul 22 16:49:06 openvpn[15967]: SIGTERM[hard,] received, process exiting
Jul 22 16:49:39 openvpn[16579]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Jul 22 16:49:39 openvpn[16579]: WARNING: file '/var/etc/openvpn_client0.secret' is group or others accessible
Jul 22 16:49:39 openvpn[16579]: LZO compression initialized
Jul 22 16:49:39 openvpn[16579]: gw 173.226.133.81
Jul 22 16:49:39 openvpn[16579]: TUN/TAP device /dev/tun0 opened
Jul 22 16:49:39 openvpn[16579]: /sbin/ifconfig tun0 10.0.100.2 10.0.100.1 mtu 1500 netmask 255.255.255.255 up
Jul 22 16:49:39 openvpn[16579]: /etc/rc.filter_configure tun0 1500 1545 10.0.100.2 10.0.100.1 init
Jul 22 16:49:40 openvpn[16579]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
Jul 22 16:49:40 openvpn[16592]: UDPv4 link local (bound): [undef]:1194
Jul 22 16:49:40 openvpn[16592]: UDPv4 link remote: 1.2.3.4:1195
Jul 22 16:49:48 openvpn[16592]: Peer Connection Initiated with 1.2.3.4:1195
Jul 22 16:49:48 openvpn[16592]: Initialization Sequence CompletedNotice that the satellite pfSense box is connecting properly on UDP port 1195 while the home office pfSense box does not - it's still trying to use UDP port 1194. This must be why I'm getting the route add ERROR on the satellite office side when it tried to add a route to the home office LAN.
On the home office pfSense box I have two OpenVPN servers created: one using PKI for remote VPN clients (UDP 1194) and one using shared-key for site-to-site (UDP 1195). As the log shows, the home office server is not connecting the site-to-site using UDP 1195 even though that's the port specified in the server configuration. Any ideas as to why this is happening or is this a bug?
-
UPDATE
Since posting the above logs, I was able to determine that I misunderstood the server log entry. The tunnel between both offices is getting established properly - the message part about using UDP 1194 is generic to OpenVPN. So now my issue appears to be that no traffic is being routed between the two locations. If I understand correctly, my routing table on the sat office side should be showing something like this:Destination Gateway Flags Refs Use Mtu Netif Expire
1.2.3.0/24 10.0.100.2 UGS 0 1693 1500 tun0Instead, I can see the route established for tun0 between 10.0.100.1 & 10.0.100.2 (the site-to-site tunnel) but no route back to the home office side appears. The home office box does show a route to the 3.4.5.6/24 LAN in the sat office via tun1. For some unknown reason, on the sat office side, inputting a network value into the Remote Network tab of OpenVPN (1.2.3.4/24) is generating ERROR: FreeBSD route add command failed. I have tried just about everything. Adding a static route in the custom options gives me two of the above errors. Adding a firewall rule on the client side (sat office) to allow traffic out port 1195 on the WAN interface does nothing. I have looked just about everywhere on Google for a resolution with no success. The Wiki documentation points to the pfSense manual which I followed. Try as I might, I cannot get OpenVPN to add the return route from the sat office to the home office and hence, nothing is transversing the tunnel from the sat office. I am dead in the water here and would appreciate any suggestions.
-
Did you ever get this working? I am just seeing your post now. If you are using PKI, the routes should be pushed from the server to the client.
-
Thanks for asking. Unfortunately, no, I never could get OpenVPN to act as a remote access server and site-to-site VPN. I currently use IPSec for site-to-site VPN and remote users are using OpenVPN. Remote clients have two configs that allow them to select which location they wish to connect. I have OpenvPN server running at both locations. Back on 9/4, I posted the following:
_OK, I connected to both locations and disabled IPSec at each end. Here are my OpenVPN configurations:
Home Office
–---------
Address Pool: 10.99.99.0/30
Remote network: 10.10.0.0/24
Local network: 10.5.1.0/24
Cryptography: BF-CBC (128-bit)
Shared Key
LZO Compression: On
Add firewall rule: TCP/UDP * * * 1195 *
Hardware: Intel PRO/1000 MT NICs (Intel chipset)Remote Office
Server Address: <public ip="" for="" home="" office="">Address Pool: 10.99.99.0/30
Remote Network: 10.5.1.0/24
Cryptography: BF-CBC (128-bit)
Shared Key
LZO Compression: On
Hardware: DLink DGE-530T NICs (Marvell chipset)Initiated a reboot of the pfSense box at both locations. After 5 minutes, attempted to ping satellite LAN from home office pfSense box:
Ping output:
PING 10.10.0.2 (10.10.0.2) from 10.5.1.1: 56 data bytes--- 10.10.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossNo tunnel - fails because OpenVPN cannot add route to 10.10.0.0/24. See log entry below:
Log output for home office
Sep 4 12:56:10 openvpn[373]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Sep 4 12:56:10 openvpn[373]: WARNING: file '/var/etc/openvpn_server0.key' is group or others accessible
Sep 4 12:56:10 openvpn[373]: gw 12.71.127.97
Sep 4 12:56:10 openvpn[373]: TUN/TAP device /dev/tun0 opened
Sep 4 12:56:10 openvpn[373]: /sbin/ifconfig tun0 10.5.2.1 10.5.2.2 mtu 1500 netmask 255.255.255.255 up
Sep 4 12:56:10 openvpn[373]: /etc/rc.filter_configure tun0 1500 1542 10.5.2.1 10.5.2.2 init
Sep 4 12:56:11 openvpn[386]: UDPv4 link local (bound): [undef]:1194
Sep 4 12:56:11 openvpn[386]: UDPv4 link remote: [undef]
Sep 4 12:56:11 openvpn[386]: Initialization Sequence Completed
Sep 4 12:56:11 openvpn[386]: Need IPv6 code in mroute_extract_addr_from_packet
Sep 4 12:56:12 openvpn[388]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Sep 4 12:56:12 openvpn[388]: WARNING: file '/var/etc/openvpn_server1.secret' is group or others accessible
Sep 4 12:56:12 openvpn[388]: gw 12.71.127.97
Sep 4 12:56:12 openvpn[388]: TUN/TAP device /dev/tun1 opened
Sep 4 12:56:12 openvpn[388]: /sbin/ifconfig tun1 10.99.99.1 10.99.99.2 mtu 1500 netmask 255.255.255.255 up
Sep 4 12:56:12 openvpn[388]: /etc/rc.filter_configure tun1 1500 1544 10.99.99.1 10.99.99.2 init
Sep 4 12:56:14 openvpn[388]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
Sep 4 12:56:14 openvpn[397]: UDPv4 link local (bound): [undef]:1195
Sep 4 12:56:14 openvpn[397]: UDPv4 link remote: [undef]
Sep 4 12:56:15 openvpn[386]: Need IPv6 code in mroute_extract_addr_from_packet
Sep 4 12:56:17 openvpn[386]: Need IPv6 code in mroute_extract_addr_from_packetRouting table:
–------------
Destination Gateway Flags Refs Use Mtu Netif Expire
default 12.71.127.97 UGS 0 729 1500 em0
10.5.2.0/24 10.5.2.2 UGS 0 0 1500 tun0
10.5.2.2 10.5.2.1 UH 2 0 1500 tun0
10.10.0.0/24 10.5.2.2 UGS 0 96 1500 tun0
10.99.99.2 10.99.99.1 UH 0 0 1500 tun1Notice that no route is established for 10.99.99.2 (sat office) to 10.10.0.0/24. OpenVPN did not like the CIDR of 10.10.0.0/24. Now if I change the remote network designation to 10.10.0.0/16, I get the following log entry:
Sep 4 13:17:44 openvpn[3258]: OpenVPN 2.0.6 i386-portbld-freebsd7.2 [SSL] [LZO] built on Dec 4 2009
Sep 4 13:17:44 openvpn[3258]: WARNING: file '/var/etc/openvpn_server1.secret' is group or others accessible
Sep 4 13:17:44 openvpn[3258]: LZO compression initialized
Sep 4 13:17:44 openvpn[3258]: gw 12.71.127.97
Sep 4 13:17:44 openvpn[3258]: TUN/TAP device /dev/tun1 opened
Sep 4 13:17:44 openvpn[3258]: /sbin/ifconfig tun1 10.99.99.1 10.99.99.2 mtu 1500 netmask 255.255.255.255 up
Sep 4 13:17:44 openvpn[3258]: /etc/rc.filter_configure tun1 1500 1545 10.99.99.1 10.99.99.2 init
Sep 4 13:17:45 openvpn[3322]: UDPv4 link local (bound): [undef]:1195
Sep 4 13:17:45 openvpn[3322]: UDPv4 link remote: [undef]The routing error vanishes, the tunnel is up and a look at the routing table shows that the route to the satellite office is now established:
Destination Gateway Flags Refs Use Mtu Netif Expire
default 12.71.127.97 UGS 0 1034 1500 em0
10.5.1.0/24 link#3 UC 0 0 1500 em1
10.5.2.0/24 10.5.2.2 UGS 0 0 1500 tun0
10.5.2.2 10.5.2.1 UH 2 0 1500 tun0
10.10.0.0/24 10.5.2.2 UGS 0 137 1500 tun0 =>
10.10.0.0/16 10.99.99.2 UGS 0 0 1500 tun1
10.99.99.2 10.99.99.1 UH 1 0 1500 tun1However, no traffic is flowing accross the tunnel:
Ping output:
PING 10.10.0.2 (10.10.0.2) from 10.5.1.1: 56 data bytes–- 10.10.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossAt this point, I am stopping. I have reloaded my previous configuration in order to restore access to my satellite office with the IPSec tunnel. Any help would be much appreciated.</public>_
And this is where I am now. I believe it when you say that OpenVPN works but I cannot isolate what is preventing this from working in my environment. I tried everything including traveling to the remote office and changing the IP subnet to 172.16.33.0/24 only to get the same results. I decided to wait for the 2.0 release. If you can spot what I'm doing wrong, I would be very grateful.
-
Mine is for multiple sites so I am using PKI because it is much easier to manage after the initial setup of generating keys. I see you tried PKI but in your latest config you are back to Shared Key.
If you want to try PKI again I could try to help by comparing my config against yours but otherwise the configs are a little different already and I don't know where the problem could be.