IPsec between pfSense at home and Ubuntu in data center
-
I would like to encrypt all of my internet traffic at home and enter and leave the internet via an Ubuntu server in a data center. Basically a site to site IPsec tunnel between the two of them.
Home: pfSense 2.2.2-RELEASE (amd64) with a public IP on the wan interface and DHCP on the lan interface
Data center: Ubuntu 14.04 server with 1 interface with a public IP
I've installed Openswan on the Ubuntu server and am wondering if anyone can help me out with the right ipsec.conf settings and pfSense settings? I'd really appreciate it.
-
do you have to use ubuntu? what about freebsd or virtualization?
-
So I've changed my data center setup to a VPS (Ubuntu server 14.04 x64) with Strongswan and UFW. The configuration is not optimal yet as I'm learning how everything works but it works for now. I do have issues loading certain websites and will play around with mss settings to try and resolve these.
/etc/ipsec.conf
config setup
uniqueids = yes
charondebug = ""conn con1000
reqid = 1
fragmentation = yes
keyexchange = ikev2
reauth = yes
forceencaps = no
mobike = no
rekey = yes
installpolicy = yes
type = tunnel
dpdaction = restart
dpddelay = 10s
dpdtimeout = 60s
auto = route
left = PUBLIC.IP.DATA.CENTER
right = PUBLIC.IP.PFSENSE.HOME
leftid = PUBLIC.IP.DATA.CENTER
ikelifetime = 28800s
lifetime = 3600s
ike = aes128-sha1-modp1024!
esp = aes128gcm128-sha1!
leftauth = psk
rightauth = psk
rightid = PUBLIC.IP.PFSENSE.HOME
rightsubnet = PRIVATE.LAN.AT.HOME/24
leftsubnet = 0.0.0.0/0/etc/ipsec.secrets
PUBLIC.IP.DATA.CENTER PUBLIC.IP.PFSENSE.HOME : PSK A-VERY-STRONG-KEY-RIGHT-HERE
Added to /etc/ufw/before.rules
START IPSEC RULES
NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s PRIVATE.LAN.AT.HOME/24 -o eth0 -j MASQUERADE
COMMITEND IPSEC RULES
and allowed the following traffic in UFW
500
PUBLIC.IP.DATA.CENTER/esp
4500My pfSense has the following settings.
<ipsec><phase1><ikeid>1</ikeid>
<iketype>ikev2</iketype>
<interface>wan</interface>
<remote-gateway>PUBLIC.IP.DATA.CENTER</remote-gateway>
<protocol>inet</protocol>
<myid_type>myaddress</myid_type>
<myid_data><peerid_type>peeraddress</peerid_type>
<peerid_data><encryption-algorithm><name>aes</name>
<keylen>128</keylen></encryption-algorithm>
<hash-algorithm>sha1</hash-algorithm>
<dhgroup>2</dhgroup>
<lifetime>28800</lifetime>
<pre-shared-key>A-VERY-STRONG-KEY-RIGHT-HERE</pre-shared-key>
<private-key><certref><caref><authentication_method>pre_shared_key</authentication_method><nat_traversal>on</nat_traversal>
<mobike>off</mobike>
<dpd_delay>10</dpd_delay>
<dpd_maxfail>5</dpd_maxfail></caref></certref></private-key></peerid_data></myid_data></phase1>
<client><phase2><ikeid>1</ikeid>
<uniqid>48592e235543</uniqid>
<mode>tunnel</mode>
<reqid>1</reqid>
<localid><type>lan</type></localid>
<remoteid><type>network</type><address>0.0.0.0</address>
<netbits>0</netbits></remoteid>
<protocol>esp</protocol>
<encryption-algorithm-option><name>aes128gcm</name>
<keylen>128</keylen></encryption-algorithm-option>
<hash-algorithm-option>hmac_sha1</hash-algorithm-option>
<pfsgroup>2</pfsgroup>
<lifetime>3600</lifetime></phase2></client></ipsec>And of course NAT outbound and firewall rules for IPsec.
-
You're probably better off using OpenVPN for that usage case, as that gives you much better flexibility in what you route out via the VPS.
-
@cmb:
You're probably better off using OpenVPN for that usage case, as that gives you much better flexibility in what you route out via the VPS.
That is correct and I agree. The problem with OpenVPN however is that I can't max out the connection. OpenVPN works great but limits around 160 Mbit/s. With IPsec I easily reach the full 200 Mbit/s I currently have between the two sites. Both ends have a CPU with AES-NI support and I played around with all OpenVPN recommended settings but I can't push it beyond 160 Mbit/s. So that's why I'm back at IPsec.
-
Ah. Yeah OpenVPN doesn't yet support AES-GCM, that's coming in OpenVPN 2.4 later this year it appears. That'll get you AES-NI acceleration benefits with it.
-
Dump the contents of the generated StrongSwan configuration on pfSense, it looks like you have it configured for esp = aes128gcm128-sha1-modp1024! which is different to the other side.