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

    Site to Site VPN using pfSense + R7000

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 4 Posters 1.8k 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.
    • P
      pfsensen00b00
      last edited by

      Hi everyone,

      I've been struggling with this issue for some time, although I am relatively new to pfSense.

      In short, I am trying to establish a site to site VPN using the OpenVPN client built into my R7000 at one site and my pfSense running virtualized on Proxmox at another site. I'll detail the problems below, along with the network, device info, all of the ping-able IPs, etc.

      Any help would be greatly appreciated!

      Site A (Client)
      Netgear R7000 running the newest Xwrt-Vortex firmware
      Local IP network: 192.168.4.0/24
      Test computer: 192.168.4.100

      Site B (Server)
      pfSense running virtualized on Proxmox host with nics also virtualized using VirtIO drivers. I used the guide here: https://pve.proxmox.com/wiki/PfSense_Guest_Notes.
      Local IP network: 192.168.1.0/24
      Test computer: 192.168.1.100

      OpenVPN Configuration
      pfSense: http://imgur.com/UXNPVuX
      R7000: http://imgur.com/9Jqe3um

      OpenVPN Log
      pfSense: http://imgur.com/MJZWtON
      R7000:```
      May 27 18:17:28 openvpn[1738]: event_wait : Interrupted system call (code=4)
      May 27 18:17:28 openvpn[1738]: vpnrouting.sh tun12 1500 1561 10.0.8.2 10.0.8.1 init
      May 27 18:17:28 openvpn-routing: Configuring policy rules for client 2
      May 27 18:17:29 openvpn-routing: Flushing client routing table
      May 27 18:17:29 openvpn-routing: Completed routing policy configuration for client 2
      May 27 18:17:29 openvpn[1738]: Closing TUN/TAP interface
      May 27 18:17:29 openvpn[1738]: /usr/sbin/ip addr del dev tun12 local 10.0.8.2 peer 10.0.8.1
      May 27 18:17:29 openvpn[1738]: SIGTERM[hard,] received, process exiting
      May 27 18:17:30 dnsmasq[456]: read /etc/hosts - 5 addresses
      May 27 18:17:30 dnsmasq[456]: read /etc/hosts.dnsmasq - 15 addresses
      May 27 18:17:30 dnsmasq-dhcp[456]: read /etc/ethers - 15 addresses
      May 27 18:17:30 dnsmasq[456]: using nameserver xxxxxxx#53 for domain xxxxx
      May 27 18:17:30 dnsmasq[456]: using nameserver xxxxxxx#53 for domain xxxxx
      May 27 18:17:30 dnsmasq[456]: using nameserver xxxxxxx#53
      May 27 18:17:30 dnsmasq[456]: using nameserver xxxxxxx#53
      May 27 18:17:30 openvpn[11768]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
      May 27 18:17:30 openvpn[11768]: OpenVPN 2.4.2 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 17 2017
      May 27 18:17:30 openvpn[11768]: library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.08
      May 27 18:17:30 openvpn[11769]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
      May 27 18:17:30 openvpn[11769]: Outgoing Static Key Encryption: Cipher 'AES-128-CBC' initialized with 128 bit key
      May 27 18:17:30 openvpn[11769]: Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
      May 27 18:17:30 openvpn[11769]: Incoming Static Key Encryption: Cipher 'AES-128-CBC' initialized with 128 bit key
      May 27 18:17:30 openvpn[11769]: Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
      May 27 18:17:30 openvpn[11769]: TUN/TAP device tun12 opened
      May 27 18:17:30 openvpn[11769]: TUN/TAP TX queue length set to 100
      May 27 18:17:30 openvpn[11769]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
      May 27 18:17:30 openvpn[11769]: /usr/sbin/ip link set dev tun12 up mtu 1500
      May 27 18:17:31 openvpn[11769]: /usr/sbin/ip addr add dev tun12 local 10.0.8.2 peer 10.0.8.1
      May 27 18:17:31 openvpn[11769]: TCP/UDP: Preserving recently used remote address: [AF_INET]<pfsense wan="" ip="">:1194
      May 27 18:17:31 openvpn[11769]: Socket Buffers: R=[122880->122880] S=[122880->122880]
      May 27 18:17:31 openvpn[11769]: UDP link local: (not bound)
      May 27 18:17:31 openvpn[11769]: UDP link remote: [AF_INET]<pfsense wan="" ip="">:1194
      May 27 18:17:41 openvpn[11769]: Peer Connection Initiated with [AF_INET]<pfsense wan="" ip="">:1194
      May 27 18:17:44 openvpn-routing: Skipping, client 2 not in routing policy mode
      May 27 18:17:44 openvpn[11769]: Initialization Sequence Completed</pfsense></pfsense></pfsense>

      
      **The Problem**
      The VPN does come online, as seen from PFSense and the R7000\. There are two main problems:
      
      1\. If I keep a ping going from the pfSense router (192.168.1.1) to the R7000 (192.168.4.1) the VPN will stay up indefinitely. If I stop the ping, the VPN will close down a minute or so later.
      
      2\. I am unable to reach the remote network from any computer in either LAN. Pretty much only the routers can ping eachother, although there is an exception for the test computer on the R7000 side that can ping the internal OpenVPN IP of the pfSense router.
      
      **Ping-able IPs**
      **Test Computer (192.168.4.100)**
      Yes: 192.168.4.1
      Yes: 10.0.8.1
      Yes: 10.0.8.2
      No: 192.168.1.1
      
      **R7000**
      Yes: 10.0.8.1
      Yes: 10.0.8.2 (itself)
      No: 192.168.1.1
      
      **PFSense**
      Yes: 192.168.1.1 (itself)
      Yes: 192.168.4.1
      Yes: 10.0.8.2
      Yes: 10.0.8.1 (itself)
      
      **Test Computer (192.168.1.100)**
      Yes: 192.168.1.1
      Yes: 10.0.8.1
      No: 10.0.8.2
      No: 192.168.4.1
      1 Reply Last reply Reply Quote 0
      • K
        killmasta93
        last edited by

        have you done client overide for the DDWRT?

        Tutorials:

        https://www.mediafire.com/folder/v329emaz1e9ih/Tutorials

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

          Check your keepalive setting for problem 1.
          For problem 2 check your routes on each side. Assuming the routers are the default route for their respective LANs they should each have a route to the other LAN pointing to the OpenVPN address.

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            The NAT configuration on the R7000 side looks wrong. You probably do not want NAT there and you do want to define the networks if you expect to be able to directly-address the LAN on that side.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

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