OpenVPN peer to peer routing



  • Hi all,

    I'm trying to use an OpenVPN peer to peer tunnel to connect my university and home networks. The tunnel establishes fine, and the peers on which the tunnel is established can talk to each other, but how do I route the local networks to talk to each other through these peer to peer connections?

    For example, my university is on a.b.0.0/16, and my home net is on c.d.0.0/16 and I wish to be able to access addresses in the c.d.0.0/16 range from a.b.0.0/16 range and vice versa. I've set these in the "remote network" and "local network" properties on the openVPN page but nothing. I also tried 'push "route c.d.0.0 255.255.0.0"' in the options but nothing happened there either.

    Now, I'm not really sure what to do. Any help appreciated.

    Cheers,

    Yax



  • I assume that
    a) the university is not just 1 big /16 subnet.
    b) you have a pfSense router at both ends (Uni and home) of the OpenVPN link.

    You probably have a VPN link to a Uni router that is on a Uni subnet - say a.b.x.0/24 or whatever.
    If you have filled in all the Local Network and Remote Network fields on each end of the peer to peer tunnel settings, then there should already be a route from a.b.x.0/24 to c.d.0.0/16 and vice-versa. But you will need to tell your home end that the whole of a.b.0.0/16 lives at the other end of the OpenVPN link - not just a.b.x.0/24. In the home end OpenVPN Advanced box just put:

    route a.b.0.0 255.255.0.0
    

    No need to "push" anything, this is a route that will get added locally at home to point to Uni.
    The problem you will have is that other subnetted parts of the Uni network (a.b.y.0/24 a.b.z.0/24 etc, however they broke it up) will have routers between them with routing tables. Those routers will need to know that they can get packets to your home c.d.0.0/16 via your Uni-end pfSense router (a.b.x.n/24) - a.b.x.n router will need to participate in the Uni routing protocol so other Uni routers can learn about it, or there will need to be static routes in every router that needs to pass your traffic.

    Even if the Uni is 1 big a.b.0.0/16 subnet, the client systems at the Uni will have some default gateway. If that default gateway is not your Uni-end pfSense box then it needs to know that it can redirect packets for c.d.0.0/16 to your Uni-end pfSense router at a.b.x.n, which will send them home to you.

    If my guesses about your Uni network environment are wrong, then give some more information…



  • Hi,

    Cheers for your response.

    a) I've no real knowledge of the uni subnetting, I'm just establishing a connection from a workstation.
    b) I don't have a pfSense router at the Uni side. I'm running an OpenVPN client from a Linux workstation.

    In all honesty, I'm not too bothered about having access to the rest of the Uni, just my workstation (I can hop around everywhere else using SSH), but I want access to my home subnet from Uni, and access to the workstation from any device within my home subnet. My of my machines are running Linux.

    Here is my pfSense routing table currently:

    /root(1): netstat -nr
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            46.65.13.1         UGS         0   109272    em0
    8.8.8.8            46.65.13.1         UGHS        0      424    em0
    46.65.13.0/24      link#1             U           0    50419    em0
    46.65.13.55        link#1             UHS         0        0    lo0
    87.194.255.154     00:25:90:54:5d:b0  UHS         0       16    em0
    87.194.255.155     00:25:90:54:5d:b0  UHS         0       16    em0
    127.0.0.1          link#7             UH          0      425    lo0
    137.73.0.0/23      192.168.2.2        UGS         0        0 ovpns1
    192.168.0.0/16     link#2             U           0   538280    em1
    192.168.1.1        link#2             UHS         0   299930    lo0
    192.168.2.1        link#8             UHS         0        0    lo0
    192.168.2.2        link#8             UH          0        0 ovpns1
    
    

    But if I ping 192.168.2.2 or 192.168.2.1 (OpenVPN peer addresses) from an address within my lan subnet, it gives me destination host unreachable. Here is an example routing table from a client in the subnet:

    [root@host ~]# route
    Kernel IP routing table
    Destination     Gateway           Genmask         Flags Metric Ref    Use Iface
    default         pfsense.localnet  0.0.0.0         UG    0      0        0 lan-br
    link-local      *                 255.255.0.0     U     1003   0        0 lan-br
    192.168.0.0     *                 255.255.0.0     U     0      0        0 lan-br
    192.168.2.0     pfsense.localnet  255.255.255.255 UGH   0      0        0 lan-br
    192.168.122.0   *                 255.255.255.0   U     0      0        0 virbr0
    [root@host ~]#
    
    

    Currently, I can't even get to the local peer address. Similarly, from my university machine, I can't reach any of the addresses in my LAN subnet.

    Routing table at my university workstation:

    [yaxattax@fedora16-yax:~]$ route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         137.73.20.30    0.0.0.0         UG    0      0        0 em1
    137.73.20.0     *               255.255.254.0   U     1      0        0 em1
    192.168.2.1     *               255.255.255.255 UH    0      0        0 tun0
    [yaxattax@fedora16-yax:~]$ 
    
    

    Please let me know what information you would like, if the provided information is not sufficient. I apologise if I appear to be dense; I don't have much experience setting up routers.

    Thanks for your response so far.

    Yax



  • I got distracted by family matters and the Olympics!
    This looks wrong:

    192.168.0.0/16     link#2             U           0   538280    em1
    192.168.1.1        link#2             UHS         0   299930    lo0
    192.168.2.1        link#8             UHS         0        0    lo0
    192.168.2.2        link#8             UH          0        0 ovpns1
    

    "/16" means that it thinks the whole of 192.168.n.n is on your LAN (known as link#2 here).
    It looks like you are using 192.168.2.1 and 192.168.2.2 for the ends of your OpenVPN tunnel. But they are addresses in your local LAN, the routing won't go too far.
    Assuming you don't actually need a "/16" subnet at home, make your home LAN subnet 192.168.1.0/24 (pfSense will be 192.168.1.1/24).
    Then make the OpenVPN tunnel 192.168.2.n/24 (or you can use anything from /24 to /30 if you understand subnet masks - you only need 4 addresses in the tunnel subnet - the bottom "0" address, 2 tunnel endpoints and the top subnet broadcast address)
    If you want to initiate stuff from the Uni end then you will need a firewall rule on OpenVPN to allow incoming from your Uni address or subnet. Similarly any firewalling stuff on the Uni end will need to allow access from home addresses.



  • Hi,

    Cheers for the response. I've done as you suggested and made the LAN a /24 subnet. It seems to improve the situation, i.e I can now ping 192.168.2.1, and 192.168.2.2 does not any longer give "destination unreachable" but instead attempts to connect time out. I've got a pass-all rule on the OpenVPN interface, so I'm not sure what next.

     netstat -nr
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            46.65.13.1         UGS         0    28671    em0
    8.8.8.8            46.65.13.1         UGHS        0      387    em0
    46.65.13.0/24      link#1             U           0    36778    em0
    46.65.13.55        link#1             UHS         0        0    lo0
    87.194.255.154     00:25:90:54:5d:b0  UHS         0       10    em0
    87.194.255.155     00:25:90:54:5d:b0  UHS         0       10    em0
    127.0.0.1          link#7             UH          0      239    lo0
    192.168.1.0/24     link#2             U           0    77490    em1
    192.168.1.1        link#2             UHS         0    76540    lo0
    192.168.2.1        link#8             UHS         0        2    lo0
    192.168.2.2        link#8             UH          0      109 ovpns1
    
    

    Cheers for all the help so far. Just out of interest, would it have been easier to set the VPN up as a bridge, rather than routed?

    Yax



  • If you do a bridge, then you'll probably get a heap of broadcast traffic from your Uni subnet (assuming your workstation picks it up).
    a) That would suck up bandwidth
    b) I doubt that the Uni would appreciate their internal broadcast traffic being relayed to your home
    c) Your home end would end up in the same subnet as Uni and you might allocate IP addresses and make address conflicts.

    Your Uni end workstation is going to need to allow incoming packets on the VPN link from home. I guess whatever software you are using on that end will also have a firewall/packet filtering function as well, which needs to be configured. It's nice and easy if pfSense is on both ends - you don't have to learn how to configure a 2nd set  of software.

    I hadn't really thought about the security implications of this sort of thing much before - what happens at my work sites with savvy users who are initiating outward VPN links from their laptops to their homes (which have VPN servers listening on IP addresses that can be found with DynDNS). They can happily route all sorts of data off the work network to their homes.



  • Well my Uni workstation is a linux box. I've turned IPtables off, so it should just allow everything.

    If I add the following route:

    route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1

    I can access everything on my LAN subnet, my LAN subnet can now also access my uni workstation.. so I think this is solved. I'd like to be able to do this without having to add the route manually, perhaps you can advise with that? Will a push option in the pfSense config work?

    Cheers,

    Yax



  • From the home end, in the Advanced box:

    push "route 192.168.1.0 255.255.255.0"
    

    This should tell the Uni end that 192.168.1.0/24 is at the home end.



  • Cheers for all your help so far - unfortunately this didn't work. I'll keep fiddling and will update if I find something that works.



  • Just to update. This does work, but there was a client configuration issue - I had –tls-client but this doesn't imply or --pull (--client does), which is required in order to pull routing information from the server. Adding --pull to the client connection command solved the problem.


Locked