Routing openVPN traffic through specific ipsec tunnels



  • 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


  • Netgate

    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



  • 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?


  • Netgate

    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.



  • 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.


  • Netgate

    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.



  • 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


  • Netgate

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



  • 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.



  • 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 :(



  • 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


  • Netgate

    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



  • 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.


  • Netgate

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



  • 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~~


  • Netgate

    You have IPsec and OpenVPN tunnels to the same sites?



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



  • 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?