VPN Policy-Based Routing + Web UI -- Discussion

It is difficult to suggest much without some output from the router, which may be why you haven't got much response before.

I have a reasonably similar setup (except cable router put in bridge mode with LEDE box connected) and I have a policy specifying 'local addresses/devices' as my LAN subnet 192.168.1.0/24 and 'remote addresses/domains' as the address of the router, which is 192.168.100.1

If that doesn't help can you provide output of this command
/etc/init.d/vpn-policy-routing status

Is this a VPR Policy entry and is it one entry or two entries? Can you provide a sample from your config file?

The output of "/etc/init.d/vpn-policy-routing status" from my setup is as follows:

Active IPv4-Routes

Network			Target			IPv4-Gateway	Metric	Table
wan				0.0.0.0/0		XXX-XXX.34.0	0		201
NLD_PIA_VPN		0.0.0.0/0		XX.59.XX.X		0		202
GBR_PIA_VPN		0.0.0.0/0		XX.87.XX.X		0		203
wan				0.0.0.0/0		XXX-XXX.34.0	0		main
NLD_PIA_VPN		XX.59.XX.X		-				0		main
GBR_PIA_VPN		XX.87.XX.X		-				0		main
lan				192.168.2.0/24	-				0		main
DSL_MODEM		192.168.5.0/24	-				0		main
wan				XXX-XXX.34.0	-				0		main

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VPR Status Output:

root@FIREBASEROUTER:~# /etc/init.d/vpn-policy-routing status
vpn-policy-routing 0.0.2-22 running on Lede SNAPSHOT. WAN (IPv4): wan/dev/XXX-XXX.34.0.
============================================================
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         dsl-XXX-XXX-34- 0.0.0.0         UG    0      0        0 pppoe-wan
IPv4 Table 201: default via XXX-XXX.34.0 dev pppoe-wan
IPv4 Table 201 Rules:
32756:  from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via XX.59.XX.X dev tun0
IPv4 Table 202 Rules:
32755:  from all fwmark 0x20000 lookup 202
IPv4 Table 203: default via XX.87.XX.X dev tun1
IPv4 Table 203 Rules:
32754:  from all fwmark 0x30000 lookup 203
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.2.206/32 -m comment --comment GalaxyTabA6_CM -c 58 16156 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.205/32 -m comment --comment Samsung_S8_CM -c 10 2040 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.204/32 -m comment --comment Samsung_S8_KJM -c 124 15365 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.203/32 -m comment --comment SamsungGearS3 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.202/32 -m comment --comment SurfacePro4_WIFI -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.201/32 -m comment --comment SurfacePro4_Ether -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.200/32 -m comment --comment ASUS_Zenbook -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.199/32 -m comment --comment VuPlusZero_Spare -c 3 142 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -s 192.168.2.198/32 -m comment --comment VuPlusZero_CAM -c 10 987 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.197/32 -m comment --comment VuPlusZero_ANM -c 1 265 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.196/32 -m comment --comment DM7020HD_Master -c 2 110 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.195/32 -m comment --comment DM7020HD_New -c 13828 571662 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.194/32 -m comment --comment STD2_Chromecast -c 1006 92956 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.193/32 -m comment --comment STD1_Chromecast -c 217 18300 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.192/32 -m comment --comment Ultra1_Chromecast_WIFI -c 174 12948 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.191/32 -m comment --comment Ultra1_Chromecast_Ether -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.190/32 -m comment --comment GalaxyTabA6_KJM -c 50 17561 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.189/32 -m comment --comment ANM_Nexus7Tablet -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.188/32 -m comment --comment CAM_Nexus7Tablet -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.187/32 -m comment --comment ANM_KindleHD -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.186/32 -m comment --comment Work_LapTopWIFI -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.185/32 -m comment --comment Spare -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.184/32 -m comment --comment Raspberry_Pi_1 -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.183/32 -m comment --comment ANM_LaptopSamsungWiFi -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.182/32 -m comment --comment ANM_LaptopSamsungEther -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.181/32 -m comment --comment FireBaseOneNew_D_Link -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.180/32 -m comment --comment FireBaseOneNew_Main -c 823 129799 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.179/32 -m comment --comment ANM_GalaxyA3 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.178/32 -m comment --comment CAM_GalaxyA3_2016 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.177/32 -m comment --comment Acer_LaptopWIFI -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.176/32 -m comment --comment Acer_LaptopEther -c 252 31450 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.175/32 -m comment --comment GalaxyS7_GSM -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.174/32 -m comment --comment GSMNexusS_SpareGSM -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.173/32 -m comment --comment Thrive_USBEtherAdapter -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.172/32 -m comment --comment Thrive_ToshibaTablet -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.171/32 -m comment --comment HP_OfficeJetPro8620_WiFi -c 3 96 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.170/32 -m comment --comment HP_OfficeJetPro8620_LAN -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.169/32 -m comment --comment ANM_FireBaseKids2 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.168/32 -m comment --comment LaptopVaioEthernet -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.167/32 -m comment --comment LaptopVaioWIFI -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.166/32 -m comment --comment XboxOne_WIFI -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.165/32 -m comment --comment XboxOne_Ether -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.164/32 -m comment --comment Ford -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.163/32 -m comment --comment Raspberry_Pi_3 -c 8 516 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -s 192.168.2.162/32 -m comment --comment CM_GalaxyA3_2016 -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -s 192.168.2.161/32 -m comment --comment SkyHD_STB_WIFI -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -s 192.168.2.160/32 -m comment --comment SkyHD_STB_Ether -c 240 110544 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set GBR_PIA_VPN dst -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set NLD_PIA_VPN dst -c 0 0 -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 NLD_PIA_VPN hash:net family inet hashsize 1024 maxelem 65536 comment
create GBR_PIA_VPN hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]
root@FIREBASEROUTER:~#

