Assign VPN to only one client

Hello, everyone,

I have installed OpenVPN on OpenWRT using the following instructions: "https://openwrt.org/docs/guide-user/services/vpn/openvpn/client-luci". Everything works. However, I would like to Assign VPN to only one client. Can anyone help me how this works?

Many greetings
PD

Basically you would need both what was in the original setup, plus what you did for the VPN. So you would need to create VLAN, interfaces and firewall zones, so that you have:
lan > wan
lanvpn > tun

The following thread can provide some illustrations

@Hegabo: Thanks!

Can you or someone else please make a short tutorial with screenshots? Unfourtunately Iam a newbie.

You can also check this

Thank you - but unfortunately I do not understand this. :frowning: I only use the gui.

See Policy-Based Routing package by @stangri

Thanks, ilmwind. I installed it - but dont know at this moment, how the setting should look like.

By default OpenVPN-client makes default route (for all lan members) via tun adapter. You should correspondingly:

  1. Leave default route.
  2. Create policy in PBR in FORWARD chain to make route for single IP.

Like this?

1 Like

Yes, but make sure, that chain is FORWARD (sorry, not PREROUTING), and default route has been left unchanged.

(You can also do this config for a single IP instead of an interface.)

1 Like

I'm trying to do just that and facing 2 problems.

I have a lan interface made of wired connections bridged with 2 wireless networks, a wan for direct internet access over ISP and a PIA_VPN tunnel interface:

/etc/config/network without routes'n'rules
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd45:96a1:e4d6::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth1.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'pppoe'
	option password '***'
	option ipv6 '0'
	option username '***'
	option service 'SoftBank'
	list dns '1.1.1.1'
	list dns '1.0.0.1'
	option peerdns '0'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 0t'

config interface 'PIA_VPN'
	option proto 'none'
	option ifname 'tun0'

I would like to only route traffic from 192.168.1.13 through VPN.
So, along the lines of the advice linked above, I've added the following to /etc/config/network:

  • a separate route to rule all traffic over to the PIA_VPN interface into a separate table
# in /etc/config/network
config route
	option interface 'PIA_VPN'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option table '2'
  • and a rule to use this table for all traffic originating from 192.168.1.13
config rule
	option src '192.168.1.13/32'
	option dest '0.0.0.0/0'
	option priority '1'
	option lookup '2'

The result though is that in the default state of the system (one of the OpenVPN instances is started) any attempt to connect to the outside world from 192.168.1.13 fails on the first hop (the router):

pi@192.168.1.13:~ $ traceroute google.com
traceroute to google.com (172.217.175.78), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.748 ms  0.632 ms  0.647 ms
 2  * * *
 3  * * *
 . . .

While from everywhere else on the lan, including the router itself, everything goes, as expected, over through the ISP.

So this is the first problem I'd like to resolve: get that traffic from that one device to propagate over to the VPN tunnel when it's active. Have I messed something up or do I need anything special in the Firewall? Currently there is nothing much:

/etc/config/firewall
config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'PIA_VPN wan'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

(/etc/firewall.user is empty)

When I stop the active OpenVPN instance, traffic from 192.168.1.13 successfully flows over where needed through wan.

When I then manually start the OpenVPN instance from LuCI, all traffic from all devices in lan, including the router and 192.168.1.13, starts going to the VPN.

And it is the second problem: if I need to bounce just the OpenVPN connection (it seems to resolve the main issue of the first problem :sweat_smile:), how do I make the router keep respecting the rule and route only traffic from one device into that VPN?

Any assistance would be much appreciated.

OK some progress actually.

With vpn-policy-routing and the following policies I managed to get it to work:

The only remaining problem is to route that 192.168.1.13 traffic through wan when VPN is down.

P.S.: In this set-up any traffic originating from the router itself goes over VPN when it's up and wan when VPN is down. Adding --pull-filter ignore redirect-gateway to the active OpenVPN instance file changes that so that the router traffic is sent over wan regardless.

LuCI > VPN > VPN Policy Routing > Basic Configuration > Strict enforcement > Do not enforce policies when their gateway is down

1 Like

Actually was just testing this about to reply that it worked. :+1:

I was wondering what firewall configuration was required to make it work according to

But turns out, nothing really?

Спасибо!

1 Like

Separate firewall zone is typically used to restrict forwarding to WAN when VPN is down, and it is not really necessary for VPN-PBR to work.

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.