Problem with pfsense acting as an OpenVPN client
-
Hi,
I have a problem with my pfsense setup where I'm not seeing the expected results when configured as an openvpn client. What appears to be happening is that traffic from the local network is not being routed correctly through the vpn tunnel. The tunnel is to connect one site with a remote internal network operating at another site which has an openvpn server.
I previously had the two sites connected successfully when running the openvpn client on an openbsd-based server, however since replacing this server with pfsense, what appears to be happening is that while pfsense establishes the openvpn tunnel successfully, it doesn't route traffic through it.
The network setup looks like this:
Local network (10.1.1.0/24) -> pfsense <- 10.1.2.0/24 -> openvpn server -> Internal network (10.1.3.0/24)
Where 10.1.2.0 is the openvpn tunnel. At the moment, pfsense can ping any system on the 10.1.3.0 network, and get a response:
PING 10.1.3.200 (10.1.3.200): 56 data bytes
64 bytes from 10.1.3.200: icmp_seq=0 ttl=62 time=15.402 msHowever, when a machine on the local 10.1.1.0 network tries, there is no response. Checking tcpdump on pfsense shows that traffic is being routed into the tunnel:
[2.0.3-RELEASE][root@pfsense]/var/etc(7): tcpdump -i ovpnc2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 96 bytes
10:10:16.153305 IP 10.1.1.200 > 10.1.3.200: ICMP echo request, id 9554, seq 1, length 64But tcpdump on the openvpn server shows that no traffic is coming out the other side of the tunnel.
Checking the routing tables on both servers, everything appears correct:
[2.0.3-RELEASE][root@pfsense]/var/etc(10): netstat -r
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
10.1.1.0 link#6 U 0 141560575 em4
10.1.2.0 10.1.2.9 UGS 0 0 ovpnc2
10.1.2.9 link#14 UH 0 0 ovpnc2
10.1.2.10 link#14 UHS 0 0 lo0
10.1.3.0 10.1.2.9 UGS 0 9 ovpnc2root@openvpn-server:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
10.1.2.2 * 255.255.255.255 UH 0 0 0 tun0
localnet * 255.255.255.224 U 0 0 0 eth0
10.1.2.0 10.1.2.2 255.255.255.0 UG 0 0 0 tun0
10.1.1.0 10.1.2.2 255.255.255.0 UG 0 0 0 tun0
10.1.3.0 * 255.255.255.0 U 0 0 0 eth1
default xxx.xxx.xxx.xxx 0.0.0.0 UG 100 0 0 eth0Below are the relevant config files:
client2.conf:
dev ovpnc2
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-client
cipher BF-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local xxx.xxx.xxx.xxx
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote openvpn.server.fqdn 1194
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
comp-lzoserver.conf
local xxx.xxx.xxx.xxx
port 1194
proto tcp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.1.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.1.3.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3I'd appreciate any assistance anyone can offer in troubleshooting this issue, as it has me stumped at the moment!
-
Hi.
I also have a similar problem. Transit packets leave the openvpn server in the tunnel but on the client side of the tunnel do not come. You have found a solution? -
Use a /30 for your tunnel instead of a /24. I had this same problem initially. For some reason, your client and server are not picking the same set of IPs for their tunnel endpoints. Your client thinks the server is at 10.1.2.9 when it's actually at 10.1.2.1. Your server thinks the client is at 10.1.2.2 when it's actually at 10.1.2.10. If you set the mask to /30 they will have no other choice than for the server to be at 10.1.2.1 and client to be 10.1.2.2.