Wow lots more policies than I have, I grouped a lot of mine up into a subnet though aligned with a DHCP allocation pool, then any device i want to control specifically is allocated an address outside that range, and I have a specific policy in VPR for it.

Anyway without looking too far into it, your route table looks good (was interested in default route), an issue I had initially was lack of the route-nopull option in openvpn, which resulted in that VPN taking over default route, so anything not explicitly covered in a policy to go via wan, went via that VPN.

Anyway policy config for connecting to my cable router (in bridge mode) is this:

config policy
        option interface 'wan'
        option comment 'To Cable Router'
        option local_addresses '192.168.1.0/24'
        option remote_addresses '192.168.100.1'

Thanks, will try on the weekend.

Yes, I have "route_nopull" set in OpenVPN for both VPN connections so the VPN provider (PIA in my case) does not set the routes as it normally would.

@stangri

Just FYI, when you have multiple VPNs/Interfaces the "Service Status" information is truncated. I have 5 VPNs/Interfaces as as you can see by the screenshot below, the last one (DSL_Modem_GUI) is cut-off.

You may want to consider a multiple line entry for this status line.

VPR%20Service%20Status%20Sample

Thanks for all your hard work on this project.

1 Like

Success!!

I have used the VPR "list supported_interface" option to manually allow VPR to use the "DSL_Modem" interface I set up with the DSL Modem's subnet.

I have put this VPR Policy at the top (priority) and it now works great, I can access the DSL Modem with VPR active.

If needed, see my prior posts on how to setup the "DSL_Modem" interface.

The VPR and Network config entries I am using are below for those in a similar situation.

config vpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option strict_enforcement '0'
	option dnsmasq_enabled '1'
	option udp_proto_enabled '1'
	list supported_interface 'DSL_MODEM'
	option enabled '1'

config policy
	option comment 'DSL_Modem_GUI'
	option interface 'DSL_MODEM'
	option local_addresses '192.168.2.1/24'
	option remote_addresses '192.168.5.1/24'

Network Config

config interface 'DSL_MODEM'
	option proto 'static'
	option ifname 'eth1.2'
	option delegate '0'
	option ipaddr '192.168.5.100'
	option netmask '255.255.255.0'

Add the 'DSL_MODEM' interface to the same Firewall Zone as the VPNs.

This is for a WRT3200ACM on Davidc502 latest image build so the "option ifname 'eth1.2'" may be different for other routers. It is what the WAN is linked to.

1 Like

Hi all,

Coming back to my previous post, I'm still stuck.
What I want to achieve: Remove my TV from the VPN tunnel to have it go directly to my wan. (For netflix streaming)

