Need Help with VPN Director

[Mike S]

I have two office locations with Asus-Merlin routers at each site. My remote site has a VPN Server configured. My main site (running 384.18) has a VPN Client configured to connect to the remote site. I have NAT over the tunnel turned off and have configured routes using Policy Rules (Strict). See the attached screen shot for the main site configuration.

Everything was working fine. With the VPN tunnel connected, I could ping between the LANs at both sites, in both directions.

This evening, I upgraded my main site to 386.7. Now I have to deal with the new VPN Director. I have attached a screen shot of my VPN Director. The tunnel connects fine, but I can't ping from the main site LAN (192.168.133.xx) to the remote site lan (192.168.135.xx) any more.

HELP!!! I can't find any documentation on how this is suppose to work.

 

[RMerlin]

Make sure you set the client firewall to Allow - it defaults to Block.

 

[Mike S]

The Client Firewall is set to allow (see attached screen shot).

One thing that is very strange is that while I can't ping from the main router to the remote network, I can ping from the remote router (using network tools) to the computers connected to the main office LAN.

I'm completely baffled???

 

[eibgrad]

In a site-to-site configuration, you do want Inbound Firewall set to Allow. But that's only to allow clients on the OpenVPN server side of the tunnel to initiate connections to devices on the OpenVPN client side of the tunnel. It has no bearing on connections initiated on the OpenVPN client side.

BTW, you don't need to use the VPN Director for site-to-site. In fact, you should set "Redirect Internet traffic through tunnel" to No. The server should normally "push" its own IP network(s) to the OpenVPN client when the connection is made, thus making those routes known to the OpenVPN client. You shouldn't have to use the VPN Director to make that happen.

The OpenVPN server should have Manage Client-Specific Options enabled and have any routes available on the OpenVPN client defined within that section, based on the CN (Common Name) of the client cert. That's how the server manages its static routing to the client.

 

[Ranger802004]

The Client Firewall is set to allow (see attached screen shot).

One thing that is very strange is that while I can't ping from the main router to the remote network, I can ping from the remote router (using network tools) to the computers connected to the main office LAN.

I'm completely baffled???

Same as @eibgrad , don't use VPN Director for your Site to Site. Create the routes in the custom configuration for OpenVPN on each side of the tunnel.

 

[Mike S]

Same as @eibgrad , don't use VPN Director for your Site to Site. Create the routes in the custom configuration for OpenVPN on each side of the tunnel.

How do you create route in the custom configuration for OpenVPN? I thought the VPN Director was suppose to handle this? Before the VPN Director existed, I could define the policy routes for each OpenVPN Client and this worked just fine. Now, the routes look like they have been defined by the VPN Director when you look at the GUI page for the OpenVPN client, but the routes don't work. This sounds like a bug to me.

 

[eibgrad]

As I said before, there's NO need to use the VPN Director for site-to-site. You configure the OpenVPN server to push the server's IP network to the OpenVPN client, which will be done automatically if you set the "Client will use VPN to access" option to "LAN only" on the OpenVPN server.

That doesn't mean you couldn't configure the server's IP network on the client using the custom config field, but the generally "preferred" semantics is to have the server push it to the client, in case it ever changes. But more importantly, how you configure "Client will use VPN to access" will also configure the firewall on the server side to allow the desired access (LAN only, Internet only, or Both)!

When it comes to the server knowing about the IP network of the OpenVPN client, that's where the MCSO (Manage Client-Specific Options) section comes into play. That's how the server knows what to route to which OpenVPN client based on the client's cert (specifically, it's Common Name). It also configures the necessary CCD directory and configuration file in that CCD directory for that client, which must contains an appropriate iroute directive for the client's IP network.

Notice NONE of this requires messing w/ the custom configuration field on either the OpenVPN client or server. Instead, it requires properly using the GUI options as intended.

IOW, there's a specific protocol here for how you establish the static routing on each side of the tunnel. If you step outside that protocol, then you create potential problems. It doesn't mean users sometimes won't go their own way and achieve the same results, but that assumes you know exactly all the i's to be dotted and t's to be crossed. Using the GUI as prescribed above avoids making mistakes.

 

[Ranger802004]

As I said before, there's NO need to use the VPN Director for site-to-site. You configure the OpenVPN server to push the server's IP network to the OpenVPN client, which will be done automatically if you set the "Client will use VPN to access" option to "LAN only" on the OpenVPN server.

