Site to site tunnel works for every second connection attempt from LAN hosts



  • I am new to this forum and this is my first post ever.

    I have setup a site to site tunnel using OpenVPN. The client side is pfSense 2.0.1 and the server side is pfSense 2.0.  From the client pfSense box, I can always ping the remote network.  From the LAN hosts on the OpenVPN client side, pinging the remote network succeeds in every other attempt. It is not only ping, any attempts to connect to the remote network behave this way.

    To connect a remote host, I have to connect twice. The first one always fails and the second one always succeeds.  The third one fails and the fourth one succeeds.  The pattern repeats forever.

    This only occurs when the client is pfSense. When I use dd-wrt as a client, the tunnel works reliably.

    Has anyone seen this behavior? What can I do to fix it?

    Thanks for your help!

    John



  • Did you ever figure this out?  I am having the same issue.  For me the issue started when when I created an openvpn server.  If I disable my newly created openvpn server and reboot pfsense my openvpn clients function properly again.  Enabling the server again breaks it and I am only able to connect through my vpn client on every other request as you have described.



  • do you have a gateway group that loadbalances ? do you have lan firewall rules that could somehow match the intended ovpn traffic ?



  • I do not have any gateway groups.  The only LAN firewall rule I have is "Default allow LAN to any rule" .



  • providing screenshot of the routes and possible packet capture could provide more insight.

    please check if the routes are different when it works vs when it doesn't work



  • I have attached my routes before and after enabling the pfsense vpn server.  The open vpn tunnel network is 192.168.254.0/24.

    Here is the packet capture trying to ping a machine over the vpn client.
    First set of pings did not work:
    16:15:21.189019 IP 192.168.254.1 > 10.0.2.14: ICMP echo request, id 57193, seq 0, length 64
    16:15:22.190481 IP 192.168.254.1 > 10.0.2.14: ICMP echo request, id 57193, seq 1, length 64
    16:15:23.191884 IP 192.168.254.1 > 10.0.2.14: ICMP echo request, id 57193, seq 2, length 64
    16:15:24.192455 IP 192.168.254.1 > 10.0.2.14: ICMP echo request, id 57193, seq 3, length 64

    crtl+c and started another ping that did work:
    16:15:26.055140 IP 10.24.1.6 > 10.0.2.14: ICMP echo request, id 51027, seq 0, length 64
    16:15:26.115971 IP 10.0.2.14 > 10.24.1.6: ICMP echo reply, id 51027, seq 0, length 64
    16:15:27.056570 IP 10.24.1.6 > 10.0.2.14: ICMP echo request, id 51027, seq 1, length 64
    16:15:27.116318 IP 10.0.2.14 > 10.24.1.6: ICMP echo reply, id 51027, seq 1, length 64
    16:15:28.058065 IP 10.24.1.6 > 10.0.2.14: ICMP echo request, id 51027, seq 2, length 64
    16:15:28.117807 IP 10.0.2.14 > 10.24.1.6: ICMP echo reply, id 51027, seq 2, length 64

    ![Screen Shot 2012-08-24 at 4.11.43 PM.png](/public/imported_attachments/1/Screen Shot 2012-08-24 at 4.11.43 PM.png)
    ![Screen Shot 2012-08-24 at 4.11.43 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-08-24 at 4.11.43 PM.png_thumb)
    ![Screen Shot 2012-08-24 at 4.12.53 PM.png](/public/imported_attachments/1/Screen Shot 2012-08-24 at 4.12.53 PM.png)
    ![Screen Shot 2012-08-24 at 4.12.53 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2012-08-24 at 4.12.53 PM.png_thumb)



  • as you can see in your routing table, the following routes are missing when it DOES NOT work:

    
    192.168.254.0/24
    192.168.254.1
    192.168.254.2
    

    Also, those packet captures don't make a lot of sense. From where to where were you pinging ?
    im asking because the capture have different source addresses (192.168.254.1 vs 10.24.1.6). Do you have any special nat rules in place that could cause this?

    The first one appears to go  from 192.168.254.1 TO 10.0.2.14 |  that would mean its from OVPN2-interface to client on other side of OVPN1
    The second one appears to go from 10.24.1.6 TO 10.0.2.14    | that would mean it is from OVPN1-interface to client on the other side of OVPN1

    Are you perhaps statically assigning ip-adresses to openvpn interfaces ? IF so: This is not recommanded

    kind regards



  • Static IP assignment shouldn't be an issue as long as you keep to the /30 subnets as per OpenVPN's default preference.  If it becomes an issue, use Network Topology in your server configuration, although, using pfsense as a server for openvpn is ok for one or two tunnels, it doesn't leverage the full power of OpenVPN unless you're willing to do some major work on the config files.  My suggestion would be to run a separate openvpn server and configure it accordingly.

    Cheers.

    -Percy
    http://swimminginthought.com



  • @pkwong:

    … although, using pfsense as a server for openvpn is ok for one or two tunnels

    Would you care to elaborate?

    Also according to this thread http://forum.pfsense.org/index.php/topic,51551.0/all.html jimp has "seen boxes with hundreds of clients connected, heard of boxes with even more"



  • pkwong I'd appreciate some clarifications about your previous comment regarding pfsense as OpenVPN server.

    It's not the first time you alluded to pfsense shortcomings when deploying more than a few OpenVPN tunnels, so some  specifics would be nice …



  • In a traditional OpenVPN server setting, you can have one port with multiple clients attached.  This is something pfSense currently isn't capable of.  I know I'd personally rather just manage one server rather than run multiple servers on different ports.  The only problem in that case would be shared key configs where you basically can only connect one client to one server (personally, to me, a waste of resources).  Even a free Amazon Instance can handle 7-10 clients very comfortably using AES encryption.

    Other features include Client Specific Directives (per client) on the same server.  Specialized routing, etc.  All powerful stuff.  All I'm saying is that pfSense is capable, but may not be the best solution as a VPN concentrator.  I know I'd rather have one port that 1000 clients can connect to rather than 1000 different instances of servers running. (but then again, that's just me).  For me, simplicity is key.  The deeper you understand a technology, the more you realize it's strengths and limitations.

    OpenVPN isn't exactly "easy to configure", but it's also not super complicated for someone with a clue about basic networking and PKI.  I think the last thing anyone wants to do is trouble-shoot 1000 different server instances on a server trying to figure out which one is broken and why.  It just adds to the complexity.  As of OpenVPN 2.2.x they've really refined it and made it a completely well thought out and solid product.

    One should consider the fact that running multiple servers on the machine = much more resource utilization than is really needed when you can run one server with client-specific directives.

    This is only one feature.  There are so many.  OpenVPN is like photoshop.  Nobody uses all the features.  If you did, you'd be lying.  It's incredibly complex and flexible.  The saving grace about the whole thing is it makes wonderful sense once you get the basics down.

    It's just a steep learning curve for the command-line phobic, but it's definitely something that makes a huge difference in the long-run.

    I'm sure we all know that can configure a server that may be less hardware powerful (CPU / DISK / RAM) to handle more traffic more efficiently than a poorly configured server.  It's not the technology (usually), it's the implementation of the technology and the individual use of the technology.

    I allude to many things in my post for one reason and one reason alone. I like to send people down the proper path and if they still run into a problem, I'll give them the solution.  I help people for free (I dedicate 10 hours a week doing this) and the other 60-70 working / writing, etc.

    I just believe that if you "Teach a man to fish, you feed them for life.. "



  • I'll probably make that my next book after I'm done writing the book I'm currently on.

    Cheers.

    -Percy
    http://swimminginthought.com



  • @pkwong:

    In a traditional OpenVPN server setting, you can have one port with multiple clients attached.  This is something pfSense currently isn't capable of.  I know I'd personally rather just manage one server rather than run multiple servers on different ports.

    I'm puzzled, because pfSense's OpenVPN is capable of multiple clients per OpenVPN-server instance on the same port … and Client Specific Directives etc.

    The webGUI can be somewhat limiting vs editing the text config files directly, however most of the commonly used functionality is present.



  • afaik i have multiple clients connecting to 1 ovpn instance without any hassle on a couple of pfsense devices, but perhaps i just got lucky =)


  • Rebel Alliance Developer Netgate

    Having multiple clients to one server works fine for SSL/TLS - it's Shared Key that can only effectively have one client.

    SSL/TLS can be used for both Remote Access and for Site-to-Site VPNs.
    Shared Key is really only practical for Site to Site, but in some rare cases might be OK for a single client remote access (but not recommended).



  • Pfsense's OVPN server can now handle multiple clients on the same port?  Cool :) good to know..  It's been a while since I've used OVPN as a server on a pfsense box.  I spoke out of turn then :)

    Cheers!


  • Rebel Alliance Developer Netgate

    Not "now" – it's always been that way.


Locked