The problem: Removing it from the VPN is no issue, using the following rule:
image

Except, I cannot get Netflix to work. All the other sites I tried work flawless, except for Netflix.
I was suggested to search in the forum, since the answer would be there somewhere. Unfortunately, I cannot find it.

Troubleshooting:
-Ping Netflix.com, no issue
-Wireshark connection to Netflix: it seems that the handshake is not completing
-Completely starting from a new router config

Can anybody point me in the right direction?

Thank you all!

While having different devices being excluded from the VPN sounds fine, how would I configure the tool if I wanted to be connected to the VPN but could still SSH into the router via the public IP? My naive guess of

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 '0'

config policy
	option interface 'wan'
	option comment 'SSH'
	option local_ports '22'
	option remote_ports '22'

does not seem to work.

Similarly to this you need to enable an OUTPUT chain and it needs to be a local_ports only policy.

I changed that and I still can't reach my router. Do I need other static routes? Why would my proposed solution not work? Do I need specific interface forwardings for this?

Does it work without the vpn client running on your router?

First off, this is a great addition to OpenWRT/LEDE project and I really appreciate all the work you have put into it. Unfortunately, I am having an issue that I can't seem to correct.

I have both a OpenVPN client (Commercial VPN Access) and a OpenVPN server (to access my local network remotely). I have set these up using the wiki's posted previously in this thread. ( * OpenVPN Client and OpenVPN Client & Server (Simultaneously))

By default, my traffic is going through my WAN interface and I use a policy to route a range of IP Addresses though the VPNCLIENT. Everything is working fine except for the machines in this range. When I access my network via the OpenVPN server they are no longer accessible. Any help that you can provide would be appreciated.

Attached is the support output

vpn-policy-routing 0.0.2-22 running on LEDE 17.01.4. WAN (IPv4): wan/dev/24.145.217.1.
============================================================
Dnsmasq version 2.78  Copyright (c) 2000-2017 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
============================================================
Routes/IP Rules
default         user-0c93m81.ca 0.0.0.0         UG    0      0        0 eth0.2
IPv4 Table 201: default via xxx.xxx.xxx.xxx dev eth0.2
IPv4 Table 201 Rules:
32747:	from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via xxx.xxx.xxx.xxx dev tun0
IPv4 Table 202 Rules:
32746:	from all fwmark 0x20000 lookup 202
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -s 192.168.13.96/28 -m comment --comment Fixed_Addresses__VPN_ -c 165 18187 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -p tcp -m multiport --sports 51194 -m comment --comment OpenVPN_Server -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -p tcp -m multiport --sports 51194 -m comment --comment OpenVPN_Server -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_PREROUTING -m set --match-set vpnclient dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
IP Tables OUTPUT
-N VPR_OUTPUT
-A VPR_OUTPUT -p tcp -m multiport --sports 51194 -m comment --comment OpenVPN_Server -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_OUTPUT -p tcp -m multiport --sports 51194 -m comment --comment OpenVPN_Server -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
-A VPR_OUTPUT -m set --match-set vpnclient dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_OUTPUT -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
add wan 208.82.237.145 comment "Craigslist.com: www.craigslist.com"
add wan 216.58.217.132 comment "Google.com: www.google.com"
add wan 216.58.217.100 comment "Google.com: www.google.com"
add wan 23.79.34.226 comment "Barnesandnoble.com: www.barnesandnoble.com"
add wan 23.79.66.247 comment "Walmart.com: www.walmart.com"
add wan 23.79.1.160 comment "Healthcare.gov: www.healthcare.gov"
create vpnclient hash:net family inet hashsize 1024 maxelem 65536 comment
add vpnclient 94.130.80.38 comment "MyAnonamouse.net (VPN): www.myanonamouse.net"
============================================================

and my Config file


config openvpn-policy-routing 'config'
	option verbosity '2'
	option ipv6_enabled '0'
	option strict_enforcement '1'
	option output_chain_enabled '1'
	list ignored_interface 'vpnserver'
	list ignored_interface 'VPNSERVER'
	option dnsmasq_enabled '0'
	option udp_proto_enabled '1'
	option enabled '1'

