RT-AC88U: Forwarding traffic between OpenVPN server and OpenVPN clients

[Ian Macdonald]

I have an RT-AC88U at home, running Merlin 380.68_4.

The box runs an OpenVPN server. I can remotely connect to and access my LAN, and forward traffic out to the Internet.

The box also runs several concurrent OpenVPN clients with selective routing. From my LAN, traffic is correctly routed to each of these VPNs.

All of the above operates in TUN mode and works as expected.

The only thing that doesn't work is having the server and the clients talk to each other. In other words, if I connect to the OpenVPN server from outside the home and try to access a resource that requires traffic to be routed out through one of the OpenVPN clients, the traffic gets no further than 10.8.0.1, the endpoint of the incoming tunnel.

How do I tell the box to forward traffic between the OpenVPN server and the OpenVPN clients? Clearly, the rules for forwarding traffic out through the client VPNs apply only to traffic coming from the LAN interface, not to traffic coming in through the VPN tunnel on the WAN interface.

How does one go about configuring this on this box?

 

[Xentrk]

I have an RT-AC88U at home, running Merlin 380.68_4.

The box runs an OpenVPN server. I can remotely connect to and access my LAN, and forward traffic out to the Internet.

The box also runs several concurrent OpenVPN clients with selective routing. From my LAN, traffic is correctly routed to each of these VPNs.

All of the above operates in TUN mode and works as expected.

The only thing that doesn't work is having the server and the clients talk to each other. In other words, if I connect to the OpenVPN server from outside the home and try to access a resource that requires traffic to be routed out through one of the OpenVPN clients, the traffic gets no further than 10.8.0.1, the endpoint of the incoming tunnel.

How do I tell the box to forward traffic between the OpenVPN server and the OpenVPN clients? Clearly, the rules for forwarding traffic out through the client VPNs apply only to traffic coming from the LAN interface, not to traffic coming in through the VPN tunnel on the WAN interface.

How does one go about configuring this on this box?

Try these settings for the VPN server.
Push LAN to clients Yes
Direct clients to redirect Internet traffic No
Respond to DNS Yes
Advertise DNS to clients Yes

 

[Ian Macdonald]

Try these settings for the VPN server.
Push LAN to clients Yes
Direct clients to redirect Internet traffic No
Respond to DNS Yes
Advertise DNS to clients Yes

My existing config differs only in the setting of Direct clients to redirect Internet traffic. This needs to be Yes in my case, because apart from being able to access my home LAN, I also need to be able to route all of my Internet traffic through my home router when I'm travelling.

I tried it anyway, though, and it had the expected effect of not routing my Internet-bound traffic over the tunnel. And for the same reason, it could never be a fix for the problem of needing to forward a subset of that traffic out through the OpenVPN client tunnels on the server side.

 

[Ian Macdonald]

I finally figured this out.

The problem was that traffic arriving at the OpenVPN server from 10.8/24 was being properly (selectively) forwarded to the OpenVPN clients, but the router wasn't applying NAT to it. The Create NAT on tunnel option that is auto-selected when one defines a client VPN config applies only to the LAN subnet defined in the router, not any extra subnets that the OpenVPN server defines.

So, the answer was to create a script that executes the following when the server is brought up:

iptables -t nat -I POSTROUTING -s 10.8.0.0/255.255.255.0 -o $1 -j MASQUERADE

An almost identical complementary script removes the rule again when the server is brought down.

These scripts can be called from each OpenVPN client's custom config section as follows:

up /jffs/scripts/ovpn_masq_up
down /jffs/scripts/ovpn_masq_down

The name of the TUN device is passed to the script as the first parameter, so one pair of scripts suffices for any number of clients. The script simply refers to the device internally as $1.

 

[Wingsfan87]

I finally figured this out.

The problem was that traffic arriving at the OpenVPN server from 10.8/24 was being properly (selectively) forwarded to the OpenVPN clients, but the router wasn't applying NAT to it. The Create NAT on tunnel option that is auto-selected when one defines a client VPN config applies only to the LAN subnet defined in the router, not any extra subnets that the OpenVPN server defines.

So, the answer was to create a script that executes the following when the server is brought up:

iptables -t nat -I POSTROUTING -s 10.8.0.0/255.255.255.0 -o $1 -j MASQUERADE