That doesn't mean you couldn't configure the server's IP network on the client using the custom config field, but the generally "preferred" semantics is to have the server push it to the client, in case it ever changes. But more importantly, how you configure "Client will use VPN to access" will also configure the firewall on the server side to allow the desired access (LAN only, Internet only, or Both)!

When it comes to the server knowing about the IP network of the OpenVPN client, that's where the MCSO (Manage Client-Specific Options) section comes into play. That's how the server knows what to route to which OpenVPN client based on the client's cert (specifically, it's Common Name). It also configures the necessary CCD directory and configuration file in that CCD directory for that client, which must contains an appropriate iroute directive for the client's IP network.

Notice NONE of this requires messing w/ the custom configuration field on either the OpenVPN client or server. Instead, it requires properly using the GUI options as intended.

IOW, there's a specific protocol here for how you establish the static routing on each side of the tunnel. If you step outside that protocol, then you create potential problems. It doesn't mean users sometimes won't go their own way and achieve the same results, but that assumes you know exactly all the i's to be dotted and t's to be crossed. Using the GUI as prescribed above avoids making mistakes.

For my site to site I have a few subnets routed so I just use the custom configuration.

 

[eibgrad]

For my site to site I have a few subnets routed so I just use the custom configuration.

I understand. I'm talking about the simplest, most common situation, w/ a single subnet on each side of the tunnel. But yes, additional subnets (client or server side) may require explicit directives in the custom config field. There are often other things you need to consider as well.

