577

Thank you for the follow up. Inactive device errors are suppressed in vpn-policy-routing 0.1.0-26.

For the Command failed -- it's an artifact of using PROCD without an actual stay-in-memory daemon.

Can you post the output of ls -la /bin/true?

578

Works for me. Screenshot below:

Annotation%202019-09-07%20160020
Annotation%202019-09-07%201600201692×762 132 KB

579

root@XXXXXXXXXXXX:~# ls -la /bin/true
lrwxrwxrwx 1 root root 7 Aug 30 20:45 /bin/true -> busybox

580

I have no idea why are you still getting command failed then. Did it only happen on install? Does it happen on start/stop/reload?

581

Seems to only happen on upgrade, I did not notice it on install.

I did start/stop/reload and no such errors.

582

Cosmetic issue:

BTW I noticed that when I do a "Reload" the " Custom User File" entries get a check mark as OK but no text. Maybe parse the file name to ensure it is identified. Just a thought.

image

1 Like
583

Big update in vpn-policy-routing 0.1.1-1:

  1. Support prep for other DNS resolvers (besides dnsmasq) ipset features
  2. The remote_ipset and dnsmasq_ipset settings are now a single setting remote_ipset which could be none, ipset or dnsmasq.ipset
  3. LIke before, your current settings will be migrated automatically, no need to edit anything
  4. New ipsets are family-agnostic
  5. README has been updated to reflect changes

PS. If anyone is using this together with the unbound and you don't mind snapshot/master builds, please let me know.

1 Like
584

@stangri

Thanks, fixed nicely in your 0.1.1-1 update.

585

No, you didn't.

Probably. It certainly is possible with OpenVPN server on your router.

According to the config below, you didn't add the policy from the tutorial. Tutorial also depends on the server being configured specific way as it is explicitly stated.

Also, as with any split routing, you have to properly configure the firewall zone(s) for your VPN clients as well, otherwise no split routing.

586

Hi,

thanks for your reply! Nevertheless I am pretty confused right now.

I read many stuff in the last days and according to the DD-WRT and Tomato forums this seems to be more a firewall problem than anything else. See eibgard's explanation here:

So after all this reading I came to the conclusion, that getting the packets from my phone OVER the router into Mullvad is not possible, since my firewall rejects this. I already tried OpenVPN on DD-WRT and was not able to make it run, Wireguard is used now by me to simplify things. Now you tell me, I did not get this right. So how can this work and what did I get wrong? It seems to be quite difficult, to setup a firewall like this.

Okay, back to my config now, following the tutorial. I tried to adopt this for Wireguard, how would it be right? Using exactly the same rules is not possible, since they are for OpenVPN I guess. But i see no difference. OpenVPN server is configured with TCP, a port and an IP. Same for me for wireguard, then created a rule according to that… I'm feeling really stupid here.

For the firewall:

Okay, now I am really confused. Is it necessary to add one zone for the client? In some posts in this thread it is mentioned that this is not necessary and make things complicated. LAN for Phone, WAN for VPN I thought. How is it right?

587

It's mainly the routing issue. It may be the firewall issue too if your firewall is not configured properly to allow split routing (if you've configured your firewall for a killswitch for example).

The post you linked is right on the money on what's happening.

Doesn't mean it's impossible. The README has the recipes specifically for that reason, to show how to run both VPN client and VPN server on the router at the same time wherever the default routing is set to the VPN or WAN.

You missed a part from the README, specifically this: option chain 'OUTPUT'.

Yeah, getting both VPN server and VPN client working on the router at the same time is sort of advanced stuff. You need to understand the problem with it.

588

I think I may have found a bug in the policy protocol (proto) handling. When that is set to "tcp", it seems to be treated as all protocols (including UDP and ICMP) rather than TCP only. Is that expected behaviour? Perhaps an "all" setting could be added for that and "tcp" made to only apply to TCP? Thanks.

589

Post your settings, as well as the output of reload and status commands.

590

Here it is:

root@OpenWrt:~# cat /etc/config/vpn-policy-routing

