Hi there
I have a GL-MT300N-V2 set up as a OpenVPN client. On the WAN site it has a VPN IP address (10.1.1.5). The LAN side has a 192.168.4.1 IP address and is connected to a PLC with a static address (192.168.4.2).
The GL-MT300N-V2 has a firewall port forwarding to any incoming traffic towards 192.168.4.2.
When I connect to the GL-MT300N-V2 by WIFI with an IP in the 192.168.4.X range I have no problem getting access to the PLC (same subnet).
When I connect from the VPN side (my IP is 10.1.1.7) I cannot access the PLC on the LAN side.
It seems that the port forwarding is not working on the VPN. I have also tried DMZ and doesnt work either.
Any help would be much appreciated…//Regards
I am having the exact same issue. I have a GL-X750 on the (wireguard client), and a GL-AR750S (wireguard server) on the server side. they are connected and I can ping both vpn client and vpn server from either location.
I can “ping” all the devices on the Server side from the client location. When I am at the server location I am not able to “ping” or access anything on the Client network.
Did you get this working. I noticed PLC in your post. I too am using this to access our PLC’s.
I believe this client to server works great because the client is forced to route all traffic to the server.
but when at the vpn server location, it is not forced to use the vpn connection for everything so when looking for my 10.1.10.12 device at the client location, it does not go looking on the vpn tunnel it goes on the internet. Which it does not find there.
I just dont know how to fix it…
@craignog
It is unfortunate to highjack this thread, as it is about an openVPN issue and not wireguard.
I have my wireguard server on a raspberry pi. The routing of the server is done with the option
net.ipv4.ip_forward=1
Additionally these rules are executed, when link is established (where %i stands for client IP as far as I know)
iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
To my understanding, the same have to be set on the client. BUT… as the client usually routes all the traffic through the tunnel (to the server) this would create a loop. So the local network has to be excluded on client side.
Additional problem: I don*t know, how to tell the server, that he has to route the traffic to the subnet of the client through the tunnel, while the rest goes to the WAN of the server.
I hope you understand what I mean, and maybe you can make something out of it.
Nevertheless, maybe you should open a new thread for your issue.
Hi Craig, ThH
my configuration is quite similar to yours with a Raspberry Pi as a OpenVpn server and the GL-MT300N-V2 as clients.
One thing that I noticed and you guys will probably suffer too was that the default config client (clientX.ovpn generated when adding a new openVPN client with the Raspberry) didn’t work well on the GL-MT300N-V2. Basically the connection was dropping every hour or so and the client did not reconnect. Going through the OpenVPN logs made me think that the clients were having DNS issues .It drove me crazy for a few days and finally gave up. I finally resolved it using the default client config file that you get from the router when you set it up as a VPN server. That works as far as you update the server.conf file accordingly.
In regards to the pings not getting to the internal router’s LANs, I think the way to get it resolved is going to advance router settings (more settings-> advanced in GL-MT300N-V2). user root and same pass that you use for the router. Under Network ->Firewall are all the settings that can help you set-up the openvpn configuration. Activate the VPN client first to have visibility over the openvpn zone.