For example, if you have multiple subnets on the server side you wish to make available to the OpenVPN client (whether push'd by the server, or defined on the client using the custom config field), you will need additional firewall rules on the server to allow access to those subnets. Or else you'll have to change "Client will use VPN to access" to Both. But if the intent is to NOT allow internet access through the server, then the client will need to block the redirect-gateway def1 directive pushed by the server in the client's custom config field.

pull-filter ignore "redirect-gateway"

For the clients w/ multiple subnets, you simply add those to MCSO on the server side.

So yes, once you move beyond a single subnet, things do get more complicated, and other changes are typically required. But it's still important to understand the proper configuration for the most common configuration since it forms the basis for any additional modifications.

 

[Ranger802004]

I understand. I'm talking about the simplest, most common situation, w/ a single subnet on each side of the tunnel. But yes, additional subnets (client or server side) may require explicit directives in the custom config field. There are often other things you need to consider as well.

For example, if you have multiple subnets on the server side you wish to make available to the OpenVPN client (whether push'd by the server, or defined on the client using the custom config field), you will need additional firewall rules on the server to allow access to those subnets. Or else you'll have to change "Client will use VPN to access" to Both. But if the intent is to NOT allow internet access through the server, then the client will need to block the redirect-gateway def1 directive pushed by the server in the client's custom config field.

pull-filter ignore "redirect-gateway"

For the clients w/ multiple subnets, you simply add those to MCSO on the server side.

So yes, once you move beyond a single subnet, things do get more complicated, and other changes are typically required. But it's still important to understand the proper configuration for the most common configuration since it forms the basis for any additional modifications.

Correct, my custom firewall and NAT scripts are pretty long with if statements on making the rules lol

 

[Mike S]

I understand. I'm talking about the simplest, most common situation, w/ a single subnet on each side of the tunnel. But yes, additional subnets (client or server side) may require explicit directives in the custom config field. There are often other things you need to consider as well.

For example, if you have multiple subnets on the server side you wish to make available to the OpenVPN client (whether push'd by the server, or defined on the client using the custom config field), you will need additional firewall rules on the server to allow access to those subnets. Or else you'll have to change "Client will use VPN to access" to Both. But if the intent is to NOT allow internet access through the server, then the client will need to block the redirect-gateway def1 directive pushed by the server in the client's custom config field.

pull-filter ignore "redirect-gateway"

For the clients w/ multiple subnets, you simply add those to MCSO on the server side.

So yes, once you move beyond a single subnet, things do get more complicated, and other changes are typically required. But it's still important to understand the proper configuration for the most common configuration since it forms the basis for any additional modifications.

In my situation, I do have two subnets at each location that I am trying to route over the VPN Connection. Before the VPN Director existed, I had no problem programing these routes in the VPN Client GUI using the Policy Rules (strict). With the VPN Director, it shows the same policy rules applying to the VPN Client, but only one of the two routes is being forwarded over the tunnel. I changed the order of the routes in the VPN Director, but that did not change the subnet that was being routed vs the one that wasn't.

There is definitely something not working properly compared to the pre VPN Director firmware.

 

[eibgrad]

In my situation, I do have two subnets at each location that I am trying to route over the VPN Connection. Before the VPN Director existed, I had no problem programing these routes in the VPN Client GUI using the Policy Rules (strict). With the VPN Director, it shows the same policy rules applying to the VPN Client, but only one of the two routes is being forwarded over the tunnel. I changed the order of the routes in the VPN Director, but that did not change the subnet that was being routed vs the one that wasn't.

There is definitely something not working properly compared to the pre VPN Director firmware.

I just don't think it makes sense to continue w/ what I consider an improperly configured OpenVPN site-to-site configuration. Even if the prior worked. For all I know, the fact a change occurred in how routing policy was implemented lead to the current situation. And had you NOT depended on it, the upgrade would most likely have been uneventful.

 

[Mike S]

I guess I don't understand how my previous configurations was improper. When you define a VPN Client, you can specify the subnets that the VPN Client should route over that tunnel. You can specify multiple subnets. This has worked for a number of years and firmware upgrade cycles. With the VPN Director GUI, all of a sudden this no longer works. This sounds like a bug to me.

 

[eibgrad]

I guess I don't understand how my previous configurations was improper. When you define a VPN Client, you can specify the subnets that the VPN Client should route over that tunnel. You can specify multiple subnets. This has worked for a number of years and firmware upgrade cycles. With the VPN Director GUI, all of a sudden this no longer works. This sounds like a bug to me.

As I said previously, it *is* possible to configure site-to-site in a more *manual* way, such as configuring the static routing on each side. But there's a good reason you should NOT do it this way. You should let the GUI manage this process for you (e.g., let the OpenVPN server push its IP network to the client), and only then make adjustments for situations like multiple subnets. I explained that in detail above.

Otherwise, we now need to debug your specific approach, whatever that is. I agree, clearly something isn't right. But it *may* be due to your chosen implementation having some fundamental error that only NOW has been exposed w/ a change in the firmware. But until I know more about exactly what you did, that's all speculation.

If you insist on using the VPN Director, then the only way we're going to debug it is if you provide FULL details of your OpenVPN client and server, soup to nuts, including any firewall changes you may have made to support those additional subnets, scripting for managing the CCD files, etc. Perhaps even dumps of the various data structures on both sides. I was just trying to avoid all that by having you follow a *normal* site-to-site configuration.

ifconfig
ip route
ip route show table ovpnc1
ip rule
iptables -vnL
iptables -t nat -vnL

At the very least, let's see how you configured the OpenVPN server, something you've never shared.

 

[eibgrad]

BTW, if you insist on configuring the server's IP networks on the client (rather than having the server push them), it would actually make more sense to add static routes to the OpenVPN client configuration rather than mess w/ the VPN Director.

route 192.168.134.0 255.255.255.0
route 192.168.135.0 255.255.255.0

(the above goes into the custom config field)

Here's an example of the output showing how all traffic is routed through the ovpnc1 table, and the static routes in-place to force those networks over the VPN. The same thing would happen if the server was pushing those routes instead.

admin@lab-merlin1:/tmp/home/root# ip rule
0:    from all lookup local
10001:    from all lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
1.0.0.1 via 192.168.63.1 dev eth0  metric 1
1.1.1.1 via 192.168.63.1 dev eth0  metric 1
192.168.63.1 dev eth0  proto kernel  scope link
192.168.135.0/24 via 10.16.0.1 dev tun11
192.168.134.0/24 via 10.16.0.1 dev tun11
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.63.0/24 dev eth0  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev eth0  metric 1
10.16.0.0/16 dev tun11  proto kernel  scope link  src 10.16.0.27
127.0.0.0/8 dev lo  scope link

NOTE: Because the "Redirect Internet traffic through tunnel" option is set to NO, there is no default gateway in ovpnc1, so anything requiring internet access falls through to the main routing table, which routes over the WAN.

That's why I say, routing policy has nothing to do w/ this. It's about properly configuring static routes on both sides of the tunnel.