OpenVPN Next Hop mismatch



  • Hi All

    I've got OpenVPN set up for site to site connectivity. It's set up thus:

    SITE-A 10.1.0.0/16  <–pfSense-A-Server--> Tunnel Network 10.0.2.0/24 <--pfSense-B-Client--> Site-B 10.2.0.0/16

    pfSense-A-Server always takes up 10.0.2.1 and expects pfSense-B-Client to be 10.0.2.2
    Routing table at pfSense-A-Server shows 10.2.0.0/16 >> 10.0.2.2

    All correct so far, I think.

    What's strange is that pfSense-B-Client for some reason always takes up 10.0.2.6 instead, and expects pfSense-A-Server to be 10.0.2.5 (should be 10.0.2.1)
    Routing table at pfSense-B-Client shows 10.1.0.0/16 >> 10.0.2.5 (should be 10.0.2.1)

    Needless to say that with the mismatch, routing across sites doesn't work.

    The Tunnel Network link actually comes up correctly, since from pfSense-A-Server I can ping 10.0.2.6, and from pfSense-B-Client I can ping 10.0.2.1.

    I've tried the following without success:

    • defining the Tunnel Network only on the server side

    • defining the Tunnel Network on both the server and client

    • Using Release 2.0.3 on both sides

    • Using Release 2.0.3 on server side, and 2.1RC2 on client side

    Can anyone shed any light on this behavior, and how to fix it?


  • Banned

    Uhm… You OpenVPN network overlaps with the site-B LAN => broken.



  • I love this thanks button - So much faster than typing…



  • It doesn't… 10.0.2.0/24 rolls up to 10.0.0.0/16, not 10.2.0.0/16



  • Hmmmmm - There is no retract thanks button…



  • I think you might need to post your configuration for both sites.



  • Here are screenshots of the configuration

    ![pfsense client.png](/public/imported_attachments/1/pfsense client.png)
    ![pfsense client.png_thumb](/public/imported_attachments/1/pfsense client.png_thumb)
    ![pfsense server.png](/public/imported_attachments/1/pfsense server.png)
    ![pfsense server.png_thumb](/public/imported_attachments/1/pfsense server.png_thumb)



  • Adding on the status and routes screenshots, in case that helps any.

    ![pfsense client status.png](/public/imported_attachments/1/pfsense client status.png)
    ![pfsense client status.png_thumb](/public/imported_attachments/1/pfsense client status.png_thumb)
    ![pfsense client routes.png](/public/imported_attachments/1/pfsense client routes.png)
    ![pfsense client routes.png_thumb](/public/imported_attachments/1/pfsense client routes.png_thumb)
    ![pfsense server status.png](/public/imported_attachments/1/pfsense server status.png)
    ![pfsense server status.png_thumb](/public/imported_attachments/1/pfsense server status.png_thumb)
    ![pfsense server routes.png](/public/imported_attachments/1/pfsense server routes.png)
    ![pfsense server routes.png_thumb](/public/imported_attachments/1/pfsense server routes.png_thumb)



  • Tried running OpenVPN client manually from the CLI with verbosity set to level 3. Looks like the server is pushing out the mismatched parameters

    Sep 14 12:40:38 pfsense openvpn[14412]: SENT CONTROL [vpn-server]: 'PUSH_REQUEST' (status=1)
    Sep 14 12:40:38 pfsense openvpn[14412]: PUSH: Received control message: 'PUSH_REPLY,route 10.1.0.0 255.255.0.0,route 10.0.2.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.2.6 10.0.2.5'



  • I do not run a site to site config.  I run road warrior configs and suspect I always will.  But, I noticed your client config has no routes configured to be pushed.  Is that the correct way to do it?



  • The correct routes to SITE-B show up on the server routing table, so there doesn't seem to be a need to do that.

    If you see my last message, it looks more like the server is pushing out the wrong ifconfig parameters to the client.

    I'm starting to think that this might be a bug…



  • It works for too many people to be a bug.  Try pushing routes in client also.  What can it hurt?



  • You should not need to push any routes. I have a site-to-site server that receives connections from multiple remote office clients. I use client-specific overrides to tell it which client has which office subnet on the other end. Maybe this is not necessary if there is only 1 client connecting, but I am not sure. Example attached.
    The .1-.2 .5-.6 .9-.10 thing breaking the tunnel subnet into /30 pieces is what OpenVPN does internally. It works, it just does not show to the outside world that the server is being .1 .5 .9 … all at once.
    Maybe you just need firewall rules at each end on the OpenVPN tab to pass the traffic coming in from the LAN subnet at the other end? Post your OpenVPN firewall rules if you are unsure.



  • Banned

    @phil.davis:

    The .1-.2 .5-.6 .9-.10 thing breaking the tunnel subnet into /30 pieces is what OpenVPN does internally. It works, it just does not show to the outside world that the server is being .1 .5 .9 … all at once.

    Yeah, this can be disabled in 2.1 (the Topology checkbox).



  • phil.davis, I've tested and looks like you're right about the way OpenVPN handles routes. Apparently it just works

    From SITE-B using the OpenVPN SSL interface, I'm able to successfully ping the networks behind the SITE-A pfSense router. It looks like at least the SITE-A pfense is routing correctly.

    It's only when I'm trying to ping hosts in the SITE-A LAN from my laptop within the SITE-B LAN that things stop working.

    I've got an allow-all rule on both routers for all IPs within my network.

    ![OpenVPN Rules.png](/public/imported_attachments/1/OpenVPN Rules.png)
    ![OpenVPN Rules.png_thumb](/public/imported_attachments/1/OpenVPN Rules.png_thumb)



  • At the client end, you don't have anything in "Remote Network". In my links I always specify that, the same as what is in "Local Network" on the server end. In theory that should be unnecessary, the server should be able to push its local network information to the client, for the client to use as remote routes. But I don't think that actually happens?



    • In a shared key setup you always need to specify on each side the routes which are added, even on the client side.
    • In a PKI the routes which are added on the client side can be configured on the server and are then pushed to the client.

    If you have a simple site-to-site connection then one usually uses a shared key setup. Just make sure that, as phil.davis wrote, you have the "Local Network" and "Remote Network" filled in with the correct information on both sides.



  • That sounds reasonable…  So I guess maybe try adding routes on the clients side also?  8)

    (Maybe I said it wrong the first couple times)



  • phil.davis and GruensFroeshli,

    Thanks for the feedback, sorry that I did not reply earlier as I could only come back and work on this during the weekend.

    I've finally got it to work after playing around with the settings based on what you mentioned, and a wiki page at http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing. Here are the changes I made:

    (1) At the server side, inserted the following into the advanced configuration
    route 10.2.0.0 255.255.0.0
    push "route 10.2.0.0 255.255.0.0"

    (2) Again at the server side, created a client specific override for the Site-B router:
    iroute 10.2.0.0 255.255.0.0

    Seems to make things work correctly after that. I'm using PKI, and tried both configuring and NOT configuring routes at the client. As Phil correctly predicted, it didn't make much of a difference.

    Thanks to everyone for helping out, this issue is solved.



  • For other readers:

    push "route 10.2.0.0 255.255.0.0"
    

    That is actually trying to tell siteB that the OpenVPN link is a route to 10.2.0.0/16 - but siteB actually has the local LAN 10.2.0.0/16. SiteB will be smart enough to effective ignore that, and talk directly to its local LAN. The  line should be able to be deleted.

    route 10.2.0.0 255.255.0.0
    

    This route put in the advanced box on the server side is OK. But it should already work like this by putting 10.2.0.0/16 inn the "Remote Networks: box. I can't say why the advanced box entry was really needed.

    iroute 10.2.0.0 255.255.0.0
    

    Client-specific overrides: This is a good thing, and specifically tells the server which connecting client has the 10.2.0.0/16 network at the client end. IMHO this is the thing that really makes it work.


Log in to reply