An almost identical complementary script removes the rule again when the server is brought down.

These scripts can be called from each OpenVPN client's custom config section as follows:

up /jffs/scripts/ovpn_masq_up
down /jffs/scripts/ovpn_masq_down

The name of the TUN device is passed to the script as the first parameter, so one pair of scripts suffices for any number of clients. The script simply refers to the device internally as $1.

Hi thanks for your post. A couple of questions as I seem to have a similar issue but not quite the same.

1. The scripts can you post both? I dont know what to put into the script to remove for the down.
2. Where do they go? Are they added to the server router and then put into the server custom config box call? or do they go into each client box?

Just a little unclear on what to do.

 

[Martineau]

Hi thanks for your post. A couple of questions as I seem to have a similar issue but not quite the same.

1. The scripts can you post both? I dont know what to put into the script to remove for the down.
2. Where do they go? Are they added to the server router and then put into the server custom config box call? or do they go into each client box?

Just a little unclear on what to do.

openvpn server and client question

 

[Alfsu]

I finally figured this out.

The problem was that traffic arriving at the OpenVPN server from 10.8/24 was being properly (selectively) forwarded to the OpenVPN clients, but the router wasn't applying NAT to it. The Create NAT on tunnel option that is auto-selected when one defines a client VPN config applies only to the LAN subnet defined in the router, not any extra subnets that the OpenVPN server defines.

So, the answer was to create a script that executes the following when the server is brought up:

iptables -t nat -I POSTROUTING -s 10.8.0.0/255.255.255.0 -o $1 -j MASQUERADE

An almost identical complementary script removes the rule again when the server is brought down.

These scripts can be called from each OpenVPN client's custom config section as follows:

up /jffs/scripts/ovpn_masq_up
down /jffs/scripts/ovpn_masq_down

The name of the TUN device is passed to the script as the first parameter, so one pair of scripts suffices for any number of clients. The script simply refers to the device internally as $1.

Alternatively, if you created individual openvpn clients files, you can also use the openvpn server iroute command.

Create a folder in /etc/openvpn in the server box named 'ccd' and create a file in /etc/openvpn/ccd with the same name of the specific openvpn client that you want to route traffic to. This file shall then contain the iroute command with the client subnet:

iroute 192.168.XXX.XXX 255.255.255.0

It automatically configure the necessary route on the openvpn server to the specific client subnet.

Sent from my ONEPLUS A3000 using Tapatalk

 

[Ian Macdonald]

Alternatively, if you created individual openvpn clients files, you can also use the openvpn server iroute command.

Create a folder in /etc/openvpn in the server box named 'ccd' and create a file in /etc/openvpn/ccd with the same name of the specific openvpn client that you want to route traffic to. This file shall then contain the iroute command with the client subnet:

iroute 192.168.XXX.XXX 255.255.255.0

It automatically configure the necessary route on the openvpn server to the specific client subnet.

Sorry. I'm only now seeing your reply here.

The solution you describe will, I believe, allow the subnets of multiple users connecting to the OpenVPN server to communicate with each other.

In my case, I needed to allow the OpenVPN server to forward incoming traffic from a single user through to client VPN tunnels (1-5) defined on the same box. These OpenVPN client configs are to commercial VPN providers, and require masquerading to make everything work.

Will your solution work in this latter case, too?

 

[Alfsu]

Sorry. I'm only now seeing your reply here.

The solution you describe will, I believe, allow the subnets of multiple users connecting to the OpenVPN server to communicate with each other.

In my case, I needed to allow the OpenVPN server to forward incoming traffic from a single user through to client VPN tunnels (1-5) defined on the same box. These OpenVPN client configs are to commercial VPN providers, and require masquerading to make everything work.

Will your solution work in this latter case, too?

I don't think your goal can be accomplished by way of the GUI. It may be possible using some clever iptables rules but that won't be an easy thing to do.

Sent from my ONEPLUS A3000 using Tapatalk

 

[Ian Macdonald]

I don't think your goal can be accomplished by way of the GUI. It may be possible using some clever iptables rules but that won't be an easy thing to do.

See post #4 in this thread for the solution that I came up with. Your posting was in response to that, which have the impression of offering an alternative solution to the same problem; but I then questioned whether this was really the case, because it appeared to be a solution to a different problem.