Strange behavior. IP ending with .2 works, ending with .3 not.

  • Hey guys,

    I'm running an OpenVPN Server on a pfSense for road warriors. And I have a reeaally strange problem since a couple days:

    13:12:34.338995 IP > ICMP echo request, id 14, seq 1, length 32
    13:12:35.332080 IP > ICMP echo request, id 14, seq 2, length 32
    13:12:36.331939 IP > ICMP echo request, id 14, seq 3, length 32
    13:12:51.894961 IP > ICMP echo request, id 2, seq 1214, length 40
    13:12:51.894967 IP > ICMP echo reply, id 2, seq 1214, length 40
    13:12:52.913033 IP > ICMP echo request, id 2, seq 1215, length 40
    13:12:52.913036 IP > ICMP echo reply, id 2, seq 1215, length 40
    13:12:53.913385 IP > ICMP echo request, id 2, seq 1216, length 40
    13:12:53.913389 IP > ICMP echo reply, id 2, seq 1216, length 40

    When I'm connecting to the VPN as the first client, recieving IP, it works flawless. However, when I'm connecting and recieve the IP, it stops working. I can't even get a replay from the VPN Gateway ( or anything.

    This happens on multiple devices, with multiple configs. I even created a second roadwarrior vpn by the wizard, with a different transport network and it still doesnt work for the IP ending with .3.

    I have checked the logs when logging in, it all looks the same, for both IPs, and it shouldn't work ever, if theres a wrong configuration I guess.

    I have firewall rules to pass any on the openvpn Interface and the corresponding road warrior interface.

    I hope someone has an idea :)


  • LAYER 8 Rebel Alliance

    Show your OpenVPN settings and Firewall Rules (screenshots).
    Do you maybe share the same cert for all Users in SSL/TLS mode?


  • hey Rico,

    here are the screenshots
    0_1552308094091_ovpn settings.png

    0_1552308080123_client export.png




    thank you for your time :)

  • LAYER 8 Rebel Alliance

    Looks OK to me.
    How about the routing table?
    I see you added the OpenVPN RAS as Interface...did you maybe add any strange setting to this interface?


  • Routing tables
    Destination        Gateway            Flags     Netif Expire
    default            ......167.145     UGS         ix1     .....167.145     UGHS        ix1         link#11            UHS         lo0         link#11            UH       ovpns2         link#17            UHS         lo0         link#17            UH       ovpns6         link#14            UHS         lo0         link#14            UH     ipsec100       link#1             U           ix0        link#1             UHS         lo0       link#13            UHS         lo0       link#13            UH       ovpns1       link#15            UHS         lo0       link#15            UH       ovpns4       link#12            UHS         lo0       link#12            UH       ovpns3       UGS      ovpns5       link#16            UHS         lo0       link#16            UH       ovpns5     UGHS        ix1          link#8             UH          lo0         UGS    ipsec100       UGS      ovpns1       UGS      ovpns1       UGS      ovpns1         UGS      ovpns2       UGS      ovpns4         UGS      ovpns6
    traceroute to (, 64 hops max, 40 byte packets
     1  .....167.145 (.....167.145)  1.333 ms  39.956 ms  0.322 ms
     2 ***
    [2.4.4-RELEASE][root@FW01.corp]/root: traceroute
    traceroute to (, 64 hops max, 40 byte packets
     1 (  11.706 ms  10.196 ms  9.799 ms
    [2.4.4-RELEASE][root@FW01.corp]/root: traceroute
    traceroute: findsaddr: failed to connect to peer for src addr selection.

    When I add a static route ( via it says "failed to connect to peer for src addr selection." upon tracerouting. Without the static route it simply tries to route that through the ISP Gateway (...167.145), instead of the OpenVPN one

    dev ovpns3
    verb 0
    dev-type tun
    dev-node /dev/tun3
    writepid /var/run/
    #user nobody
    #group nobody
    script-security 3
    keepalive 10 60
    proto udp4
    cipher AES-128-CBC
    auth SHA256
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/
    client-disconnect /usr/local/sbin/
    local .....167.150
    client-config-dir /var/etc/openvpn-csc/server3
    verify-client-cert none
    plugin /usr/local/lib/openvpn/plugins/ /usr/local/sbin/ovpn_auth_verify_async user Y29ycC5pbm5vdmFtYXh4LmRl false server3 1196
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'vpn.corp.......' 1"
    lport 1196
    management /var/etc/openvpn/server3.sock unix
    push "route"
    push "dhcp-option DOMAIN corp.......
    push "dhcp-option DNS"
    push "dhcp-option DNS"
    push "dhcp-option DNS"
    ca /var/etc/openvpn/
    cert /var/etc/openvpn/server3.cert
    key /var/etc/openvpn/server3.key
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server3.tls-auth 0
    comp-lzo adaptive
    topology subnet

    Basically it's really just the IP. works without problems. On any device. As soon as a device gets the or higher, it just doesn't work anymore. If the device had .2 before, it worked during that time too, but up until it gets the .3

  • I also noticed, when I create a new server on a different port, with the exact settings (wich worked before all this began to happen), and that new server also has the exact same problem. I created a tunnel network, and as soon as someone gets the .3 or higher, it doesnt work.

  • LAYER 8 Rebel Alliance

    Any overlapping IPsec networks?


  • No there were not.

    I have deleted everything related to the RoadWarrior Server now and recreated it with another cipher, but same settings/TunnelNetwork/Buffer/Rules. It seems to work now. Could it be that pfSense sometimes doesn't activate rules unless you recreate them? It felt like that, though I dont really know why it didn't work and now works.