VPN Policy-Based Routing + Web UI -- Discussion

Yes. In vpn-policy-routing, I have:

config vpn-policy-routing 'config'
	option strict_enforcement '1'
	option dnsmasq_enabled '1'
	option ipv6_enabled '1'
	option verbosity '0'
	option enabled '1'

Also, dnsmasq-full is installed, as the instructions request. This morning there is yet another new, slightly different IP address for www.bankofamerica.com, 171.161.202.100. Other thoughts?

Hi,

I have a strange issue with vpn-policy-routing. I'm using the Turris Omnia router and I set-up multiple VLANs. However, I don't want the VPN for the DMZ VLAN and I don't want VPN for my public IP address from my LAN. So VPR is configure that way:

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	option enabled '1'

config policy
	option interface 'wan'
	option local_addresses 'x.x.x.0/24'
	option comment 'DMZ'

config policy
	option interface 'wan'
	option remote_addresses '1.2.3.4'
	option local_addresses 'x.x.x.0/24'
	option comment 'IP public from LAN'

Well lets say it works fine. BUT, when VPR started I can't contact my VPN anymore from my LAN. Usually, I'm using SSH.

Is there a way to solve this issue ?

Please let me know if you need further details.

The BoA seems to use the nameserver which resolves into 171.161.206.99, 171.161.203.99, 171.161.199.99, 171.161.207.99, 171.161.202.99, 171.161.198.99.

So based on your experience I would just add the policy with the following remote IP addresses: 171.161.206.100, 171.161.203.100, 171.161.199.100, 171.161.207.100, 171.161.202.100, 171.161.198.100 for WAN.

I'm not sure I understand.

Stan, thanks. I'd already discovered three of the six so it's help for you to identify the others. For what its worth, there is also secure.bankofamerica.com, which ends in .200 rather than .100. So I'll also add thosee six addresses.

@stangri

Well, sorry I was tired, you can forget this sentence.

My DMZ don't go through VPN. With VPR it works fine. But the issue is I can't access my DMZ from my LAN when VPR is running. I mainly use SSH and HTTP to access my box in DMZ from my LAN. For now, I don't what to check.

Hey, based on your feedback I've implemented new options: append_local_rules and append_remote_rules. They are also exposed via WebUI in Advanced tab. In your case, you'll need to set append_local_rules='! -d 192.168.200.0/24' in the VPR config.

