unable to reach specific LAN device when connected to OpenVPN Server

[#TY]

Time to see what's actually happening there by dumping the relevant data structures.

On the OpenVPN *server*, post the output from the following commands.

ip route
iptables -vnL INPUT
iptables -vnL FORWARD
iptables -t nat -vnL POSTROUTING
cat /tmp/etc/openvpn/server1/config.ovpn

On the OpenVPN *client*, post the output from the following commands.

ip route
iptables -vnL FORWARD
iptables -t nat -vnL POSTROUTING
cat /tmp/etc/openvpn/client1/config.ovpn

From the server (white Terminal):

From the client (Black Terminal)

 

[eibgrad]

Why does the client side have *both* an OpenVPN client and *server*?! I see tun12 and tun21 on that side, both using 10.8.0.x!

 

[eibgrad]

That's the tricky part about VPNs. You need to be extremely careful that you don't create routing conflicts. Every network, be it the client, server, or tunnel, must be unique and non-overlapping. And as you create more and more complex configurations (in this case, the client itself having its own OpenVPN server), the risk of creating such conflicts grows. Again, this is why 192.168.1.1 for the remote network is likely to cause its own problems, if not now, in the near future.

 

[#TY]

Why does the client side have *both* an OpenVPN client and *server*?! I see tun12 and tun21 on that side, both using 10.8.0.x!

That's because Im a dummy that completely forgot about that

I changed my home OpenVPN to 10.9.0.0, then shut down and restarted the OpenVPN client and now everything works

 

[#TY]

@eibgrad Thank you so much man for all your help. I will definitely document and save your script for future reference.

Why isn't this included in the default VPN section of the router? Im sure I can't be the only one with a need like this.

 

[eibgrad]

That's because Im a dummy that completely forgot about that

I changed my home OpenVPN to 10.9.0.0, then shut down and restarted the OpenVPN client and now everything works

Consider it a blessing in disguise. Because now you have a good example of how doing everything seemingly correct can still lead to issues. OpenVPN server typically use 10.8.0.x by default, but it's only a convention, mostly because that's what the OpenVPN documentation uses. To avoid this happening to your other clients, perhaps consider making the office use 10.88.0.x. IOW, if someone else also has an OpenVPN server running concurrently w/ their OpenVPN client, there's just that much less chance of a conflict. Think/plan ahead!

 

[eibgrad]

Why isn't this included in the default VPN section of the router? Im sure I can't be the only one with a need like this.

I was actually thinking about making the suggestion to @RMerlin.

 

[#TY]

I was actually thinking about making the suggestion to @RMerlin.

I second that idea. Its absolutely brilliant and Im sure tons would appreciate it. Thank you once again for your help and more importantly, your patience

 

[#TY]

Im sorry to bother you again with this @eibgrad but I just applied your script to my home router as I also have OpenVPN Server running on it so that I may access it when Im away. Everything "seemed" to have gone right when I copy/pasted the script but after restarting the router, I don't see the NAT line in the iptables -t nat -vnL POSTROUTING output. Instead, this is what I get:

master@RT-AC5300-0780:/tmp/home/root# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 307 packets, 22077 bytes)
pkts bytes target prot opt in out source destination
499 45078 PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0
466 42758 MASQUERADE all -- * eth0 !193.161.25.178 0.0.0.0/0
14 3233 MASQUERADE all -- * br0 10.0.10.0/24 10.0.10.0/24

Any idea?

 

[eibgrad]

Im sorry to bother you again with this @eibgrad but I just applied your script to my home router as I also have OpenVPN Server running on it so that I may access it when Im away. Everything "seemed" to have gone right when I copy/pasted the script but after restarting the router, I don't see the NAT line in the iptables -t nat -vnL POSTROUTING output. Instead, this is what I get:

master@RT-AC5300-0780:/tmp/home/root# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 307 packets, 22077 bytes)
pkts bytes target prot opt in out source destination
499 45078 PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0
466 42758 MASQUERADE all -- * eth0 !193.161.25.178 0.0.0.0/0
14 3233 MASQUERADE all -- * br0 10.0.10.0/24 10.0.10.0/24

Any idea?

I assume it's also running Merlin. Did you enable JFFS and JFFS scripts in Administration->System?

 

[#TY]

I assume it's also running Merlin. Did you enable JFFS and JFFS scripts in Administration->System?

Yes to both

 

[eibgrad]

Remember, the script assumes server #1. If you're using some other instances, adjust accordingly. Wouldn't hurt to initially apply the rule directly from an ssh session, in case it's returning an error, something you wouldn't notice from the nat-start script when executed. Check it got applied w/ the "iptables -t nat -vnL POSTROUTING" command.

 

[#TY]

Remember, the script assumes server #1. If you're using some other instances, adjust accordingly. Wouldn't hurt to initially apply the rule directly from an ssh session, in case it's returning an error, something you wouldn't notice from the nat-start script when executed. Check it got applied w/ the "iptables -t nat -vnL POSTROUTING" command.

Is there a special way to copy/paste your script? I am simply SSH into the router, then from the command line, pasting the script as is. Im not sure if this is the correct way though. Thats what I did on the office router and it seemed to work but for some reason on my home router, it isnt.