[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 443

    
    Here'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 pppoe0
    
    

    The 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 DOWN

    while 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 init
    

    OpenVPN 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 context

    
    Attached 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.
    
    ![Interfaces.png_thumb](/public/_imported_attachments_/1/Interfaces.png_thumb)
    ![Interfaces.png](/public/_imported_attachments_/1/Interfaces.png)
    ![Firewall_LAN.png](/public/_imported_attachments_/1/Firewall_LAN.png)
    ![Firewall_VPNPRIVATE.png](/public/_imported_attachments_/1/Firewall_VPNPRIVATE.png)
    ![Firewall_OpenVPN.png_thumb](/public/_imported_attachments_/1/Firewall_OpenVPN.png_thumb)
    ![Firewall_LAN.png_thumb](/public/_imported_attachments_/1/Firewall_LAN.png_thumb)
    ![Firewall_VPNPRIVATE.png_thumb](/public/_imported_attachments_/1/Firewall_VPNPRIVATE.png_thumb)
    ![Firewall_OpenVPN.png](/public/_imported_attachments_/1/Firewall_OpenVPN.png)


  • 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 ms
    

    System 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 IGMP

    
    Then 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 	IGMP
    

    A 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 tun0

    
    I 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]
    
    ![Log_ICMP_on_LAN.png](/public/_imported_attachments_/1/Log_ICMP_on_LAN.png)
    ![Log_ICMP_on_LAN.png_thumb](/public/_imported_attachments_/1/Log_ICMP_on_LAN.png_thumb)
    ![Log_ICMP_on_LAN_edit.png](/public/_imported_attachments_/1/Log_ICMP_on_LAN_edit.png)
    ![Log_ICMP_on_LAN_edit.png_thumb](/public/_imported_attachments_/1/Log_ICMP_on_LAN_edit.png_thumb)


  • 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 46

    
    Then 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 46
    

    Then 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 64

    
    Then 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 64
    

    Seems 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:0

    
    Here'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 	pppoe0 	 
    

    The 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



  • @bardelot:

    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.


Log in to reply