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

    Openvpn Site-to-Site PKI Routing Help [SOLVED]

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 2.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.
    • H Offline
      hexfusion
      last edited by

      Hello I have setup a site to site connection between (2) 1.2.3-RELEASE boxes from VPN Client I can ping the VPN Sever's lan interface and vice versa.  The main office pfsense box is not the main gateway for the network.  My goal is to be able to bring the home office network into the domain and have shared folder resource access.  I currently have PKI setup but I have had the same problem with shared keyes.  My problem is a routing issue that to this point I can't seem to get right any help would be greatly appreciated.

      |–-GW1--|                            |---GW2--|              
      |-WAN 123.123.123.1-|   |-WAN 123.123.123.2->|<-192.168.10.0/24->|<-Home WAN 123.123.123.3->|
      |---LAN 192.168.3.3---|   |---VPN Server LAN 192.168.3.1---|                          |---LAN 192.168.6.1---|
                  |                                                      |                                                              |
      |---SWITCH---|------------------------------------------|                                                  |--Work Station--|
      |                                                                                                             
      |---Domain Controller 192.168.3.100--

      Main Office:
      Domain:office.local
      Windows DC,DNS:192.168.3.100
      WAN:123.123.123.1 (Static)
      LAN:192.168.3.1
      Network:192.168.3.0/24

      OPENVPN Server - PKI
      TCP Port: 1194
      Address Pool: 192.168.10.0/24
      Shared Key Blank
      All keys entered
      Client-to-client VPN checked
      LZO compression checked

      custom: route 192.168.6.0 255.255.255.0;push "route 192.168.3.0 255.255.255.0"

      Client-specific configuration
      home-office
      iroute 192.168.6.0 255.255.255.0

      ####################

      Home Office:
      DSL Modem :123.123.132.3 (Dynamic)

      Pfsensebox
      WAN:192.168.0.10 (DHCP from DSL Modem pfsense set as DMZ)
      LAN:192.168.6.1
      Network:192.168.6.0/24

      OPENVPN Client - PKI
      TCP Port: 1194
      Server Address:123.123.123.2
      LZO: enabled

      #####################

      #####################
      Currently the only rules I have setup for testing are:

      Main Office:
      LAN:
      Proto Source Port Destination Port Gateway Schedule Description

      • LAN net *               *  *         *         Default LAN -> any

      WAN:
      Proto Source Port Destination Port Gateway Schedule Description

      • Reserved/not assigned by IANA * * * * * Block bogon networks
        TCP/UDP * * * 1194 (OpenVPN) *   Allow OpenVPN
      1 Reply Last reply Reply Quote 0
      • J Offline
        joako
        last edited by

        1. You need to connect the pfsense LAN on both ends, not the WAN.
        2. Once that is correct, say you ping from your home to your office, your packets will be like such:
          Source: 192.168.6.0/24
          Destination: 192.168.3.0/24

        So far, so good your ICMP will reach the remote LAN no problems. Once it gets there, however, the host will sent the ICMP response to 192.168.10.0/24, again no problem, but since the traffic is not on your local subnet it will be sent to the default gateway. Your default gateway at this point will either drop the traffic or forward it to your ISP's default gateway which will then drop the traffic. Solution: setup static routes. These will tell your work LAN default gateway to route the VPN traffic to your pfSense VPN gateway instead of your WAN default gateway.

        So please respect the laws of subnetting, it's very simple, but like gravity there's no way to circumvent them. Shared key setup is fine unless you need more than 1 client connecting, keep it simple and avoid the hassles that PKI entails. Both are encrypted and are equally secure.

        1 Reply Last reply Reply Quote 0
        • H Offline
          hexfusion
          last edited by

          @joako:

          1. You need to connect the pfsense LAN on both ends, not the WAN.
          2. Once that is correct, say you ping from your home to your office, your packets will be like such:
            Source: 192.168.6.0/24
            Destination: 192.168.3.0/24

          So far, so good your ICMP will reach the remote LAN no problems. Once it gets there, however, the host will sent the ICMP response to 192.168.10.0/24, again no problem, but since the traffic is not on your local subnet it will be sent to the default gateway. Your default gateway at this point will either drop the traffic or forward it to your ISP's default gateway which will then drop the traffic. Solution: setup static routes. These will tell your work LAN default gateway to route the VPN traffic to your pfSense VPN gateway instead of your WAN default gateway.

          So please respect the laws of subnetting, it's very simple, but like gravity there's no way to circumvent them. Shared key setup is fine unless you need more than 1 client connecting, keep it simple and avoid the hassles that PKI entails. Both are encrypted and are equally secure.

          First of all thank you for your reply I am trying to wade through what you wrote here.  When you say I need to connect the PF LAN not the WAN isn't that how this is setup?  I see in the logs this connection which looks right and from the diagnostics section on each box I can ping the LAN interfaces.  So to me the connection is complete traffic flows fine though the 192.168.10.0/24 network and gets correctly routed to the 192.168.6.0/24 and 192.168.3.0/24 networks respectively.  So I think from what you said I did this right?  Second part is the static routes and I agree this is my issue.  I am going to have multiple connecting once I get this in production for now I am going to stick with PKI.

          
Nov 6 17:30:22 	openvpn[47500]: gw 123.123.123.100 [color](Same Gateway for both 123.123.123.1 and 123.123.123.2)[/color]
Nov 6 17:30:22 	openvpn[47500]: TUN/TAP device /dev/tun0 opened
Nov 6 17:30:22 	openvpn[47500]: /sbin/ifconfig tun0 192.168.10.1 192.168.10.2 mtu 1500 netmask 255.255.255.255 up [color]<--- I think this is correct [/color]
Nov 6 17:30:22 	openvpn[47500]: /etc/rc.filter_configure tun0 1500 1542 192.168.10.1 192.168.10.2 init 
Nov 6 17:30:23 	openvpn[47522]: UDPv4 link local (bound): [undef]:1194
Nov 6 17:30:23 	openvpn[47522]: UDPv4 link remote: [undef]
Nov 6 17:30:23 	openvpn[47522]: Initialization Sequence Completed
Nov 6 17:30:28 	openvpn[47522]: 123.123.123.3:1194 Re-using SSL/TLS context
Nov 6 17:30:28 	openvpn[47522]: 123.123.123.3:1194 LZO compression initialized
Nov 6 17:30:28 	openvpn[47522]: 123.123.123.3:1194 [home] Peer Connection Initiated with 123.123.123.3:1194

          In my server setup I have the following custom config routes, which are the reason I can ping the LAN interfaces.

          route 192.168.6.0 255.255.255.0;push "route 192.168.3.0 255.255.255.0"

          I assume the static routes should be on the VPN server side and in my mind I should send all traffic from 192.168.10.0/24 network to the 192.168.3.1 gateway is this on the right track?

          Tried all of these on the VPN Server PF

          
Interface  	Network  	Gateway  	Description
LAN  	 192.168.10.0/24  	 192.168.6.1 
LAN  	 192.168.6.0/24  	 192.168.10.2
LAN  	 192.168.6.0/24  	 192.168.10.1
          1 Reply Last reply Reply Quote 0
          • H Offline
            hexfusion
            last edited by

            I knew it was one line and I knew it was going to slap me when I figured it out.

            On GW1 (Cisco router) all I needed to do put a route that forwarded all 192.168.6.0/24 back to 192.168.3.1

            or

            ip route 192.168.6.0 255.255.255.0 192.168.3.1

            ;D

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