[SOLVED] - Traffic over OpenVPN tunnel doesn't pass
-
Hello community,
First of all thank you for this great piece of work called pfSense. It's awesome and
feature rich. I have been using it (2.0) for a couple of months now and didn't have any kind
of problems until today.Today in the morning I have updated my office firewall using System: Firmware: Autoupdate.
The system updated to: Sun Apr 10 21:49:29 EDT 2011.I have a Site to Site OpenVPN server setup on this system. The tunnel is made with a FreeBSD
system (8.1-STABLE) running OpenVPN:# openvpn --version OpenVPN 2.1.3 amd64-portbld-freebsd8.1 [SSL] [LZO2] built on Oct 21 2010 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net></sales@openvpn.net>
The OpenVPN configuration on both sides is basic, push route with subnet behind pfSense
to the FreeBSD box and vice versa. The subnet I used for OpenVPN is 10.11.12.0/29. pfSense
ovpns1 interface has 10.11.12.1 –> 10.11.12.2 and FreeBSD ovpnc1 has 10.11.12.6 --> 10.11.12.5LAN (172.16.0.0/24) ------ [pfSense] (ovpns1) –--- (ovpnc1) [FreeBSD] –---- Remote LAN (172.31.30.0/24)
pfSense# ifconfig ovpns1 ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500 options=80000 <linkstate>inet6 fe80::21b:21ff:fe95:9c2%ovpns1 prefixlen 64 scopeid 0x10 inet 10.11.12.1 --> 10.11.12.2 netmask 0xffffffff nd6 options=3 <performnud,accept_rtadv>Opened by PID 9746</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>
FreeBSD# ifconfig ovpnc1 ovpnc_a2a1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500 options=80000 <linkstate>inet 10.11.12.6 --> 10.11.12.5 netmask 0xffffffff Opened by PID 16149</linkstate></up,pointopoint,running,multicast>
After update the VPN tunnel isn't working anymore. I can't ping from LAN to Remote LAN.
Although I can ping the IP address of the tunnel from both ends.pfSense# ping 10.11.12.6 PING 10.11.12.6 (10.11.12.6): 56 data bytes 64 bytes from 10.11.12.6: icmp_seq=0 ttl=64 time=19.788 ms 64 bytes from 10.11.12.6: icmp_seq=1 ttl=64 time=19.746 ms
FreeBSD# ping 10.11.12.1 PING 10.11.12.1 (10.11.12.1): 56 data bytes 64 bytes from 10.11.12.1: icmp_seq=0 ttl=64 time=22.062 ms 64 bytes from 10.11.12.1: icmp_seq=1 ttl=64 time=19.633 ms
And what is strange, at least for me, is that I can ping from the FreeBSD box
a machine located in LAN behind pfSense:FreeBSD# ping 172.16.0.77 PING 172.16.0.77 (172.16.0.77): 56 data bytes 64 bytes from 172.16.0.77: icmp_seq=0 ttl=63 time=20.816 ms 64 bytes from 172.16.0.77: icmp_seq=1 ttl=63 time=168.055 ms
I can't ping any machine located in Remote LAN from the pfSense box:
pfSense# ping 172.31.30.14 PING 172.31.30.14 (172.31.30.14): 56 data bytes [...] NO OUTPUT [...]
If I start a tcpdump on the ovpns1 interface of pfSense I can see traffic going
to the tunnel endpoint but no traffic coming back.pfSense# tcpdump -eni ovpns1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ovpns1, link-type NULL (BSD loopback), capture size 96 bytes 14:17:40.802869 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 69, length 64 14:17:41.803846 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 70, length 64 14:17:42.804833 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 71, length 64 14:17:43.805805 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 72, length 64 14:17:44.806774 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 73, length 64
How can I debug this problem further? The tunnel was working properly before the morning
update.Thank you,
v -
Hello again,
I have udpated pfSense to
pfSense# cat /tmp/pfSense_version Mon Apr 11 17:11:38 EDT 2011
Still the problem persists. The tunnel is up but no traffic goes across from
pfSense to FreeBSD. Ping from FreeBSD tunnel endpoint to any IP behind pfSense works fine.
I have also updated openvpn on the FreeBSD box to latest openvpn from ports thinking
it might have something to do with this.FreeBSD# openvpn --version OpenVPN 2.1.4 amd64-portbld-freebsd8.1 [SSL] [LZO2] built on Jan 21 2011 Originally developed by James Yonan Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net></sales@openvpn.net>
I also have another pfSense box located in a remote location that has a tunnel setup
with the pfSense box from the office. Same problem there too, tunnel set up just
fine, no traffic goes across except ping from endpoint to endpoint.The firewall rules on OpenVPN interface on both pfSense boxes and FreeBSD box
are set to pass everything.Once again, please tell me what can I do to find the problem?
Thank you,
v -
Hello again,
I have solved the problem. Guess what? The problem was located between the
monitor and the chair :).For future reference and for the sake of solving it I will post what happened.
[Subnet A] –---- [pfSense] (ovpns1) –------------ (ovpnc1) [FreeBSD] –------- [Subnet B]
My problem was that I couldn't get traffic across from subnet A to subnet B.
Digging around I have found out that OpenVPN Server on pfSense was not
properly configured.If you want to reach a client Subnet, in my case Subnet B, you need to reference a client
config directory (client-config-dir) on the server and have a file (name of the file is the common name of the client)
for each client you want to apply certain configurations to. In order to reach a Subnet that's behind a client you have
to make use of iroute A.A.A.A N.N.N.N in the client's particular file.To make per client configuration in pfSense you can access VPN -> OpenVPN: Client Specific Override and
add client specific overrides. So I have added an override for my client specifying iroute Subnet B in Advance
box and everything works.Anyway I don't really understand how could it work before yesterday's update. Was it supposed to work
that way (without iroute for each client)? From what I have read on OpenVPN website it shouldn't / doesn't work
without iroute.I am very glad that I could solve the issue by my self :). If you ever have troubles with anything just
turn on debug logging and for sure you can spot what's going wrong.A great day,
v -
Nicely done mtx! I was having exactly the same issue. I (wrongly) assumed that the ccd settings were being automagically set by pfSense. Having used OpenVPN for quite a while, and being used to creating ccd files, I'm surprised I missed this!
Thanks!