• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 Offline
    mtx
    last edited by Apr 12, 2011, 12:53 PM Apr 11, 2011, 11:20 AM

    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 Offline
      mtx
      last edited by Apr 12, 2011, 7:26 AM

      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 Offline
        mtx
        last edited by Apr 12, 2011, 1:15 PM

        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 Offline
          Zebble
          last edited by Jun 14, 2011, 4:46 AM

          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.
            This community forum collects and processes your personal information.
            consent.not_received