config policy
	option comment 'OpenVPN Server'
	option local_ports '51194'
	option interface 'wan'

config policy
	option interface 'wan'
	option comment 'Barnesandnoble.com'
	option remote_addresses ' www.barnesandnoble.com'

config policy
	option interface 'wan'
	option comment 'Craigslist.com'
	option remote_addresses 'www.craigslist.com'

config policy
	option interface 'wan'
	option comment 'Google.com'
	option remote_addresses 'www.google.com'

config policy
	option interface 'wan'
	option comment 'Healthcare.gov'
	option remote_addresses 'www.healthcare.gov'

config policy
	option interface 'wan'
	option comment 'Walmart.com'
	option remote_addresses ' www.walmart.com'

config policy
	option comment 'MyAnonamouse.net (VPN)'
	option remote_addresses 'www.myanonamouse.net'
	option interface 'vpnclient'

config policy
	option comment 'Fixed Addresses (VPN)'
	option local_addresses '192.168.13.96/28'
	option interface 'vpnclient'

The more I think about it, the more I realize that maybe the OpenVPN in TAP mode should be used in this scenario, @JW0914 is an OpenVPN expert, maybe he can suggest a better approach for you or at least advise on the feasibility of the TAP mode. If you find a satisfactory solution, please post it either here or better yet in the Wiki.

Please clarify which of the following is your issue:

  1. You lose access to WAN when routing traffic from your remote access client through the commercial VPN
    i.e. you can't WAN -> OpenVPN Server -> Commercial VPN Client Interface -> WAN
    OR
  2. You're unable to reach devices behind the router when accessing from a remote client
    i.e. you can't WAN -> OpenVPN Server -> LAN

Please perform the steps in Troubleshooting for your next post.

I'd have to do some research if #1 is the issue, as TAP is normally used when access is required to RFC1918 subnets that are behind two or more routers, as there's no way for either router to know what RFC1918 subnets are behind the other.

  • For all intents and purposes, TAP provides a transparent bridge between networks, operating at Layer 2 like a virtual router.

Thanks for the replies.

Stangri

I am more then willing to try using TAP if you think that will help. However, In my process to determine where the problem was, I setup a StrongSWAN Server and had the identical issue using it to connect remotely. I am not sure what type of connection it uses, so I don't know if this will help you or not?

What I am wondering is when I set this policy (IP Address -> VPN Client) does it capture all traffic leaving that IP Address? I assume that there is some sort of exemption for my LAN, as I can access the IP Address just fine within my LAN (network shares, web pages, etc). However, since the OpenVPN Server is using a different subnet could the policy be capturing that traffic and sending it via VPN Client instead of back to the OpenVPNServer? Would a firewall rule, or manual entry into firewall.user override this behavior?

JW0914

The problem I am experiencing is almost option #2.

If I don't have any policies set for the IP Addresses in my LAN, everything works fine. (Wan -> OpenVPN Server -> Lan.)

However, as soon as I set a policy for any IP Address in my LAN, I can no longer access that machine via the OpenVPN Server. ( Wan -> OpenVPN Sever -> no response) Other IP Addresses work just fine. (Wan -> OpenVPN Server -> Lan.)

Here is the server log using verb 5

