Network from VPN Server unreachable through the Lan



  • Pfsense is the VPN-Client. From the pfsense console i get a ping form all machines in the server network. but when i try to connect from a machine behind the pfsense client the network is unreachable.

    it seems to me like a firewall problem.

    When i use port forwarding it is possible to connect so the service in die server network, but only if the IF is set to wan or ppoe. But this not the way i want to use vpn.

    Thanks for your help



  • I think I am experiencing the same problem.  Without a tun interface to play with, I cannot see the rules that are being applied.  I can access everything fine from inside the pfsense box but it will not pass traffic from the Lan side…  I did get it working a while ago by natting the tun interface but I dont think its a good fix.  I was wondering if anyone has a pfsense to pfsense vpn working properly.  Sorry I cant help but it might be nice to know that your not alone...



  • What version of pfSense are each of you running?  If the answer is not RC3 or better, update.

    Second, have you assigned your tun/tap to a pfSense interface?  If you have, stop it. :)  Delete that interface, and pfSense will automatically generate tun/tap any/any allow rules for you.

    Finally, if you are in a 3 network setup (ie, local net - tunnel net - remote net) make sure that each side of the tunnel has a route to the opposing network, otherwise traffic will not route!



  • It looks like on the server end, the routes get created when you fill in the remote network field.  As far as the client, it seems to blow up when you enter the route for the other network and get a operation denied error when you ping clients over the vpn.  You have to completely remove things restart and go again.  HELP!!!



  • Sorry, my mistake.

    I'm running RC3e (Updated a, b, c, d, e). The tun interface can not assigned any more. Because there seems to be a problem with the route-push option i had to add a static route on my pfsense-client to the servers network. The pfsense-client can ping to all machines in the server network. So the routes must be ok, don't they?
    But it's not possible to ping from the lan-side of the pfsense-client to the server or the server-network. May there a problem with the routes on the server side?

    Here my OVPN Log:

    Oct 11 19:05:18 openvpn[7640]: –- [SKD] Peer Connection Initiated with –-
    Oct 11 19:05:17 openvpn[92656]: Initialization Sequence Completed
    Oct 11 19:05:17 openvpn[92656]: Preserving previous TUN/TAP instance: tun0
    Oct 11 19:05:17 openvpn[92656]: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.6)
    Oct 11 19:05:16 openvpn[92656]: [server] Peer Connection Initiated with –-
    Oct 11 19:05:13 openvpn[7640]: TCPv4_SERVER link remote: –-
    Oct 11 19:05:13 openvpn[7640]: TCPv4_SERVER link local: [undef]
    Oct 11 19:05:13 openvpn[7640]: TCP connection established with –-
    Oct 11 19:05:13 openvpn[7640]: Re-using SSL/TLS context
    Oct 11 19:05:12 openvpn[92656]: TCPv4_CLIENT link remote: –-
    Oct 11 19:05:12 openvpn[92656]: TCPv4_CLIENT link local: [undef]
    Oct 11 19:05:12 openvpn[92656]: TCP connection established with –-
    Oct 11 19:05:12 openvpn[92656]: Attempting to establish TCP connection with –-
    Oct 11 19:05:12 openvpn[92656]: Re-using SSL/TLS context
    Oct 11 19:05:12 openvpn[92656]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
    Oct 11 19:05:12 openvpn[92656]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
    Oct 11 19:05:07 openvpn[92656]: SIGUSR1[soft,ping-restart] received, process restarting
    Oct 11 19:05:07 openvpn[92656]: [server] Inactivity timeout (–ping-restart), restarting



  • You do not assign the tun interface.  Search the forum, this has been beaten to death like a dead horse.



  • That i had't to assign a tun interface is clear to me.

    The routing problem is driving me crazy. When pfsense is the vpn-server the client can access the server net. it is not possible to connect to any system on the client side (same problem at the pfsense console). If pfsense is the client, it is not possible to connect from the server side to any system on the client side. But form the pfsense console it is possible to connect to all server side systems. But not from the lan behind the pfsense client. When i use nat (with IF pptp) i can forward some services into the client lan.

    I'm really confused now!

    This seems to be the reason why i had to add a static route when pfsense is the client:

    Oct 11 19:36:25 openvpn[72511]: Initialization Sequence Completed
    Oct 11 19:36:25 openvpn[72511]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
    Oct 11 19:36:20 openvpn[72511]: /etc/rc.filter_configure tun0 1500 1543 192.168.220.6 192.168.220.5 init
    Oct 11 19:36:20 openvpn[72511]: /sbin/ifconfig tun0 192.168.220.6 192.168.220.5 mtu 1500 netmask 255.255.255.255 up
    Oct 11 19:36:20 openvpn[72511]: TUN/TAP device /dev/tun0 opened
    Oct 11 19:36:20 openvpn[72511]: gw –-
    Oct 11 19:36:20 openvpn[72511]: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.6)
    Oct 11 19:36:19 openvpn[72511]: [server] Peer Connection Initiated with –-
    Oct 11 19:36:15 openvpn[72511]: TCPv4_CLIENT link remote: –-
    Oct 11 19:36:15 openvpn[72511]: TCPv4_CLIENT link local: [undef]
    Oct 11 19:36:15 openvpn[72511]: TCP/UDP: Dynamic remote address changed during TCP connection establishment
    Oct 11 19:36:15 openvpn[72511]: TCP connection established with –-



  • Your not going to like to hear this but I went with IPSEC vpn's instead.  The interface is much more reliable and pfsense's implementation will allow you to configure the server as a remote client portal.  All the pfsense clients connect as if they were a site to site and it takes care of all routes beautifully.  It doesnt matter if they are dynamic or static ip's with this conifig also.  I will keep checking with OVPN and hopefully they will have all the kinks worked out soon.


Log in to reply