I am using OpenWRT LEDE (Cybrnook build) “LEDE-STABLE Reboot 17.01-SNAPSHOT r3356-8b9f7bd / LuCI lede-17.01 branch (git-17.110.53878-16ffea4)” on a WRT1900AC V1 and I have a Netgear DM200 VDSL2 Modem configured as a Bridge. I login via the WRT1900AC under “PPPoE” protocol. The WRT1900AC does the login and password with the DM200 just providing DSL connectivity; no routing or any thing else on the DM200.
The WRT1900AC has a static IP set at 192.168.2.1 and the DM200 has a static IP set at 192.168.5.1. They are on different subnets.
I have setup OpenVPN (VPN) and OpenVPN Policy-Based-Routing (OPR) services added to the LEDE build via the “System-Software” tab and all is working OK. I can use OPR to direct all my PCs or STBs (all with static IPs on 192.168.2.*) to either the WAN or the VPN (tun0).
The problem I have is that I cannot find a setup that allows me to access the DSL Modem DM200 at 192.168.5.1 with OPR enabled. I want to check from time to time the status of the VDSL2 connection (connect speed etc.) and that is available via the GUI of the DM200.
When I turn off (disable) OPR and just leave the VPN on/active I can get access to the DM200 via the setup provided by “Simplexion” at https://simplebeian.wordpress.com/2014/03/12/accessing-your-modem-from-openwrt-router/. I changed the IPs to my setup and named the new interface “DSL_Modem” with a static IP of 192.168.5.2 and mask of 255.255.255.0. and the physical interface of: “Switch VLAN: "eth1.2" (DSL_Modem, wan, wan6)”
I have tried making an entry (top of config=first priority) to OPR configuration that I thought would allow access to the DM200 but it did not work. I did a few different setups but no luck. Entry to “/etc/config/openvpn-policy-routing” config file is:
How can I keep the VPN and OPR services enabled/active and still allow me to access the DM200 DSL Modem GUI at 192.168.5.1 from PCs with static IPs of 192.168.2.* on my WRT1900AC router?
Anyone with deep VLAN/iptables expertise can help out? OPR creates a new chain in the mangle table and creates iptables rules based on user-created policies. But for the life of me I can't figure out why it breaks access to the modem.
But for me one problem remains as i'm not able to enable "strict policy enforcement" without loosing access to my modem.
The problem seems that there is no Gateway IP set for my modem interface and if i set one i loose access to the internet because my router will not use pppoe anymore and instead trying to use my modem gateway IP for the internet connection.
Thanks for your reply. I've asked for some help in the offical VPR thread but no one realy replied to my problem...
The only response was this:
Yes, the 0.0.0.0 was being detected as invalid gateway in some of the newer versions only. Please try the vpn-policy-routing 0.0.2-27 where this code was regressed.
I've installed version 0.0.2-27 and also 0.0.2-28 but it didn't help.
I was so happy when i saw your solution with the modem and it did work but sadly "strict enforcement" breaks the solution and therefore i don't have a working killswitch for my VPN.
In my case im using a bridged modem and my WRT3200 does the PPPoE connection and everything else.
As i said, the problem seems to be that there is no gateway set for my modem interface and therfore VPR reports the gateway of the modem interface as 0.0.0.0.
If i set the Modem IP as gateway i loose internet access as the PPPoE doesn't work as IPv4 Upstream connection anymore. It's so weird and i can't help myself...
I've created an issue thread at github, maybe this problem can get fixed in future versions.
Anyway i'm still hoping that someone is able to help me with this problem.
I had the same issue as yourself, and thankfully I was able to gain access to my bridged modem because of your posts. I then encountered the same problems when using strict policy enforcement.
A way around this for me was to disable strict enforcement in VPR and add a firewall rule to my firewall config that prevents forwarding for my VPN clients (they have a specific IP range) to the WAN interface.
That way I can prevent them from accessing the internet if the VPN interface is down.
I then encountered the same problems when using strict policy enforcement.