OpenVPN Site-to-Site Woes

glitch

I recently switched the company I work for from an aging proprietary VPN solution to a Pentium 4 running pfSense-1.2.3. We initially configured a branch office to connect to our home office through an OpenVPN site-to-site link using PKI (followed this howto: http://forum.pfsense.org/index.php/topic,12888.0.html ). The branch was also running pfSense-1.2.3 on Soekris embedded hardware, and the VPN worked perfectly, allowing us to access all branch machines, and the branch office to access all home office resources.

I'd chosen PKI for our setup because we plan on deploying more Soekris and/or ALIX boxes to current and future branch offices. After confirming that it was up to our needs with the first branch, we purchased an ALIX unit and installed pfSense-1.2.3 as well. I generated client keys for the new branch office, added a client-specific configuration, and had the second branch up and routing to the home office as well as the first branch in no time. At this point, the network config was as follows:

pfSense/OpenVPN at the home office only needed to route 10.3.0.0/16 into the VPN, since all test branches were using 10.3.x.0/24 subnets. I had initially configured it this way to make testing easier on me. However, in reality Branch2 really needs to be 10.1.0.0/24 since the guys in the office are fond of static IPs and don't wish to renumber everything. To me, it seemed as if it would be a simple process of changing the IP on the ALIX system and adding another route statement to the OpenVPN config – no so, apparently. With my current configuration, I'm able to ping the 10.0.0.0/24 and 10.3.0.0/24 networks from the SSH login of the Branch2 system, but not from any machines connected to the LAN port or even the webinterface Ping tool.

I've been wracking my brain trying to figure out what needs to be happening here, including adding ALL:ALL pass rules on the LAN sides of the Home and Branch2 pfSense firewalls. It would seem the tunnel is up and routing properly, since I can ping/SSH from the Branch2 system, but it doesn't seem the tunnel is being correctly routed to/from the LAN connection at Branch2. Any ideas?

Additional info:

Tunnel IPs are 172.0.0.0/24 and assigned to tunnels via DHCP
pfSense boxes are running as premises routers in all cases
Routing to 10.3.0.0/16 works exactly as it should

XIII

you need to change the IPs on both ends, branch2 and home office. Sounds like you only changed branch2, you said you changed it on the alix system which is branch 2, but you didnt say if you changed it on the P4 system (homeoffice).
On the homeoffice system under remote network it probably still has the old 10.3.1.0 instead of the new 10.1.0.0

if this is not the case post the config pics or text (blocking out public IPs/FQDNs and other sensitive info)

glitch

@XIII:

you need to change the IPs on both ends, branch2 and home office. Sounds like you only changed branch2, you said you changed it on the alix system which is branch 2, but you didnt say if you changed it on the P4 system (homeoffice).
On the homeoffice system under remote network it probably still has the old 10.3.1.0 instead of the new 10.1.0.0

if this is not the case post the config pics or text (blocking out public IPs/FQDNs and other sensitive info)

Yes, I changed it on both ends. Here's the server config:

writepid /var/run/openvpn_server0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto udp
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
client-to-client
server 172.0.0.0 255.255.255.0
client-config-dir /var/etc/openvpn_csc
lport 1194
push "dhcp-option DNS 10.0.0.4"
push "dhcp-option DNS 10.0.0.1"
push "dhcp-option WINS 10.0.0.4"
push "dhcp-option NBT 2"
ca /var/etc/openvpn_server0.ca
cert /var/etc/openvpn_server0.cert
key /var/etc/openvpn_server0.key
dh /var/etc/openvpn_server0.dh
comp-lzo
persist-remote-ip
float
push "route 10.0.0.0 255.255.255.0"
 push "route 10.3.0.0 255.255.255.0"
 route 10.1.0.0 255.255.255.0
 route 10.3.0.0 255.255.255.0
 verb 3

Additionally, each branch has a Client-Specific Configuration by its Common Name. That configuration just contains an iroute statement directing traffic for the branch subnet back into the VPN. Example:

Disabled: No
Common Name: Branch2
Blocked: No
Push reset: No
Interface IP: <blank>Custom Options: iroute 10.1.0.0 255.255.255.0
Description: Branch 2 VPN Link.

Each client is configured the same, using the static IP of the home OpenVPN server, LZO compression, UDP and a verbosity of 3. The only difference is, of course, the PKI key/cert pasted in for the specific branch.</blank>

glitch

To make things a little stranger, I've determined that Branch2 and Branch1 are fully linked by the VPN – routing from LAN-attached machines in Branch2's network is fine to LAN-attached machines in Branch1's network. I should think this indicates a routing problem on the Home Office pfSense/OpenVPN machine, since packets seem to be getting lost only on its subnet.

glitch

I began doing an audit of various configuration files after posting the last remark, to determine if something was blocking 10.1.0.0/24 traffic. Interestingly enough, I found a reference to 10.1.0.0/24 in /var/etc/racoon.conf – the entry here suggests there's something to do with IPsec, and according to the pfSense book anything IPsec-related will mess up VPN links. So I changed Branch2's subnet to 10.5.0.0/24, and now everyone is communicating just as one would expect.

Anyone know what a reference to 10.1.0.0/24 is doing in racoon.conf?

glitch

I reported to my boss about the success with the IP change…"oh, I bet I know why...when you first set up the pfSense I wanted to see if my home router would connect with its old VPN." He'd added an IPsec configuration.

Thanks, pfSense developers, for giving us a routing platform that does exactly what we want -- this is why our company buys books and makes donations to the project!

XIII

I was going to ask if you tried rebooting both machines or had an active IPSec connection as the config settings look right, but you figured it out, glad to hear.