Mon Aug 13 10:02:08 2018 us=244193 OpenVPN 2.4.4 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Aug 13 10:02:08 2018 us=244542 library versions: OpenSSL 1.0.2o  27 Mar 2018, LZO 2.10
Mon Aug 13 10:02:08 2018 us=268512 Diffie-Hellman initialized with 2048 bit key
Mon Aug 13 10:02:08 2018 us=274035 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Aug 13 10:02:08 2018 us=274462 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Aug 13 10:02:08 2018 us=274867 TLS-Auth MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ]
Mon Aug 13 10:02:08 2018 us=323669 TUN/TAP device ovpns0 opened
Mon Aug 13 10:02:08 2018 us=324097 TUN/TAP TX queue length set to 100
Mon Aug 13 10:02:08 2018 us=324489 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Aug 13 10:02:08 2018 us=325013 /sbin/ifconfig ovpns0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Mon Aug 13 10:02:08 2018 us=355149 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Mon Aug 13 10:02:08 2018 us=355635 Could not determine IPv4/IPv6 protocol. Using AF_INET
Mon Aug 13 10:02:08 2018 us=356042 Socket Buffers: R=[87380->87380] S=[16384->16384]
Mon Aug 13 10:02:08 2018 us=356487 Listening for incoming TCP connection on [AF_INET][undef]:51194
Mon Aug 13 10:02:08 2018 us=356891 TCPv4_SERVER link local (bound): [AF_INET][undef]:51194
Mon Aug 13 10:02:08 2018 us=357366 TCPv4_SERVER link remote: [AF_UNSPEC]
Mon Aug 13 10:02:08 2018 us=357738 MULTI: multi_init called, r=256 v=256
Mon Aug 13 10:02:08 2018 us=358267 IFCONFIG POOL: base=192.168.200.2 size=252, ipv6=0
Mon Aug 13 10:02:08 2018 us=358833 MULTI: TCP INIT maxclients=1024 maxevents=1028
Mon Aug 13 10:02:08 2018 us=359695 Initialization Sequence Completed
Mon Aug 13 10:02:33 2018 us=136073 MULTI: multi_create_instance called
Mon Aug 13 10:02:33 2018 us=136808 Re-using SSL/TLS context
Mon Aug 13 10:02:33 2018 us=137322 LZ4 compression initializing
Mon Aug 13 10:02:33 2018 us=139020 Control Channel MTU parms [ L:1624 D:1182 EF:68 EB:0 ET:0 EL:3 ]
Mon Aug 13 10:02:33 2018 us=139812 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Mon Aug 13 10:02:33 2018 us=140537 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Mon Aug 13 10:02:33 2018 us=140885 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Mon Aug 13 10:02:33 2018 us=141413 TCP connection established with [AF_INET]174.233.134.118:5541
Mon Aug 13 10:02:33 2018 us=141769 TCPv4_SERVER link local: (not bound)
Mon Aug 13 10:02:33 2018 us=142141 TCPv4_SERVER link remote: [AF_INET]174.233.134.118:5541
RMon Aug 13 10:02:34 2018 us=18195 174.233.134.118:5541 TLS: Initial packet from [AF_INET]174.233.134.118:5541, sid=8bcbf6e4 03b4d310
WRRWWWWRRRRWRWRMon Aug 13 10:02:35 2018 us=659468 174.233.134.118:5541 VERIFY OK: depth=1, C=GB, ST=London, O=WWW Ltd.
Mon Aug 13 10:02:35 2018 us=672654 174.233.134.118:5541 VERIFY OK: depth=0, CN=my-client
WRMon Aug 13 10:02:35 2018 us=944944 174.233.134.118:5541 peer info: IV_VER=2.5_master
Mon Aug 13 10:02:35 2018 us=945351 174.233.134.118:5541 peer info: IV_PLAT=android
Mon Aug 13 10:02:35 2018 us=945709 174.233.134.118:5541 peer info: IV_PROTO=2
Mon Aug 13 10:02:35 2018 us=946067 174.233.134.118:5541 peer info: IV_NCP=2
Mon Aug 13 10:02:35 2018 us=946424 174.233.134.118:5541 peer info: IV_LZ4=1
Mon Aug 13 10:02:35 2018 us=946778 174.233.134.118:5541 peer info: IV_LZ4v2=1
Mon Aug 13 10:02:35 2018 us=947265 174.233.134.118:5541 peer info: IV_LZO=1
Mon Aug 13 10:02:35 2018 us=947657 174.233.134.118:5541 peer info: IV_COMP_STUB=1
Mon Aug 13 10:02:35 2018 us=948063 174.233.134.118:5541 peer info: IV_COMP_STUBv2=1
Mon Aug 13 10:02:35 2018 us=948427 174.233.134.118:5541 peer info: IV_TCPNL=1
Mon Aug 13 10:02:35 2018 us=948803 174.233.134.118:5541 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.5
WRMon Aug 13 10:02:36 2018 us=76164 174.233.134.118:5541 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Mon Aug 13 10:02:36 2018 us=76713 174.233.134.118:5541 [my-client] Peer Connection Initiated with [AF_INET]174.233.134.118:5541
Mon Aug 13 10:02:36 2018 us=77403 my-client/174.233.134.118:5541 MULTI_sva: pool returned IPv4=192.168.200.2, IPv6=(Not enabled)
Mon Aug 13 10:02:36 2018 us=78964 my-client/174.233.134.118:5541 MULTI: Learn: 192.168.200.2 -> my-client/174.233.134.118:5541
Mon Aug 13 10:02:36 2018 us=79374 my-client/174.233.134.118:5541 MULTI: primary virtual IP for my-client/174.233.134.118:5541: 192.168.200.2
RMon Aug 13 10:02:37 2018 us=216104 my-client/174.233.134.118:5541 PUSH: Received control message: 'PUSH_REQUEST'
Mon Aug 13 10:02:37 2018 us=216961 my-client/174.233.134.118:5541 SENT CONTROL [my-client]: 'PUSH_REPLY,topology subnet,redirect-gateway def1,route-gateway dhcp,route 192.168.200.0 255.255.255.0,dhcp-option DNS 192.168.1.1,compress lz4,persist-key,persist-tun,DOMAIN lan,route-gateway 192.168.200.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.200.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Mon Aug 13 10:02:37 2018 us=217396 my-client/174.233.134.118:5541 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Aug 13 10:02:37 2018 us=217835 my-client/174.233.134.118:5541 Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ]
Mon Aug 13 10:02:37 2018 us=219287 my-client/174.233.134.118:5541 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Aug 13 10:02:37 2018 us=219716 my-client/174.233.134.118:5541 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
WWRRwRwRwrWRwRwRwRwWRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwWRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwWRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwWRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwWRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwRwMon Aug 13 10:03:32 2018 us=935002 my-client/174.233.134.118:5541 Connection reset, restarting [0]
Mon Aug 13 10:03:32 2018 us=935388 my-client/174.233.134.118:5541 SIGUSR1[soft,connection-reset] received, client-instance restarting
Mon Aug 13 10:03:32 2018 us=936708 TCP/UDP: Closing socket

