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

    Site-to-site tunnel working, routing not working

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 2.7k 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.
    • C
      caffreys
      last edited by

      I'm trying to connect two subnets which are both behind hardware routers. I've configured OpenVPN as per many good tutorials and made sure to forward UDP 1194 to respective pfsense boxes. The tunnel works straight away and survives reboots etc.

      Here's my config:
      Server network: 192.168.15.0/24
      HW Router IP: 192.168.15.1
      Pfsense LAN/WAP IP: 192.168.15.108
      PFSense Virt IP: 192.168.200.1

      Client network: 192.168.1.0/24
      HW Router IP: 192.168.1.1
      Pfsense LAN/WAP IP: 192.168.1.4
      PFSense Virt IP: 192.168.200.2

      So next I would like to route between subnets. As I have hardware routers I believe I need to create static routes to route each end's remote subnet through the pfsense boxes. On the server network I added a route for network 192.168.1.0/24 to 192.168.15.1 and on the client network I added a route for network 192.168.15.0/14 to 192.168.1.4. Unfortunately that didn't work on either side. Interestingly if I ping from either server or client pfsense console then I can reach the remote networks. If I run ping from web config it fails. In the web config it does appear as though the static routing is working properly:

      PING 192.168.15.1 (192.168.15.1) from 192.168.1.4: 56 data bytes
      92 bytes from D-Link.DSL2740B (192.168.1.1): Redirect Host(New addr: 192.168.1.4)
      Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
      4  5  00 0054 112f  0 0000  3f  01 d924 192.168.1.4  192.168.15.1

      92 bytes from D-Link.DSL2740B (192.168.1.1): Redirect Host(New addr: 192.168.1.4)
      Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst
      4  5  00 0054 1c78  0 0000  3f  01 cddb 192.168.1.4  192.168.15.1

      –- 192.168.15.1 ping statistics ---
      3 packets transmitted, 0 packets received, 100.0% packet loss

      So from what I can see the tunnel is working and if I ping from the console on either side I can contact the remote network. Anything outside of the console fails.

      Is there any other routing I need to do at the pfsense boxes?

      Thanks for your help.

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        Maybe these are just typos in your post, but the following look wrong to me. As I understand your post, the pfSense LANs are sitting on the ordinary private LAN at each end, along with the hardware routers. The pfSense WAN ports go nowhere. The hardware routers are the real internet gateway at each site. So each hardware router needs to know that to get to the other site, packets have to be sent "sideways" to the local pfSense, which will forward them over the VPN (which, with the 1194 port forwards on the hardware routers, can establish itself across the hardware routers).

        So next I would like to route between subnets. As I have hardware routers I believe I need to create static routes to route each end's remote subnet through the pfsense boxes. On the server network I added a route for network 192.168.1.0/24 to 192.168.15.1 and on the client network I added a route for network 192.168.15.0/14 to 192.168.1.4. Unfortunately that didn't work on either side.

        On server network, the hardware router at 192.168.15.1 needs to know that 192.168.1.0/24 is reached via 192.168.15.108 (the local pfSense).
        On client network, the hardware router at 192.168.1.1 needs to know that 192.168.15.0/24 is reached via 192.168.1.4

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

          Hi, yes this is all correct and the static routes on each router are indeed as per your suggestions. And the routing appears to work as you can see from the ping log. When I try to ping (from the client side) to the private lan's gateway on the server side at 192.168.15.1 this is forwarded to the local pfsense LAN IP 192.168.1.4. But that is as far as it gets. Either the local pfsense is not forwarding through the tunnel, or the other side is not forwarding to the remote lan or something else? And both sides fail the same way. And i've checked again that the tunnel is still up. And pinging at the pfsense console only still works.

          I would add that I have not set-up any routing in pfsense. Is there anything required to route between pf LAN IP and the private tunnel IP? Or is this done as part of the OpenVPN set-up?

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            When you enter Tunnel Network, Local Network and Remote Network it uses these to make a route to Remote Network across Tunnel Network for you. So when there is just 1 LAN subnet at each end, the routing happens "automatically".
            The extra things you have to do are;

            1. open the port you are using at the server end, so the client incoming connect can get through.
            2. Add firewall rule/s on OpenVPN at each end to allow the traffic you want that comes from the other end of the tunnel.
              Then it all just works in a simple site-to-site config.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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