Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to get an OpenVPN tunnel going on pfSense 1.2.3-RELEASE running on embedded routers.

I have a local LAN 10.34.43.0/254. The remote LAN is 10.200.1.0/24. The local pfSense is configured as the client, and the remote is configured as the server.

My OpenVPN tunnel is using the IP range 10.99.89.0/24 internally. There are also some additional LANs on the remote side routed through the tunnel, but the issue is not with those since my connectivity fails before that point in the chain.

The tunnel comes up fine and the logs look healthy. What I find is this:-

  • I can ping and telnet to the remote LAN and the additional remote LANs from the local pfSense box's shell.
  • I cannot ping or telnet to any remote LANs from the local network.
  • I cannot ping or telnet to the local network from the remote LAN or the remote pfSense box's shell.
  • If I tcpdump the tun interfaces on both sides and ping from the local LAN, I see the packets hit the tunnel locally, but they do not appear on the remote side (nor do they appear on the remote LAN interface if I tcpdump that).
  • If I tcpdump the tun interfaces on both sides and ping from the local pfSense shell, I see the packets hit the tunnel locally, and exit the remote side. I can also tcpdump the remote LAN interface and see them pass there too.
  • If I tcpdump the tun interfaces on both sides and ping from the remote pfSense shell, I see the packets hit the remote tun but they do not emerge from the local one.

Here is the config file the remote side is using:-

#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
server 10.99.89.0 255.255.255.0
client-config-dir /var/etc/openvpn_csc
push "route 10.200.1.0 255.255.255.0"
lport <port>
route 10.34.43.0 255.255.255.0
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
push "route 205.217.5.128 255.255.255.224"
push "route 205.217.5.64 255.255.255.224"
push "route 165.193.147.128 255.255.255.224"
push "route 165.193.147.32 255.255.255.240"
push "route 192.168.1.16 255.255.255.240"
push "route 192.168.2.16 255.255.255.240"

Here is the local config:-

writepid /var/run/openvpn_client0.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
remote <host> <port>
client
lport 1194
ifconfig 10.99.89.2 10.99.89.1
ca /var/etc/openvpn_client0.ca
cert /var/etc/openvpn_client0.cert
key /var/etc/openvpn_client0.key
comp-lzo

You can see the relevant parts of the routing tables extracted from pfSense here http://pastie.org/5365800

The local firewall permits all ICMP from the LAN, and my PC is allowed everything to anywhere. The remote firewall treats its LAN as trusted and permits all traffic on that interface.

Can anyone suggest why this is not working, and what I could try next?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

With SSL/TLS site to site VPNs, you need the route on the server, and the iroute in a client specific override. The description here sounds like you're missing that iroute. Unlike shared key, where the route on the server suffices. In the case of VPNs like this, the route on the server sends that traffic to that particular OpenVPN instance, and its internal routing, via iroutes, must know which client to route that particular network.

Under VPN>OpenVPN, Client Specific Override tab, add a new entry. For the "Common name", put in the CN from the certificate on the client side. In the Advanced box, fill in "iroute 10.34.43.0 255.255.255.0" (sans quotes). Leave the rest at defaults, click Save. Restart the OpenVPN client from Status>Services on the client system, and once it reconnects, it should work if it is indeed the missing iroute.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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