Pfsense openvpn connecting problem



  • Guys
    I am running 2.1-RELEASE (i386) of it and I am also running windows 7 and everytime I try to connect to it I get this error "Connecting pfsense-udp-1194-vpn has failed".



  • Detail needed!!!
    How is your pfSense OpenVPN server setup…
    Do you have static public IP, or using Dynamic DNS name? And is the dynamic DNS name correctly pointing to your current public IP?
    Is port 1194 on your WAN open? (post WAN rules)
    Which client are you using on Windows (e.g. the one including OpenVPN Manager)?
    What is in server and client conf files?



  • How is your pfSense OpenVPN server setup…
    Do you have static public IP, or using Dynamic DNS name? And is the dynamic DNS name correctly pointing to your current public IP? This is on static IP not internal static IP
    Is port 1194 on your WAN open? (post WAN rules) I used the openvpn wizard to do this
    Which client are you using on Windows (e.g. the one including OpenVPN Manager)? I am using Openvpn GUI v5
    What is in server and client conf files? I used the Client Export option on openvpn tab

    I have tried this on 2 windows 7 machines it seems like its not working.

    Is there any guide for release 2.1 for pfsense for openvpn how to set it up correctly?



  • any help?



  • The final running server configuration is written in /var/etc/openvpn/server1.conf (depending how many servers you have set up, it might be server2, server3…). Post the contents of that (changing your public IP to some other numbers).
    also find the client.conf on your laptop (in C:\Program Files\OpenVPN\config - a folder something like that) and post it, again change your public IP before posting). But check that the public IP is the same in both files!
    And post the WAN rule you have to allow access to the OpenVPN server port. It should be similar to the attached.




  • Here is the server1.conf:

    dev ovpns1
    dev-type tun
    tun-ipv6
    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 udp
    cipher BF-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local 70.62.xx.xxx
    tls-server
    server 172.16.0.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    username-as-common-name
    auth-user-pass-verify /var/etc/openvpn/server1.php via-env
    tls-verify /var/etc/openvpn/server1.tls-verify.php
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 20
    push "route 192.168.60.0 255.255.255.0"
    push "dhcp-option DOMAIN nwxxxxx.com"
    push "dhcp-option DNS 8.8.8.8"
    push "dhcp-option DNS 8.8.4.4"
    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
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo
    persist-remote-ip
    float
    
    

    I dont have an option for client.conf at all. as you can see :



  • pfsense-udp-1194-vpn1.ovpn should be the client conf file. Post the sanitised text in that.
    The server conf file looks fine. As long as the client has the right matching stuff, and your ISP does not block port 1194, it should work!



  • This is from the .opvn

    dev tun
    persist-tun
    persist-key
    cipher BF-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote 70.62.55.xxx 1194 udp
    lport 0
    verify-x509-name "vpn1" name
    auth-user-pass
    pkcs12 pfSense-udp-1194-vpn1.p12
    tls-auth pfSense-udp-1194-vpn1-tls.key 1
    comp-lzo
    
    


  • Hmmm - no obvious problems there. You need to establish that connection packets from the client are actually arriving at the pfSense WAN port 1194. Do a packet capture on WAN while trying to connect from outside.
    You could also just check that a ordinary thing like ping will work to your public IP - add a rule on WAN to allow protocol ICMP, source any, destination WAN IP. Then from the client system outside, ping 70.62.55.xxx - at least that will tell you that the ISP is letting something through to your public IP.
    After that, try and find some more logs on the client with more detail than just "Connecting pfsense-udp-1194-vpn has failed".



  • Here is packet capture from inside of the pfsense:

    11:33:49.163708 IP 206.51.171.xxx.56519 > 70.62.55.xxx.443: tcp 0
    11:33:49.371754 IP 206.51.171.xxx.56519 > 70.62.55.xxx.443: tcp 0
    11:33:49.435251 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 11421, length 44
    11:33:49.435331 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 39072, length 44
    11:33:49.436866 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 39072, length 44
    11:33:50.445249 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 11677, length 44
    11:33:50.445338 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 39328, length 44
    11:33:50.446886 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 39328, length 44
    11:33:50.892333 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:33:51.455231 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 11933, length 44
    11:33:51.455322 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 39584, length 44
    11:33:51.456852 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 39584, length 44
    11:33:52.465223 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 12189, length 44
    11:33:52.465311 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 39840, length 44
    11:33:52.466869 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 39840, length 44
    11:33:53.475198 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 12445, length 44
    11:33:53.475285 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 40096, length 44
    11:33:53.476838 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 40096, length 44
    11:33:53.939212 IP 70.62.55.xxx.20339 > 74.125.192.125.5222: tcp 26
    11:33:53.981360 IP 74.125.192.125.5222 > 70.62.55.xxx.20339: tcp 0
    11:33:54.485186 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 12701, length 44
    11:33:54.485269 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 40352, length 44
    11:33:54.485875 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 40352, length 44
    11:33:55.357039 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:33:55.495162 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 12957, length 44
    11:33:55.495233 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 40608, length 44
    11:33:55.495827 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 40608, length 44
    11:33:56.505177 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 13213, length 44
    11:33:56.505260 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 40864, length 44
    11:33:56.506851 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 40864, length 44
    11:33:57.269435 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:33:57.515167 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 13469, length 44
    11:33:57.515255 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 41120, length 44
    11:33:57.516798 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 41120, length 44
    11:33:58.525142 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 13725, length 44
    11:33:58.525225 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 41376, length 44
    11:33:58.526781 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 41376, length 44
    11:33:59.535147 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 13981, length 44
    11:33:59.535232 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 41632, length 44
    11:33:59.536772 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 41632, length 44
    11:34:00.535708 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 14237, length 44
    11:34:00.535805 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 41888, length 44
    11:34:00.537341 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 41888, length 44
    11:34:01.545122 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 14493, length 44
    11:34:01.545208 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 42144, length 44
    11:34:01.546729 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 42144, length 44
    11:34:02.084724 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:34:02.555119 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 14749, length 44
    11:34:02.555206 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 42400, length 44
    11:34:02.556745 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 42400, length 44
    11:34:03.565088 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 15005, length 44
    11:34:03.565172 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 42656, length 44
    11:34:03.566712 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 42656, length 44
    11:34:03.838352 IP 70.62.55.xxx.19798 > 74.125.192.125.5222: tcp 26
    11:34:03.881635 IP 74.125.192.125.5222 > 70.62.55.xxx.19798: tcp 0
    11:34:04.575105 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 15261, length 44
    11:34:04.575193 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 42912, length 44
    11:34:04.576726 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 42912, length 44
    11:34:05.227069 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:34:05.585075 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 15517, length 44
    11:34:05.585164 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 43168, length 44
    11:34:05.586663 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 43168, length 44
    11:34:06.595086 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 15773, length 44
    11:34:06.595176 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 43424, length 44
    11:34:06.596701 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 43424, length 44
    11:34:06.971216 IP 70.62.55.xxx.44722 > 74.125.192.125.5222: tcp 26
    11:34:07.084968 IP 74.125.192.125.5222 > 70.62.55.xxx.44722: tcp 0
    11:34:07.299624 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
    11:34:07.605065 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 16029, length 44
    11:34:07.605153 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 43680, length 44
    11:34:07.606675 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 43680, length 44
    11:34:08.615055 IP 70.62.55.xxx > 172.16.0.2: ICMP echo request, id 35111, seq 16285, length 44
    11:34:08.615143 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo request, id 35385, seq 43936, length 44
    11:34:08.616665 IP 70.62.55.xxx > 70.62.55.xxx: ICMP echo reply, id 35385, seq 43936, length 44
    

    I can ping it after adding the rule but still cant connect via openvpn still getting :



  • I tried it on 2 different computers and they connect just fine I think its the problem with my windows 7 machine so I am uninstalling openvpn and reinstall in it to see if it corrects the problem.


  • Rebel Alliance Developer Netgate

    uninstall the client and tap driver, then reinstall making sure to use the latest client.

    Odds are, you have the 2.2.x OpenVPN windows client installed and not 2.3, so the verify-x509-name parameter is tripping it up.


Log in to reply