[solved] road-warrior setup cannot ping to LAN since upgraded to 2.0.2-RELEASE
-
I've pleasantly used pfSense 2 with OpenVPN in a road-warrior scenario with various clients including XP, Win7, Android and Maemo for more than a year. Now after upgrading pfSense to 2.0.2 none of the clients can reach the the LAN anymore. I've not changed any setup, neither on any client nor in pfSense, other than the manual setting of DNS Servers because of the PPP-assigned DNS server problem.
When connecting, the OVPN clients always report success because the tunnel is established (using 192.168.10.0/24) and also it seems the route to LAN (192.168.1.0/24) gets pushed to the client but cannot be used for some reason. Clients can ping the pfSense LAN IP (192.168.1.221) which at the same time is the standard gateway for that LAN, but cannot reach any other IP. The pfSense box itself however can ping to any client and also to the LAN.It seems like the firewall settings or routing got messed during the upgrade process (used Web-GUI).
Here's the ovpn server setup:```
#cat /var/etc/openvpn/server1.conf
dev ovpns1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp-server
cipher BF-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local xxx.xxx.xxx.xxx
engine padlock
tls-server
server 192.168.10.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
tls-verify /var/etc/openvpn/server1.tls-verify.php
lport xxxx
management /var/etc/openvpn/server1.sock unix
max-clients 4
push "route 192.168.1.0 255.255.255.0"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
comp-lzo
persist-remote-ip
float
push "route 192.168.1.0 255.255.255.0"
management 127.0.0.1 443Here's the routes in pfSense:``` # netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 217.0.116.247 UGS 0 450088 pppoe0 google-public-dns- 217.0.116.247 UGHS 0 3868 pppoe0 google-public-dns- 217.0.116.247 UGHS 0 77739 pppoe0 p5488DC8F.dip.t-di link#11 UHS 0 0 lo0 localhost link#10 UH 0 546 lo0 192.168.1.0 link#1 U 0 888976 dc0 router link#1 UHS 0 0 lo0 192.168.10.0 192.168.10.2 UGS 0 0 ovpns1 192.168.10.1 link#12 UHS 0 0 lo0 192.168.10.2 link#12 UH 0 10 ovpns1 217.0.116.247 link#11 UH 0 0 pppoe0 217.237.148.22 217.0.116.247 UGHS 0 3906 pppoe0 f-lb-b01.isp.t-ipn 217.0.116.247 UGHS 0 3911 pppoe0The system log when starting OpenVPN shows:```
Jan 26 02:00:40 dnsmasq[9327]: using nameserver 217.237.150.51#53
Jan 26 02:00:40 dnsmasq[9327]: using nameserver 217.237.148.22#53
Jan 26 02:00:40 dnsmasq[9327]: using nameserver 8.8.8.8#53
Jan 26 02:00:40 dnsmasq[9327]: using nameserver 8.8.4.4#53
Jan 26 02:00:40 dnsmasq[9327]: reading /etc/resolv.conf
Jan 26 02:00:24 check_reload_status: Reloading filter
Jan 26 02:00:24 apinger: Starting Alarm Pinger, apinger(50362)
Jan 26 02:00:23 apinger: Exiting on signal 15.
Jan 26 02:00:23 php: : Removing static route for monitor 8.8.8.8 and adding a new route through 217.0.116.247
Jan 26 02:00:21 php: : rc.newwanip: on (IP address: 192.168.10.1) (interface: opt1) (real interface: ovpns1).
Jan 26 02:00:21 php: : rc.newwanip: Informational is starting ovpns1.
Jan 26 02:00:20 check_reload_status: Syncing firewall
Jan 26 02:00:14 check_reload_status: rc.newwanip starting ovpns1
Jan 26 02:00:13 kernel: ovpns1: link state changed to UP
Jan 26 02:00:11 check_reload_status: Reloading filter
Jan 26 02:00:11 kernel: ovpns1: link state changed to DOWNwhile at the same time the OpenVPN log shows:``` Jan 26 02:00:14 openvpn[20072]: Initialization Sequence Completed Jan 26 02:00:14 openvpn[20072]: TCPv4_SERVER link remote: [undef] Jan 26 02:00:14 openvpn[20072]: TCPv4_SERVER link local (bound): [AF_INET]xxx.xxx.xxx.xxx:xxxx Jan 26 02:00:14 openvpn[20072]: Listening for incoming TCP connection on [AF_INET]xxx.xxx.xxx.xxx:xxxx Jan 26 02:00:13 openvpn[19022]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1544 192.168.10.1 192.168.10.2 init Jan 26 02:00:13 openvpn[19022]: /sbin/ifconfig ovpns1 192.168.10.1 192.168.10.2 mtu 1500 netmask 255.255.255.255 up Jan 26 02:00:13 openvpn[19022]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Jan 26 02:00:13 openvpn[19022]: TUN/TAP device /dev/tun1 opened Jan 26 02:00:13 openvpn[19022]: Initializing OpenSSL support for engine 'padlock' Jan 26 02:00:13 openvpn[19022]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jan 26 02:00:13 openvpn[19022]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want Jan 26 02:00:12 openvpn[19022]: OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 6 2012 Jan 26 02:00:11 openvpn[9818]: SIGTERM[hard,] received, process exiting Jan 26 02:00:11 openvpn[9818]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1544 192.168.10.1 192.168.10.2 initOpenVPN log shows a successfull connection:```
Jan 26 02:08:09 openvpn[20072]: N900@K-Home/109.84.0.67:43167 send_push_reply(): safe_cap=960
Jan 26 02:08:07 openvpn[20072]: 109.84.0.67:43167 [N900@K-Home] Peer Connection Initiated with [AF_INET]109.84.0.67:43167
Jan 26 02:07:58 openvpn[20072]: TCPv4_SERVER link remote: [AF_INET]109.84.0.67:43167
Jan 26 02:07:58 openvpn[20072]: TCPv4_SERVER link local: [undef]
Jan 26 02:07:58 openvpn[20072]: TCP connection established with [AF_INET]109.84.0.67:43167
Jan 26 02:07:58 openvpn[20072]: LZO compression initialized
Jan 26 02:07:58 openvpn[20072]: Re-using SSL/TLS contextAttached are the firewall rules for OpenVPN as well for VPNprivate and LAN. I don't know why there appear two VPN interfaces for the Firewall, but exactly this setup used to work for me before 2.0.2-RELEASE. I hope to have described the issue sufficiently. I've found similar reports in various forums but none of the solutions, if any addressed my problem. I'd greatly appreciate any hints or good advice on this.         -
What version did you upgrade from? Regardless, it's not likely the upgrade is related. Try running a constant ping to one of the hosts, packet capture on LAN filtering on that IP, and see if it's getting passed out.
-
Thanks for looking into this and your reply.
I've upgraded from pfSense 2.0-RELEASE (i386) to 2.0.2-RELEASE (i386) however it might well be that it's just a coincidence that my problem arised just at the time of upgrading, because at this occasion it was the first reboot that I can remember. In order to exclude the possibility of configuration damages while upgrading I had uploaded a backup configuration file of a known good state after seeing the problem, but that didn't help. So I still don't know if the new version is not handling my configuration in the same way as the previous version.
So I tried to follow your suggestion. Did setup a firewall rule on the LAN interface to log ICMP like the attached image shows. Then pinged from the pfSense host to see the log and later from a VPN client.
*** Welcome to pfSense 2.0.2-RELEASE-pfSense (i386) on router *** WAN (wan) -> pppoe0 -> xxx.xxx.xxx.xxx (PPPoE) LAN (lan) -> dc0 -> 192.168.1.221 VPNPRIVATE (opt1) -> ovpns1 -> 192.168.10.1 # ping 192.168.1.220 PING 192.168.1.220 (192.168.1.220): 56 data bytes 64 bytes from 192.168.1.220: icmp_seq=0 ttl=64 time=0.386 ms 64 bytes from 192.168.1.220: icmp_seq=1 ttl=64 time=0.279 ms 64 bytes from 192.168.1.220: icmp_seq=2 ttl=64 time=0.263 ms 64 bytes from 192.168.1.220: icmp_seq=3 ttl=64 time=0.307 ms 64 bytes from 192.168.1.220: icmp_seq=4 ttl=64 time=0.285 ms ^C --- 192.168.1.220 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.263/0.304/0.386/0.043 msSystem logs: Firewall```
Act Time If Source Destination Proto
block Jan 26 11:11:49 LAN 0.0.0.0 224.0.0.1 IGMP
block Jan 26 11:09:44 LAN 0.0.0.0 224.0.0.1 IGMP
block Jan 26 11:07:38 LAN 0.0.0.0 224.0.0.1 IGMP
block Jan 26 11:05:33 LAN 0.0.0.0 224.0.0.1 IGMPThen ping from a VPN client, first to the pfSense host (successful), then to another host on the LAN (100% loss) gives the following log. System logs: Firewall``` Act Time If Source Destination Proto block Jan 26 11:13:53 LAN 0.0.0.0 224.0.0.1 IGMP block Jan 26 11:11:49 LAN 0.0.0.0 224.0.0.1 IGMP block Jan 26 11:09:44 LAN 0.0.0.0 224.0.0.1 IGMP block Jan 26 11:07:38 LAN 0.0.0.0 224.0.0.1 IGMP block Jan 26 11:05:33 LAN 0.0.0.0 224.0.0.1 IGMPA route command on the client shows (extract):```
Destination Gateway Genmask iface
192.168.1.0 192.168.10.1 255.255.255.0 UG 0 0 0 tun0
192.168.10.0 192.168.10.1 255.255.255.0 UG 0 0 0 tun0I have no idea why destination 224.0.0.1 is shown in the logs. [edit]It seems 224.0.0.1 is a broadcast, possibly by UPnP devices, which definitely are present in my LAN. Then it looks like neither the ping from my pfSense, nor from the VPN client does appear in the log, although the pfSense ping is beeing answered (while the ping from the VPN client is not). Something wrong with my firewall rule?[/edit]     -
traffic from OpenVPN clients is filtered on OpenVPN, not LAN. In your case, both OpenVPN and VPNPRIVATE can apply, the former before the latter.
The 224.0.0.1 is multicast traffic, unrelated.
Start a constant ping to 192.168.1.220 from the VPN client, go to Diag>Packet capture, interface LAN, fill in host 192.168.1.220, start the capture. Let it run for 3-4 seconds or so, long enough for a couple pings to time out, and stop it.
-
Many thanks for the advice. I send the ping requests from VPN client to LAN host 192.168.1.220 and captured successfully on interface VPNPRIVATE and LAN.
Here's what has been reported on interface LAN:```
02:10:05.260521 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 65, length 64
02:10:05.260917 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46
02:10:06.248109 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 66, length 64
02:10:06.260928 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46
02:10:07.260931 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46
02:10:07.273513 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 67, length 64
02:10:08.265299 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 68, length 64
02:10:08.265917 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46
02:10:09.259272 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 69, length 64
02:10:09.265912 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46Then tried to capture the reply to 192.168.10.6 (VPN-Client) in interface LAN:``` 02:22:52.419953 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 831, length 64 02:22:52.420877 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46 02:22:53.420873 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46 02:22:53.430594 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 832, length 64 02:22:54.410433 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 833, length 64 02:22:54.420873 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46 02:22:55.436836 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 834, length 64 02:22:55.437878 ARP, Request who-has 192.168.10.6 tell 192.168.1.220, length 46Then tried to capture the reply to 192.168.10.6 (VPN-Client) in interface VPNPRIVATE but only found requests:```
02:25:05.583747 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 964, length 64
02:25:06.593409 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 965, length 64
02:25:07.601648 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 966, length 64
02:25:08.599407 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 967, length 64
02:25:09.585162 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 968, length 64Then tried to capture the reply to 192.168.10.6 (VPN-Client) in OpenVPN Server privateVPN but only found requests:``` 02:26:37.733693 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 1056, length 64 02:26:38.714398 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 1057, length 64 02:26:39.743110 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 1058, length 64 02:26:40.740434 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 1059, length 64 02:26:41.745515 IP 192.168.10.6 > 192.168.1.220: ICMP echo request, id 27659, seq 1060, length 64Seems there is no route back?
Diagnostic -> Show States gives the following (filtered by "192.168.1.220"):```
Proto Source -> Router -> Destination State
icmp 192.168.1.220:27659 <- 192.168.10.6 0:0
icmp 192.168.10.6:27659 -> 192.168.1.220 0:0Here's the IP V4 routes``` IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 217.0.116.247 UGS 0 70964 1492 pppoe0 8.8.4.4 217.0.116.247 UGHS 0 1655 1492 pppoe0 8.8.8.8 217.0.116.247 UGHS 0 76868 1492 pppoe0 xxx.xxx.xxx.xxx link#11 UHS 0 0 16384 lo0 127.0.0.1 link#10 UH 0 644 16384 lo0 192.168.1.0/24 link#1 U 0 985656 1500 dc0 192.168.1.221 link#1 UHS 0 0 16384 lo0 192.168.10.0/24 192.168.10.2 UGS 0 4 1500 ovpns1 192.168.10.1 link#12 UHS 0 0 16384 lo0 192.168.10.2 link#12 UH 0 0 1500 ovpns1 217.0.116.247 link#11 UH 0 0 1492 pppoe0 217.237.148.22 217.0.116.247 UGHS 0 3310 1492 pppoe0 217.237.150.51 217.0.116.247 UGHS 0 3310 1492 pppoe0The VPN Client ping gets no reply, while a ping from the pfSense host to both, the VPN Client and the LAN host gets answered. Sorry, I'm still lost here. I've never touched NAT or routes yet.
-
There seems to be a configuration problem on your LAN host (192.168.1.220) which assumes that your VPN host (192.168.10.6) is in the same network.
Are you using a statically assigned IP address? If so make sure the network mask is correct. -
Interesting. I'll definetely look into this. Host 192.168.1.220 is static IP with a netwask of 255.255.255.0, gateway 192.168.1.221 (pfSense).
Tried to ping another host from the VPN client. Same result - no reply - but different capture on pfSense interface LAN:```
11:44:01.080637 IP 192.168.1.100.49360 > 192.168.1.221.80: tcp 0
11:44:01.659639 IP 192.168.10.6 > 192.168.1.100: ICMP echo request, id 18184, seq 27, length 64
11:44:02.666382 IP 192.168.10.6 > 192.168.1.100: ICMP echo request, id 18184, seq 28, length 64
11:44:03.657112 IP 192.168.10.6 > 192.168.1.100: ICMP echo request, id 18184, seq 29, length 64
11:44:04.330064 IP 192.168.1.100.49360 > 192.168.1.221.80: tcp 668
11:44:04.330200 IP 192.168.1.221.80 > 192.168.1.100.49360: tcp 0
11:44:04.645066 IP 192.168.10.6 > 192.168.1.100: ICMP echo request, id 18184, seq 30, length 64
11:44:04.649932 IP 192.168.1.100.65498 > 224.0.0.252.5355: UDP, length 28
11:44:04.749957 IP 192.168.1.100.65498 > 224.0.0.252.5355: UDP, length 28 -
There seems to be a configuration problem on your LAN host (192.168.1.220) which assumes that your VPN host (192.168.10.6) is in the same network.
Yeah, this. Either the mask is not really 255.255.255.0, or the host may have an IP alias on 192.168.10.x. Something on that host makes it think 192.168.10.6 is local and it's not.
-
Many thanks for directing me to this. Host 192.168.220 did have a misconfiguration - broadcast 192.168.255.255 with netmask 255.255.255.0 - which did not raise a problem until a reboot - coincidently around the time of the pfSense upgrade.
Now ping is working from VPN clients to this host (and all VM's on this machine) but still a ping to the Windows 7 host 192.168.1.100 gets only answered inside the LAN, but that's obviously not related to pfSense.