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

    Routing openVPN traffic through specific ipsec tunnels

    Scheduled Pinned Locked Moved
    OpenVPN
    6
    18
    18.7k
    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.
    • E
      eblaster101
      last edited by

      Hi Everyone,

      We currently provide IT services to small businesses, one of my aims was to create a network in which we can support our users with ease.

      https://dl.dropboxusercontent.com/u/858614/network.png

      Currently I have customers with Juniper SSG5s who are successfully connected to the pfsense via IPSEC site to site VPNs

      I can ping all my customers devices through the Pfsense network (great!)

      I have configured openVPN and have also got that working so I can access my pfsense router and the server associated with it.

      I want to be able to able to give myself openvpn access in which I can still reach my customers machines. Any help is appreciated.

      Customers:
      172.10.2.0/24 (connected via ipsec site to site to pfsense)
      172.10.3.0/24 (connected via ipsec site to site to pfsense)
      172.10.4.0/24 (connected via ipsec site to site to pfsense)
      etc

      pfsense network
      172.5.1.0/24

      openVPN
      10.0.8.0/24

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

        I think you need to add "push route 172.10.0.0 255.255.0.0" to your openVPN server config advanced settings.  That will add a route to your clients that says to send all traffic for 172.10.0.0/16 back through OpenVPN.

        You then have to add a route to your IPsec clients telling them that 10.0.8.0/24 and possibly 172.5.1.0/24 should be sent out the ipsec tunnel.

        (You do realize that 172.5.X.X and 172.10.X.X are not private IPs right?  Those are 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12, or 172.16.0.0 - 172.31.255.255.  I would fix that while your network is small.)

        They are allocated to: AT&T Internet Services SIS-80-8-2012 (NET-172-0-0-0-1) 172.0.0.0 - 172.15.255.255

        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
        • M
          marvosa
          last edited by

          This has been discussed before.  Someone correct me if I'm wrong, but in addition to pushing routes for your ipsec tunnels to your openvpn clients, you will also need to tell your ipsec clients how to route back to your road warrior clients… i.e. create a 2nd phase 2 entry in each ipsec tunnel for your openvpn tunnel network (10.0.8.0/24).

          I also second Derelict on your LAN scope... why are you using public IP's in your LAN?

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

            I'm not sure if reply-to in pf will take care of the return traffic or not.  Probably not and another phase 2 route will be required as stated.

            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
            • E
              eblaster101
              last edited by

              thanks for the advise guys, i will try creating a second tunnel and see how i get on.

              I never realised i was using public IP addresses, i used to work for a large company which i believed had a good set-up so i copied everything they did. Never realised the mistake. Will rectify it.

              They had a really good SSTP VPN configuration. They had around 400 customers with AD servers all linked to one master DC, so all customer DCs were RODC. Any changes they wanted to make were done at high level and filtered down.

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

                thanks for the advise guys, i will try creating a second tunnel and see how i get on.

                You don't need a second tunnel.  Just another route over the existing one.

                i used to work for a large company which i believed had a good set-up

                Funny how a lot of windows guys didn't know what an RFC was until it was too late.

                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
                • E
                  eblaster101
                  last edited by

                  I have had a look at old threads asking for the same thing and they all mention creating another tunnel. I have tried creating a second phase2 tunnel but it just fails to connect and for some reason the small play button near it wont appear.

                  As soon as i change the phase2 local network entry from LAN subnet to a manual network (10.0.8.0/24) the small play button disappears. I have entered the opposing entries on the juniper

                  derelict if i upload the config would you able to tell me the route i need so i can try that?

                  Thank you

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

                    When I was talking about a route I was talking about another phase 2.  Poor choice of words.

                    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
                    • C
                      cmb
                      last edited by

                      You need that second phase 2 on both sides. You won't get a "start" button on the IPsec status page for any phase 2 where the firewall doesn't have a local IP on that subnet on an interface, as all that button does is trigger a ping to something within the remote subnet to cause the tunnel to attempt to negotiate. Just initiate some traffic from a client matching the additional P2 to bring it up.

                      1 Reply Last reply Reply Quote 0
                      • E
                        eblaster101
                        last edited by

                        Thanks guys it worked! :)

                        I added the second phase2 as you said, and added a manual route to the clients network on my desktop (connected via openvpn) and started pinging it and it came up.

                        Thank you for all your help, now I need to go change all these public addresses to private :(

                        1 Reply Last reply Reply Quote 0
                        • T
                          treuss
                          last edited by

                          Hi everyone,

                          we're currently building an OpenVPN infrastructure very similar to what @eblaster101 described initially.
                          In our scenario, there are 5 networks and a number of road warriors who need VPN access to these 5 networks:

                          192.168.75.0/24 is the network our road warriors will connect to via OpenVPN.
                          192.168.220.0/24 is the OpenVPN tunnel network.

                          192.168.71.0/24,
                          192.168.72.0/24,
                          192.168.73.0/24 and
                          192.168.74.0/24 are connected to 192.168.75.0/24 using IPsec site-to-site tunnels.

                          Here's a little sketch: https://db.tt/6V4SGVKi (the green line symbolizes the required access)

                          We configured OpenVPN so routes to 192.168.7[1-4].0/24 will be pushed to the clients. On my client machine, I can see these routes, using the tun0 interface and 192.168.220.1 as gateway for the networks 192.168.7[1-4].0/24.
                          OpenVPN itself works very well, I can reach addresses inside of 192.168.75.0/24. What doesn't work until today is reaching any address in one of the networks connected via IPsec, e.g. 192.168.72.1. Obviously, there's some issue between the OpenVPN target network 192.168.220.0/24 and the IPsec tunnels. We already configured Phase 2 of one of these IPsec tunnels, as described by @marvosa in order to route 192.168.220.0/24, without success.

                          Now, I'm wondering if there's still something we might have missed out. Any help is highly appreciated!

                          Thomas

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

                            What are the firewall rules on your OpenVPN tab Firewall > Rules, OpenVPN tab.

                            Are there IPsec P2 entries for:

                            192.168.71.0/24 to 192.168.75.0
                            192.168.72.0/24 to 192.168.75.0
                            192.168.73.0/24 to 192.168.75.0
                            192.168.74.0/24 to 192.168.75.0

                            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
                            • T
                              treuss
                              last edited by

                              Our Firewall currently allows any traffic on the OpenVPN tab. There are no limitations (except IPv4).
                              We left it this way when we ran into trouble accessing the other networks.

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

                                You still need IPsec phase 2 entries in your IPsec for the OpenVPN destinations.

                                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
                                • T
                                  treuss
                                  last edited by

                                  Problem solved. Routing works now very well. Thanks again to everyone for your help!  :)

                                  ~~Hi,

                                  sorry for the delay and thank you very much for the hint!
                                  Just some hours ago we were able to ping machines behind the IPsec tunnel via OpenVPN. We accomplished it as you suggested by adding the appropriate rule in phase 2.

                                  Now, unfortunately, we're facing a weird behaviour: As soon as there's traffic over the new (second) Phase 2 rule, the old (first) IPsec connection suddenly breaks and the target site is only reachable via OpenVPN. 
                                  Why is it that these two phase 2 rules seem to be mutually exclusive?

                                  Best regards
                                  Thomas~~

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

                                    You have IPsec and OpenVPN tunnels to the same sites?

                                    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
                                    • T
                                      treuss
                                      last edited by

                                      It was for sure not easy, but we finally got the stuff working thanks to your help.  :)

                                      1 Reply Last reply Reply Quote 0
                                      • T
                                        totalimpact
                                        last edited by

                                        Can you give any notes on this setup, did you need to create static routes on the remote ipsec routers to point to the openvpn subnet?

                                        1 Reply Last reply Reply Quote 0
                                        • M mcit referenced this topic on
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.