You may need to use the options I referred above, but in your case it should be append_remote_rules with value `! -s <your_dmz_netmask_here>'.

That's my guess, you may want to ask @LostTech69 for help.

3 Likes

Oh, the new functionality is enabled in:
vpn-policy-routing 0.0.2-24
luci-app-vpn-policy-routing 33

@stangri

Thanks but still not working :frowning:

@LostTech69

Hi, I have an issue when VPR is running: I can't access my box in the DMZ VLAN from my LAN VLAN using SSH or HTTP (using private IP address). In fact, the DMZ VLAN is not accessible anymore. But, when I disable VPR access to DMZ VLAN work again.

To resume, when VPR is running it works as intended but I can't access the box in DMZ from internal network with private IP address and when VPR is disable I can access my box.

Below my VPR setting:

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option ipset_enabled '1'
	option dnsmasq_enabled '0'
	option strict_enforcement '1'
	option enabled '1'
	option append_remote_rules '! -s 10.42.69.0/24'

config policy
	option interface 'wan'
	option local_addresses '10.42.69.0/24'
	option comment 'DMZ'

config policy
	option interface 'wan'
	option remote_addresses '1.2.3.4'
	option local_addresses '10.42.42.0/24'
	option comment 'IP public from LAN'

Please let me know if you need further details.

Thanks

Hi,

Thanks for this - I'm having some problems getting it working, but it looks really useful.

I'm running both an openvpn server and client: the server uses tap and is bridged to the lan, the client is standard tun. Up until now I've used the openwrt static routes functionality to direct various ip destinations via the vpn client. It worked, but was a bit limited.

My vpn-policy-routing config is:

config vpn-policy-routing 'config'
	option verbosity '2'
	option dnsmasq_enabled '1'
	option strict_enforcement '0'
	option ipv6_enabled '0'
	list ignored_interface 'eth0'
	list ignored_interface 'guest'
	list ignored_interface 'lan'
	option enabled '1'

config policy
	option interface 'nordvpntun'
	option name 'whatsmyip.org'
	option remote_addresses 'whatsmyip.org'

/etc/init.d/vpn-policy-routing support:

vpn-policy-routing 0.0.2-24 running on OpenWrt SNAPSHOT. WAN (IPv4): wan/dev/62.3.80.17.
============================================================
Dnsmasq version 2.80test2  Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify dumpfile
============================================================
Routes/IP Rules
default         losubs.subs.bng 0.0.0.0         UG    0      0        0 pppoe-wan
IPv4 Table 201: default via 62.3.80.17 dev pppoe-wan
IPv4 Table 201 Rules:
32631:	from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.8.8.4 dev tun0
IPv4 Table 202 Rules:
32630:	from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -m set --match-set nordvpntun dst -c 14 840 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create nordvpntun hash:net family inet hashsize 1024 maxelem 65536 comment
add nordvpntun 204.11.35.98
create wan6 hash:net family inet6 hashsize 1024 maxelem 65536 comment
create nordvpntun6 hash:net family inet6 hashsize 1024 maxelem 65536 comment
============================================================
DNSMASQ ipsets
ipset=/whatsmyip.org/nordvpntun # whatsmyip.org
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]

/etc/init.d/vpn-policy-routing reload:

Creating table 'wan/62.3.80.17' [✓]
Creating table 'nordvpntun/10.8.8.4' [✓]
Routing 'whatsmyip.org' via nordvpntun [✓]
vpn-policy-routing 0.0.2-24 started on wan/62.3.80.17 nordvpntun/10.8.8.4 [✓]
vpn-policy-routing 0.0.2-24 monitoring interfaces: wan nordvpntun [✓]

I'm just testing using whatsmyip.org at the moment; unfortunately when the service is running I can't connect to that site.

Can you help, please?

Thanks,
Tim

Because of these:

Looks like VPR is working. Something else must be getting in a way.

Yes, it's odd if I put in a static route via the VPN ip, it works fine:

ip route add 204.11.35.98 via 10.8.8.4 dev tun0

Then I can browse to whatsmyip.org and it reports the VPN ip address. There just seems to be a problem routing via table 202.

The packets and bytes are increasing when I look at the iptables rule, but the connection just times out. Should there be more than the default route in 202? at the moment it's just:

root@mason:~# ip route list table 202
default via 10.8.8.4 dev tun0

Hi @algebro

Can you add more context to the solution you provided ? I'm not sure of some values from your script.

Create the following script to automatically set up the DMZ routing rules and configure it to start on boot:

#!/bin/sh

ip rule add from 10.10.10.0/24 table dmz
ip route add default via <ISP WAN Gateway IP> dev eth1.2 table dmz
ip route add 192.168.1.0/24 dev br-lan table dmz

ip rule add to 10.10.10.0/24 table todmz
ip route add 10.10.10.0/24 dev eth0.3 table todmz

So ??

10.10.10.0/24 <-- DMZ subnet
eth1.2 <-- DMZ interface ??
192.168.1.0/24 <-- LAN subnet ??
eth0.3 ???

Thank you.

hey @jondifool,

10.10.10.0/24 = DMZ subnet
eth1.2 = WAN interface
192.168.1.0/24 = LAN subnet
eth0.3 = DMZ interface

The commands do the following:

  1. Add a rule stating that any traffic coming from 10.10.10.0/24 should use the DMZ routing table
  2. Add a default route directing traffic from the DMZ to the WAN using the WAN interface
  3. Add a route to the LAN from the DMZ using the LAN interface (br-lan). This allows me to SSH to the devices on the DMZ from the LAN, but I also added firewall policies that block new connections from the DMZ to the LAN.
  4. Add a rule stating any traffic coming TO 10.10.10.0/24 should use a separate "todmz" routing table
  5. Add a route to the "todmz" routing table saying any traffic going to the DMZ subnet should use the DMZ interface.

Hope that helps!

Does vpn policy-based routing work with IPsec based solutions (Strongswan)?

Not yet. I don't know enough about Strongswan to implement the support. If you use Strongswan and can PM me your /etc/config/network and the output of ifconfig and ip -4 route, I can look into implementing it.

Ok! I am planning to install it today with my updated build.
I've seen up to 200% increase in speeds when using IKEV2 over OpenVPN. That's why I am looking into using it!

Cheers man :slight_smile: thank you

I'm loosing access to my bridged VDSL modem if the vpn-policy-routing service is running and a policy is configured.
It doesn't matter if i select VPN or WAN for the client.
If there is no policy configured for the client i'm able to access my modem just fine even if the service is up and running...

Any ideas?

edit: I found the solution for my problem in this thread... Sorry i was kinda blind!
Link: VPN Policy-Based Routing + Web UI -- Discussion

The modem access solution only seems to work with option strict_enforcement '0' but than there is no active killswitch if the VPN connection goes down.
I've also noticed that IP shown in the VPN Policy Routing GUI is modem/0.0.0.0 but wan and vpn does have the right gateway ip's next to their name... :confused:

Any idea how to fix this and is there any way to get the killswitch + modem access working at the same time?

@stangri
Any chance of getting an older version of VPR? I recently upgraded to OpenWRT 18.06.01, with fresh settings and installed the latest version of VPR 0.26. Now, I am having various strange issues. You helped me work some things out with version 0.24 and everything was working fine then. If you could post 0.24 it would really help. Thanks