config vpn-policy-routing 'config'
        option verbosity '2'
        option local_ipset '0'
        option ipv6_enabled '0'
        list ignored_interface 'vpnserver'
        option boot_timeout '30'
        option iptables_rule_option 'append'
        option iprule_enabled '0'
        option chain_control '0'
        option remote_ipset 'ipset'
        option sort_control '1'
        option enable_control '1'
        option proto_control '1'
        option strict_enforcement '0'
        option enabled '1'

config include
        option path '/etc/vpn-policy-routing.netflix.user'
        option enabled '0'

config include
        option path '/etc/vpn-policy-routing.aws.user'
        option enabled '0'

config policy
        option name 'test'
        option remote_address '<ip_address_here>'
        option interface 'vpn'
        option proto 'tcp'

root@OpenWrt:~# service vpn-policy-routing reload
Creating table 'wan/eth0.2/192.168.8.1' [â“]
Creating table 'vpn/tun0/10.8.0.2' [â“]
Routing 'test' via vpn [â“]
vpn-policy-routing 0.1.1-1 started on wan/eth0.2/192.168.8.1[â“] vpn/tun0/10.8.0.2 

root@OpenWrt:~# service vpn-policy-routing status
running

Let me know if you need anything else.

591

Which OpenWrt is that?

PS. ipsets do seem to be protocol-agnostic. Let me think about it.

592

Hi Stangri,
I've compiled my OpenWRT build to OpenWRT SNAPSHOT r11033-2b342d01a2 (latest)
I custom packaged WireGuard via Makefile to latest ver 0.0.20190913-1
I can connect to Mullvad via WireGuard but your package (vpn-policy-routing 0.1.1-1) does not seem to recognize the new mullvad WG interface as it appears as zeros (0.0.0.0).

service vpn-policy-routing reload

Creating table 'wan/eth1.2/24.xxx.xx.x' [✓]
Creating table 'ipvanvpntun/tun0/172.xx.xx.xx' [✓]
Creating table 'mullvad/0.0.0.0' [✓]
Routing 'WANSubnet' via wan [✓]
Routing 'GEOsites' via wan [✓]
Routing 'Kijiji' via wan [✓]
Routing 'All443Tun' via ipvanvpntun [✓]
Routing 'lol1' via wan [✓]
Routing 'lol5' via wan [✓]
Routing 'lol6' via wan [✓]
Routing 'Skype' via wan [✓]
Routing 'lyric' via wan [✓]
Running /etc/vpn-policy-routing.aws.user [✓]
vpn-policy-routing 0.1.1-1 started on (strict mode): wan/eth1.2/24.xxx.xx.x ipvanvpntun/tun0/172.xx.xx.xx mullvad/0.0.0.0[✓]

I was having issues with Mullvad dropping out so I would like to test against the lastest WG build.
I'd love to help troubleshoot and get this sorted with you...

Thanks!

593

ip -4 a list dev mullvad

PS. I'm on 18.06.4 and have no issues whatsoever with wg connections to mullvad.

594

21: mullvad: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
inet 10.xx.xx.248/32 brd 255.255.255.255 scope global mullvad
valid_lft forever preferred_lft forever

595

what happens if you /etc/init.d/vpn-policy-routing reload manually?

596

/etc/init.d/vpn-policy-routing reload
Creating table 'wan/eth1.2/24.xxx.xx.1' [✓]
Creating table 'ipvanvpntun/tun0/172.xx.xx.6' [✓]
Creating table 'mullvad/0.0.0.0' [✓]
Routing 'WANSubnet' via wan [✓]
Routing 'GEOsites' via wan [✓]
Routing 'Kijiji' via wan [✓]
Routing 'All443Tun' via ipvanvpntun [✓]
Routing 'lol1' via wan [✓]
Routing 'lol5' via wan [✓]
Routing 'lol6' via wan [✓]
Routing 'Skype' via wan [✓]
Routing 'lyric' via wan [✓]
Running /etc/vpn-policy-routing.aws.user [✓]
vpn-policy-routing 0.1.1-1 started on (strict mode): wan/eth1.2/24.xxx.xx.1 ipvanvpntun/tun0/172.xx.xx.6 mullvad/0.0.0.0[✓]

same thing it comes up as 0.0.0.0