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

redirect-gateway def1; Routing Traffic from Subnet through OpenVPN

Scheduled Pinned Locked Moved OpenVPN
3 Posts 1 Posters 3.3k 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.
  • S
    Scampicfx
    last edited by Scampicfx Jan 23, 2020, 4:59 PM Jan 23, 2020, 4:36 PM

    Hey guys,

    I followed this article exactly:

    https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/routing-internet-traffic-through-a-site-to-site-openvpn-connection-in-pfsense-2-1.html

    And everything is working fine!

    However: The command (client-side)...

    redirect-gateway def1
    

    ... means it sends ALL traffic through this vpn tunnel. I only want the traffic from one SPECIFIC subnet routed through this VPN tunnel. Is there any way to achieve that?

    1 Reply Last reply Reply Quote 0
    • S
      Scampicfx
      last edited by Jan 23, 2020, 11:39 PM

      Hey guys,

      finally I got this problem (and https://forum.netgate.com/topic/149785/packets-don-t-get-answered-correctly-via-openvpn ) solved. @viragomann has helped a lot in solving this. I would like to say a big thank you again!

      Maybe when you are reading you are stuck in the same problem? I would like to sum up all important points - maybe it helps you solving your issue!

      What is my goal?
      I would like to route only traffic from one specific local subnet through OpenVPN tunnel.

      What basic steps are necessary?
      First of all, be sure that both sites are connected to each other using OpenVPN tunnel. You may follow exactly the steps described in the link above ( https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/routing-internet-traffic-through-a-site-to-site-openvpn-connection-in-pfsense-2-1.html ). It is important to define NAT outbound rules at the remote site. This is described in the doc as well!

      When you strictly follow the guide, towards the end you are requested to define redirect-gateway def1 as custom option of your local pfsense. First of all, this command means that all traffic gets routed through the OpenVPN tunnel. Yes, every subnet - even it is has nothing to do with the OpenVPN tunnel itself. And that's not the solutoin I wanted to achieve! So don't use redirect-gateway def1!

      What steps are necessary to get this working?
      When I used google I often noticed other solutions that used net_gateway and route commands. None of them helped at my problem.
      The key word in solving the problem was policy based routing. When you have configured your pfsenses as described in the link above, then the only thing you need to do is add one additional firewall rule, which matches the affected traffic you want to route through the tunnel and change the gateway of this traffic to the openvpn interface.
      Important: You have to define interface for your openvpn connection at both sides. This is easily done via "Interfaces -> Assignments".

      The firewall rule you have to set:
      Go to Firewall -> Rules and at the top select your subnet which you would like to get forwarded, in this example it is OPT3:
      Click "Add" to create a new firewall rule.

      Action: Pass
      Interface: [The Interface of the subnet you would like to get forwarded: OPT3]
      Adress family: IPv4
      Protocol: Any
      Source: [OPT3 net]
      Destination: any
      Scroll down and click on "Advanced"
      At "Gateway" select the Interface of your OpenVPN connection to the remote side.

      That's it!

      The good thing about policy-based routing is, that you also can select more granular which traffic shall be forwarded. So maybe you don't want that every traffic of this specific subnet gets routed? You only want some specific ports to get sent via the tunnel? Then policy-based routing is a good choice for you :)

      Thanks again @viragomann

      1 Reply Last reply Reply Quote 0
      • S
        Scampicfx
        last edited by Jan 24, 2020, 6:21 PM

        Hey guys,

        I have to admit, I thought this issue was solved. However, it is not!

        At Local Site:
        When a connection is initiated from inside (e.g. I am trying to access google.de using Chrome) then my complete traffic gets routed via VPN tunnel. Back and Forth! Everything! Good!

        However, when a connection is initiated from outside (e.g. someone is trying to access a service) then the traffic from the outside gets routed from Remote Site to Local Site. There, the service "answers" the requests from outside, however the local pfsense just does not send this packets again through the tunnel. All packets want to leave WAN at local site - not at remote site! However, they should leave at remote site ! and not at local site!

        I can see this clearly when looking at packet capture.

        Following example:
        I visit https://www.yougetsignal.com/tools/open-ports/
        I enter the host address of remote site and the port, which gets forwarded through the tunnel.
        I click "check"

        Then I go to pfsense -> Packet Capture at Local Site and monitor.

        I can clearly see that all answer-packets leave at WAN interface! However, they should get routed through the VPN tunnel and leave the WAN interface of the remote site!

        I have clearly defined a firewall rule at local site:
        Unbenannt.JPG

        At remote site I have configured Outbound NAT. But I think the problem right now is local site, because there the packets want to leave via WAN interface. However, they should get sent into the tunnel.

        Does anyone have an idea what's the problem?

        1 Reply Last reply Reply Quote 0
        3 out of 3
        • First post
          3/3
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
          This community forum collects and processes your personal information.
          consent.not_received