OpenVPN Next Hop mismatch

[weichiang]

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


[weichiang]

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'

[kejianshi]

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?

[weichiang]

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…

[kejianshi]

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

[phil.davis]

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.

[doktornotor]

@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).

[weichiang]

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.


[phil.davis]

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?

[GruensFroeschli]

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

[kejianshi]

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)

[weichiang]

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.

[phil.davis]

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.