Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN up but no traffic passing

    OpenVPN
    7
    23
    17.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      Reiner030
      last edited by

      what is your "latest" version? ;) … 2.0.3. or an actual snapshot of 2.1-BETA1 ?

      I had before upgrade to 2.0.3. the problem that my "old, stable" firewalls can't talk to my new BETA ones (connection was up but no traffic inside)...
      I think that was because they used different OpenVPN versions.

      Since I made the update they have now same version and connection works great with inside traffic.

      So it would be best to check your OpenVPN version on both sides and upgrade if necessary.

      1 Reply Last reply Reply Quote 0
      • B
        badserver
        last edited by

        My current version is 2.0.3, the distant end is StrongVPN's hardware. I'm not sure what they're running. I'm thinking of rolling back to an earlier release if I can't find a workaround.

        1 Reply Last reply Reply Quote 0
        • R
          Reiner030
          last edited by

          • you checked out their FAQ http://strongvpn.com/faq.shtml ?

          • too big time differences can provide "bad keys" like this ~
              TLS Error: local/remote TLS keys are out of sync: <remote ip="">:1194 [1]

          • you can increase verbose logging by writing option "verb 2" or "verb 3" into "Advanced" box.
              Then it should be possible to see remote OpenVPN version, too. ;)

          verb2 shows vor instance my (2.0.3 pfsense) version:
          openvpn[61445]: OpenVPN 2.2.2 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013

          • Copy&Paste is more readable then screenshots ;)

          Apr 29 20:57:02 openvpn[62042]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
          Apr 29 20:57:02 openvpn[62042]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
          Apr 29 20:57:02 openvpn[62042]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
          Apr 29 20:57:02 openvpn[62042]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
          Apr 29 20:57:02 openvpn[62042]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
          Apr 29 20:57:02 openvpn[62042]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 172.16.4.1 172.16.4.2'                **
          Apr 29 20:57:02 openvpn[62042]: VERIFY OK: depth=0, …
          Apr 29 20:57:02 openvpn[62042]: CRL CHECK OK: …
          Apr 29 20:57:02 openvpn[62042]: VERIFY SCRIPT OK: depth=0…
          Apr 29 20:57:01 openvpn[62042]: VERIFY OK: depth=1, …
          Apr 29 20:57:01 openvpn[62042]: CRL CHECK OK: …
          Apr 29 20:57:01 openvpn[62042]: VERIFY SCRIPT OK: depth=1…
          Apr 29 20:56:23 openvpn[62042]: Initialization Sequence Completed
          Apr 29 20:56:21 openvpn[62042]: [PAV-JWS1-ZWS8-Bridge] Peer Connection Initiated with <remote ip="">:1194

          ( ** interesting failure… perhaps this can be the reason why quagga routing won't setup as expected ? My Setup is on both sides 172.16.4.0/30 ...)</remote></remote>

          1 Reply Last reply Reply Quote 0
          • R
            Reiner030
            last edited by

            http://strongvpn.com/setup.shtml refers btw to http://forum.pfsense.org/index.php?topic=29944.0

            so you used all there given options yet which fits your needs?

            -Note 2: for ease, here are the "advanced configuration" options you can copy and paste: (remember to keep the trailing ; in place.) --->

verb 5;tun-mtu 1500;fragment 1300;keysize 128;redirect-gateway def1;persist-key;
            1 Reply Last reply Reply Quote 0
            • B
              badserver
              last edited by

              That's correct, I followed the steps given in http://forum.pfsense.org/index.php/topic,29944.0.html. I substituted some of their settings for the settings provided in the ovpn0xx.ovpn file. My verb is set to 5 right now, but when I get home I'll switch to 2 and re initiate the VPN and let you know. Thanks!

              1 Reply Last reply Reply Quote 0
              • R
                Reiner030
                last edited by

                mmh,

                ah sorry, yesterday was too late - mixed it with another post which had posted only 2 small pics from log…

                I think this line is the problem:
                Apr 27 13:13:32    openvpn[56942]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
                Apr 27 13:13:32    openvpn[56942]: TUN/TAP device /dev/tun1 opened

                can you fully stop/start the service without this error?

                Perhaps it's enough to kill the pid which is holding the tun device

                ovpns5: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
                options=80000 <linkstate>inet6 fe80::225:90ff:fe26:1f22%ovpns5 prefixlen 64 scopeid 0x6e
                inet 172.16.4.1 –> 172.16.4.2 netmask 0xffffffff
                nd6 options=43 <performnud,accept_rtadv>Opened by PID 3002

                => here by pid 3002 …  if not, then hopely a reboot helps...</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>

                1 Reply Last reply Reply Quote 0
                • B
                  badserver
                  last edited by

                  I've tried multiple reboots with no joy. When I stop and start the service this is what I get:

                  Apr 30 18:45:44 openvpn[1886]: Initialization Sequence Completed
                  Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 10.8.1.73 10.8.1.77 255.255.255.255
                  Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 128.0.0.0 10.8.1.77 128.0.0.0
                  Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 0.0.0.0 10.8.1.77 128.0.0.0
                  Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 98.158.127.42 192.168.1.1 255.255.255.255
                  Apr 30 18:45:42 openvpn[1886]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1562 10.8.1.78 10.8.1.77 init
                  Apr 30 18:45:42 openvpn[1886]: /sbin/ifconfig ovpnc1 10.8.1.78 10.8.1.77 mtu 1500 netmask 255.255.255.255 up
                  Apr 30 18:45:42 openvpn[1886]: TUN/TAP device /dev/tun1 opened
                  Apr 30 18:45:42 openvpn[1886]: ROUTE default_gateway=192.168.1.1
                  Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ip-win32 and/or --dhcp-option options modified
                  Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route-related options modified
                  Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route options modified
                  Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ifconfig/up options modified
                  Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: timers and/or timeouts modified
                  Apr 30 18:45:42 openvpn[1886]: PUSH: Received control message: 'PUSH_REPLY,ping 1,ping-restart 60,route-delay 2,route-metric 1,dhcp-option DNS 98.158.112.60,dhcp-option DNS 199.127.248.22,route 10.8.1.73,topology net30,ifconfig 10.8.1.78 10.8.1.77'
                  Apr 30 18:45:42 openvpn[1886]: SENT CONTROL [vpn-in26]: 'PUSH_REQUEST' (status=1)
                  Apr 30 18:45:40 openvpn[1886]: [vpn-in26] Peer Connection Initiated with 98.158.127.42:4672
                  Apr 30 18:45:40 openvpn[1886]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
                  Apr 30 18:45:40 openvpn[1886]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                  Apr 30 18:45:40 openvpn[1886]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                  Apr 30 18:45:40 openvpn[1886]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
                  Apr 30 18:45:40 openvpn[1886]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
                  Apr 30 18:45:36 openvpn[1886]: VERIFY OK: depth=0, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=vpn-in26/emailAddress=techies@reliablehosting.com
                  Apr 30 18:45:36 openvpn[1886]: VERIFY OK: depth=1, /C=US/ST=CA/L=San-Francisco/O=reliablehosting.com/CN=ovpn041/emailAddress=techies@reliablehosting.com
                  Apr 30 18:45:32 openvpn[1886]: TLS: Initial packet from 98.158.127.42:4672, sid=be10c338 72e02aff
                  Apr 30 18:45:32 openvpn[1886]: UDPv4 link remote: 98.158.127.42:4672
                  Apr 30 18:45:32 openvpn[1886]: UDPv4 link local (bound): 192.168.1.100:4672
                  Apr 30 18:45:32 openvpn[1841]: Expected Remote Options hash (VER=V4): '6a64613d'
                  Apr 30 18:45:32 openvpn[1841]: Local Options hash (VER=V4): '84ab6e17'
                  Apr 30 18:45:32 openvpn[1841]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 0,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
                  Apr 30 18:45:32 openvpn[1841]: Local Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
                  Apr 30 18:45:32 openvpn[1841]: Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
                  Apr 30 18:45:32 openvpn[1841]: Data Channel MTU parms [ L:1562 D:1450 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
                  Apr 30 18:45:32 openvpn[1841]: Socket Buffers: R=[42080->65536] S=[57344->65536]
                  Apr 30 18:45:32 openvpn[1841]: Control Channel MTU parms [ L:1562 D:166 EF:66 EB:0 ET:0 EL:0 ]
                  Apr 30 18:45:32 openvpn[1841]: LZO compression initialized
                  Apr 30 18:45:32 openvpn[1841]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
                  Apr 30 18:45:32 openvpn[1841]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
                  Apr 30 18:45:32 openvpn[1841]: Control Channel Authentication: using '/var/etc/openvpn/client1.tls-auth' as a OpenVPN static key file
                  Apr 30 18:45:32 openvpn[1841]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
                  Apr 30 18:45:32 openvpn[1841]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
                  Apr 30 18:45:32 openvpn[1841]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
                  Apr 30 18:45:32 openvpn[1841]: OpenVPN 2.2.2 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
                  Apr 30 18:45:32 openvpn[1841]: auth_user_pass_file = '[UNDEF]'
                  Apr 30 18:45:32 openvpn[1841]: pull = ENABLED
                  Apr 30 18:45:32 openvpn[1841]: client = ENABLED
                  Apr 30 18:45:32 openvpn[1841]: port_share_port = 0
                  Apr 30 18:45:32 openvpn[1841]: port_share_host = '[UNDEF]'
                  Apr 30 18:45:32 openvpn[1841]: ssl_flags = 0
                  Apr 30 18:45:32 openvpn[1841]: auth_user_pass_verify_script_via_file = DISABLED

                  1 Reply Last reply Reply Quote 0
                  • R
                    Reiner030
                    last edited by

                    mmh from log seems all ok…

                    interesting part should be:
                    @badserver:

                    Apr 30 18:45:44 openvpn[1886]: Initialization Sequence Completed
                    Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 10.8.1.73 10.8.1.77 255.255.255.255
                    Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 128.0.0.0 10.8.1.77 128.0.0.0
                    Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 0.0.0.0 10.8.1.77 128.0.0.0
                    Apr 30 18:45:44 openvpn[1886]: /sbin/route add -net 98.158.127.42 192.168.1.1 255.255.255.255
                    Apr 30 18:45:42 openvpn[1886]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1562 10.8.1.78 10.8.1.77 init
                    Apr 30 18:45:42 openvpn[1886]: /sbin/ifconfig ovpnc1 10.8.1.78 10.8.1.77 mtu 1500 netmask 255.255.255.255 up
                    Apr 30 18:45:42 openvpn[1886]: TUN/TAP device /dev/tun1 opened
                    Apr 30 18:45:42 openvpn[1886]: ROUTE default_gateway=192.168.1.1
                    Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ip-win32 and/or --dhcp-option options modified
                    Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route-related options modified
                    Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: route options modified
                    Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: –ifconfig/up options modified
                    Apr 30 18:45:42 openvpn[1886]: OPTIONS IMPORT: timers and/or timeouts modified
                    Apr 30 18:45:42 openvpn[1886]: PUSH: Received control message: 'PUSH_REPLY,ping 1,ping-restart 60,route-delay 2,route-metric 1,dhcp-option DNS 98.158.112.60,dhcp-option DNS 199.127.248.22,route 10.8.1.73,topology net30,ifconfig 10.8.1.78 10.8.1.77'
                    Apr 30 18:45:42 openvpn[1886]: SENT CONTROL [vpn-in26]: 'PUSH_REQUEST' (status=1)
                    Apr 30 18:45:40 openvpn[1886]: [vpn-in26] Peer Connection Initiated with 98.158.127.42:4672

                    • can you ping the other side?
                    • can you see with tcpdump traffic on your interface (tcpdump -ni ovpnc1) ?
                    1 Reply Last reply Reply Quote 0
                    • B
                      badserver
                      last edited by

                      Ok, sorry for the long delay. Moved to a new house and had to wait for internet setup.

                      So, I can not ping the other side and all tcpdump traffic shows my internal hosts going out with no return traffic.

                      1 Reply Last reply Reply Quote 0
                      • R
                        Reiner030
                        last edited by

                        @badserver:

                        So, I can not ping the other side and all tcpdump traffic shows my internal hosts going out with no return traffic.

                        Mmh, can you tcpdump other side, too? So that you can see that traffic goes out and perhaps come back?
                        I guess that on other side the back routes are missing. so that the remote side did not know where to route the traffic.

                        1 Reply Last reply Reply Quote 0
                        • B
                          badserver
                          last edited by

                          Unfortunately the distant end is a StrongVPN node so I have no way to do a dump on the other side. A co-worker is having the exact same symptoms but his worked fine before he upgraded to 2.0.3. I set mine up with 2.0.3 and it's never worked for me.

                          1 Reply Last reply Reply Quote 0
                          • R
                            Reiner030
                            last edited by

                            @badserver:

                            Unfortunately the distant end is a StrongVPN node so I have no way to do a dump on the other side. A co-worker is having the exact same symptoms but his worked fine before he upgraded to 2.0.3. I set mine up with 2.0.3 and it's never worked for me.

                            can you perhaps downgrade then to pfsense 2.0.2 ?

                            http://files.nyi.pfsense.org/mirror/downloads/old/

                            http://blog.pfsense.org/?p=694

                            "biggest" change could be the Version update:

                            • OpenVPN 2.2 stock again (Removed IPv6 patches since those are only needed on 2.1 now)

                            and

                            OpenVPN

                            *    Clear the route for an OpenVPN endpoint IP when restarting the VPN, to avoid a situation where a learned route from OSPF or elsewhere could prevent an instance from restarting properly
                            *    Always clear the OpenVPN route when using shared key, no matter how the tunnel network “CIDR” is set
                            *    Use the actual OpenVPN restart routine when starting/stopping from services rather than killing/restarting manually
                            *    Allow editing an imported CRL, and refresh OpenVPN CRLs when saving. [#2652]
                            *    Fix interface assignment descriptions when using > 10 OpenVPN instances

                            1 Reply Last reply Reply Quote 0
                            • ?
                              A Former User
                              last edited by

                              Have you done the Outbound NAT Rules ? It sounds to me that you missed that bit.

                              1 Reply Last reply Reply Quote 0
                              • B
                                badserver
                                last edited by

                                I won't have time to downgrade until later this week, but I will post the results once I do it.

                                Just out of curiosity, is there anyone out there that is running 2.0.3, connecting to StrongVPN (or any other commercial VPN provider) and routing traffic across it with no issues?

                                1 Reply Last reply Reply Quote 0
                                • R
                                  Reiner030
                                  last edited by

                                  no Idea… In knew someone who uses in his old company https://www.overplay.net/ for VPN connections...
                                  Perhaps you'll try an alternative to check if it's problematic only at StrongVPN.
                                  So this is the reason you can open ticket to StronVPN that there is a versions conflict in their system and hope they fix it quick or you switch to the functional alternative.

                                  1 Reply Last reply Reply Quote 0
                                  • C
                                    chevyn8
                                    last edited by

                                    After update, my openvpn is not usable (connect and not passing most of the traffic), looking for instructions to downgrade.  Using 3rd party and openvpn client.

                                    1 Reply Last reply Reply Quote 0
                                    • B
                                      badserver
                                      last edited by

                                      Alright, I finally got the time to downgrade to 2.0.2 and I'm having the same results. I'll download 2.0.1 and downgrade even further tomorrow, but right now it's not looking good.

                                      1 Reply Last reply Reply Quote 0
                                      • N
                                        nabil
                                        last edited by

                                        @badserver:

                                        Hi all,

                                        I'm stationed overseas and I'm trying to use pfSense with StrongVPN to access Hulu, netflix, etc. I've followed the steps outlined in forum.pfsense.org/index.php?topic=29944.0 and the VPN reports that it's up when I look at Status > OpenVPN. I've created an alias group to route only a few devices from my network out the StrongVPN connection and I've created firewall rules to handle the routing out. When I add my PC to that alias group I can't web browse at all and I'm also unable to ping the distant end virtual IP (i can ping the local virtual IP fine). Also, when doing a packet capture I can see my local virtual IP attempting to send traffic to the distant end with no response coming back. I thought it might be something with the StrongVPN server so I've already switched to a different server.

                                        Has anyone run into problems like this in the past? Any help would be greatly appreciated!

                                        I think I have the same problem as you. I am running pfsense 2.0.3. I followed several tutorials (swimminginthought one and the sticky one) and I still can not get it work properly as you mention. It is probably a question of openvpn version ?

                                        1 Reply Last reply Reply Quote 0
                                        • K
                                          kejianshi
                                          last edited by

                                          Are you running automatic or static outbound NAT?

                                          1 Reply Last reply Reply Quote 0
                                          • I
                                            ircman
                                            last edited by

                                            Hi Guy's,

                                            I'm having similar issues with pfsense 2.0.3.

                                            I'm using the OpenVPN Client software to setup a remote connection to my pfsense box and the VPN connection itself is up, some routes are being pushed to my client and I can ping the IP-address of the pfsense box itself.
                                            But all traffic going through the VPN to the internal systems (like RDP, ICMP etc.) are not passing through. When doing a Wireshark on the RDP-server and tcpdump on the pfsense box I see that the traffic is coming in via the VPN to the firewall, but not going out of the firewall to the RDP-server. Wireshark is not showing any incoming packets from the VPN client.
                                            So it seems that there maybe is a routing issue or that all VPN traffic is beeing blocked somehow.

                                            What I found out is that when configuring a clean pfsense 2.0.3 box the VPN connection is working and traffic is passing through to my RDP-server. But after rebooting the pfsense box, it does not work anymore.
                                            So something changes after rebooting the box.

                                            To answer on Kejianshi, i'm using automatic Outbound NAT Rule generation

                                            Regards,
                                            Cedric.

                                            C'est moi!

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.