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

    [SOLVED] - Traffic over OpenVPN tunnel doesn't pass

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    4 Posts 2 Posters 8.4k Views
    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.
    • M
      mtx
      last edited by

      Hello community,

      First of all thank you for this great piece of work called pfSense. It's awesome and
      feature rich. I have been using it (2.0) for a couple of months now and didn't have any kind
      of problems until today.

      Today in the morning I have updated my office firewall using System: Firmware: Autoupdate.
      The system updated to: Sun Apr 10 21:49:29 EDT 2011.

      I have a Site to Site OpenVPN server setup on this system. The tunnel is made with a FreeBSD
      system (8.1-STABLE) running OpenVPN:

      # openvpn --version
      OpenVPN 2.1.3 amd64-portbld-freebsd8.1 [SSL] [LZO2] built on Oct 21 2010
      Originally developed by James Yonan
      Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net></sales@openvpn.net>
      

      The OpenVPN configuration on both sides is basic, push route with subnet behind pfSense
      to the FreeBSD box and vice versa. The subnet I used for OpenVPN is 10.11.12.0/29. pfSense
      ovpns1 interface has 10.11.12.1 –> 10.11.12.2 and FreeBSD ovpnc1 has 10.11.12.6 --> 10.11.12.5

      LAN (172.16.0.0/24) ------ [pfSense] (ovpns1) –--- (ovpnc1) [FreeBSD] –---- Remote LAN (172.31.30.0/24)

      pfSense# ifconfig ovpns1
      ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
              options=80000 <linkstate>inet6 fe80::21b:21ff:fe95:9c2%ovpns1 prefixlen 64 scopeid 0x10 
              inet 10.11.12.1 --> 10.11.12.2 netmask 0xffffffff 
              nd6 options=3 <performnud,accept_rtadv>Opened by PID 9746</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast> 
      
      FreeBSD# ifconfig ovpnc1
      ovpnc_a2a1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
              options=80000 <linkstate>inet 10.11.12.6 --> 10.11.12.5 netmask 0xffffffff 
              Opened by PID 16149</linkstate></up,pointopoint,running,multicast> 
      

      After update the VPN tunnel isn't working anymore. I can't ping from LAN to Remote LAN.
      Although I can ping the IP address of the tunnel from both ends.

      
      pfSense# ping 10.11.12.6
      PING 10.11.12.6 (10.11.12.6): 56 data bytes
      64 bytes from 10.11.12.6: icmp_seq=0 ttl=64 time=19.788 ms
      64 bytes from 10.11.12.6: icmp_seq=1 ttl=64 time=19.746 ms
      
      
      
      FreeBSD# ping 10.11.12.1
      PING 10.11.12.1 (10.11.12.1): 56 data bytes
      64 bytes from 10.11.12.1: icmp_seq=0 ttl=64 time=22.062 ms
      64 bytes from 10.11.12.1: icmp_seq=1 ttl=64 time=19.633 ms
      
      

      And what is strange, at least for me, is that I can ping from the FreeBSD box
      a machine located in LAN behind pfSense:

      
      FreeBSD# ping 172.16.0.77 
      PING 172.16.0.77 (172.16.0.77): 56 data bytes
      64 bytes from 172.16.0.77: icmp_seq=0 ttl=63 time=20.816 ms
      64 bytes from 172.16.0.77: icmp_seq=1 ttl=63 time=168.055 ms
      
      

      I can't ping any machine located in Remote LAN from the pfSense box:

      
      pfSense# ping 172.31.30.14
      PING 172.31.30.14 (172.31.30.14): 56 data bytes
      [...] NO OUTPUT [...]
      
      

      If I start a tcpdump on the ovpns1 interface of pfSense I can see traffic going
      to the tunnel endpoint but no traffic coming back.

      
      pfSense# tcpdump -eni ovpns1
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on ovpns1, link-type NULL (BSD loopback), capture size 96 bytes
      14:17:40.802869 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 69, length 64
      14:17:41.803846 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 70, length 64
      14:17:42.804833 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 71, length 64
      14:17:43.805805 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 72, length 64
      14:17:44.806774 AF IPv4 (2), length 88: 10.11.12.1 > 172.31.30.14: ICMP echo request, id 35652, seq 73, length 64
      
      

      How can I debug this problem further? The tunnel was working properly before the morning
      update.

      Thank you,
      v

      1 Reply Last reply Reply Quote 0
      • M
        mtx
        last edited by

        Hello again,

        I have udpated pfSense to

        
        pfSense# cat /tmp/pfSense_version
        Mon Apr 11 17:11:38 EDT 2011
        
        

        Still the problem persists. The tunnel is up but no traffic goes across from
        pfSense to FreeBSD. Ping from FreeBSD tunnel endpoint to any IP behind pfSense works fine.
        I have also updated openvpn on the FreeBSD box to latest openvpn from ports thinking
        it might have something to do with this.

        
        FreeBSD# openvpn --version
        OpenVPN 2.1.4 amd64-portbld-freebsd8.1 [SSL] [LZO2] built on Jan 21 2011
        Originally developed by James Yonan
        Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net></sales@openvpn.net> 
        

        I also have another pfSense box located in a remote location that has a tunnel setup
        with the pfSense box from the office. Same problem there too, tunnel set up just
        fine, no traffic goes across except ping from endpoint to endpoint.

        The firewall rules on OpenVPN interface on both pfSense boxes and FreeBSD box
        are set to pass everything.

        Once again, please tell me what can I do to find the problem?

        Thank you,
        v

        1 Reply Last reply Reply Quote 0
        • M
          mtx
          last edited by

          Hello again,

          I have solved the problem. Guess what? The problem was located between the
          monitor and the chair :).

          For future reference and for the sake of solving it I will post what happened.

          [Subnet A] –---- [pfSense] (ovpns1) –------------ (ovpnc1) [FreeBSD] –------- [Subnet B]

          My problem was that I couldn't get traffic across from subnet A to subnet B.
          Digging around I have found out that OpenVPN Server on pfSense was not
          properly configured.

          If you want to reach a client Subnet, in my case Subnet B, you need to reference a client
          config directory (client-config-dir) on the server and have a file (name of the file is the common name of the client)
          for each client you want to apply certain configurations to. In order to reach a Subnet that's behind a client you have
          to make use of iroute A.A.A.A N.N.N.N in the client's particular file.

          To make per client configuration in pfSense you can access VPN -> OpenVPN: Client Specific Override and
          add client specific overrides. So I have added an override for my client specifying iroute Subnet B in Advance
          box and everything works.

          Anyway I don't really understand how could it work before yesterday's update. Was it supposed to work
          that way (without iroute for each client)? From what I have read on OpenVPN website it shouldn't / doesn't work
          without iroute.

          I am very glad that I could solve the issue by my self :). If you ever have troubles with anything just
          turn on debug logging and for sure you can spot what's going wrong.

          A great day,
          v

          1 Reply Last reply Reply Quote 0
          • Z
            Zebble
            last edited by

            Nicely done mtx!  I was having exactly the same issue.  I (wrongly) assumed that the ccd settings were being automagically set by pfSense.  Having used OpenVPN for quite a while, and being used to creating ccd files, I'm surprised I missed this!

            Thanks!

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