I am using android devices to connect to the Open VPN Server, using the "OpenVPN for Android" app. I can't seem to find an option to set the verb level within the app. If I set it in the OVPN file before importing it, the app resets it to verb 4 when importing it into the app. If I set a custom option to verb 7 after importing the OVPN file, the generated config file stills adds verb 4. Do you know of another android app I could use to get this log?

Stangri

After, my last post I started toying around with the idea of the override and I found a relatively ugly workaround. I hardcoded the address range for my OpenVPN Server as a not destination-address on line 240 of your code.

	[ -n "$laddr" ] && param="$param -s $laddr ! -d 192.168.200.0/24"

The support output now shows

-A VPR_PREROUTING -s 192.168.13.96/28 ! -d 192.168.200.0/24 -m comment --comment Fixed_Addresses__VPN_ -c 586 61582 -j MARK --set-xmark 0x20000/0xff0000

This seems to have worked for me and should not cause me any other issues as I only have the single Source Range Policy being implemented. I will continue testing for the next couple of days, and let you know If any other problems pop up.

Would it be possible to add a general ignore this range to the package, or to a specific policy? If memory serves you already have a ignore interface coded for the package, which I have set to the vpnserver. Is there anyway to get the IP Address pool from this interface, and set this automatically? Or would it be better to let the user set it manually?

Thanks for all your help.

1 Like

I have an odd VPN policy routing issue I am trying to debug. I use a OpenVPN client with IVPN for most of my devices however I use VPN policy routing to go to the WAN for my Roku streaming boxes. For a few years, I had no trouble accessing Bank of America. Recently, they shut down access through the IVPN server. Oh well, so I decided to create a VPN policy such that traffic with remote domains of www.bankofamerica.com and secure.bankofamerica.com would be routed to WAN. That worked miserably. When I ran /etc/init.d/vpn-policy-routing support, I found that the IP addresses used in the routing table for the two BofA addresses were slightly wrong. I ran nslookup, got the correct IP addresses and used them as the remote addresses rather than domains, and it all worked briefly. After a short time, it stopped working and the IPs changed again. The IP address change is slight, from 171.161.206.100 to 171.161.198.100, for example.

This feels like a weird bug. What should I investigate?

Thank you for posting this. Let me think about how to best approach implementation.

Is dnsmasq support enabled?

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?