Setting up a dedicated VPN VLAN

Nope it doesn't conclude the session establishment process. You'll see the message Initialization Sequence Completed when everything works fine.
Check the .auth file that it has correct user-pass inside. Also use full path for the filename, in case it is not in the same working directory of the OpenVPN process.

2 Likes

Our posts must have overlapped trendy. I was using the incorrect syntax in the AUTH file I think

Alright, let us know how it looks when you get home.

OpenWRT works and the tun0 interface shows activity.

Now I need to alloy dynamic DNS to function i.e. remote connection AND only allow the devices I specify to go through the VPN. I'm assuming as it stands at the moment that when enabled all traffic will be using the VPN. Is that correct?

Before anything else post again the following:

ip -4 addr ; ip -4 ro ; ip -4 ru; \
ls -l  /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.*
> ls -l  /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.*
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.0.1/24 brd 192.168.0.255 scope global br-lan
       valid_lft forever preferred_lft forever
10: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet xx.xx.xx.xx/24 brd xx.xx.xx.xx scope global eth1.2
       valid_lft forever preferred_lft forever
25: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    inet xx.xx.xx.xx/26 brd xx.xx.xx.xx scope global tun0
       valid_lft forever preferred_lft forever
0.0.0.0/1 via xx.xx.xx.xx dev tun0
default via xx.xx.xx.xx dev eth1.2 proto static src xx.xx.xx.xx
xx.xx.xx.xx/24 dev eth1.2 proto kernel scope link src xx.xx.xx.xx
128.0.0.0/1 via xx.xx.xx.xx dev tun0
xx.xx.xx.xx via xx.xx.xx.xx dev eth1.2
xx.xx.xx.xx/26 dev tun0 proto kernel scope link src xx.xx.xx.xx
xx.xx.xx.xx/24 dev br-lan proto kernel scope link src xx.xx.xx.xx
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
lrwxrwxrwx    1 root     root            16 Oct 11 15:31 /etc/resolv.conf -> /tmp/resolv.conf
-rw-r--r--    1 root     root             0 Oct 16 11:20 /tmp/resolv.conf
-rw-r--r--    1 root     root           149 Oct 16 12:23 /tmp/resolv.conf.auto
==> /etc/resolv.conf <==

==> /tmp/resolv.conf <==

==> /tmp/resolv.conf.auto <==
# Interface lan
nameserver 8.8.8.8
nameserver 8.8.4.4
# Interface wan
nameserver xx.xx.xx.xx
nameserver xx.xx.xx.xx
search cable.virginmedia.net

As it stands now, all your traffic goes through the VPN tunnel. Therefore you can use the rules I posted earlier to classify traffic that should go via the regular ISP.
Regarding DynDNS, is the IP you got in trun0 interface public or private?

So could make the following change:

config rule
        option in 'lan'
        option src '192.168.0.3'
        option lookup '100'

config route
        option interface 'vpngen'
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option metric '200'
        option table '100'

Would that just route any traffic from a device that I have setup with a static ip of 192.168.0.3 through the VPN or am I missing something?

And if I invoke OpenVPN and the VPN interface how do I get round my dynamic dns issue?

And as for being public or private the ip is from a subscribed service (no-ip) so I have Dynamic DNS running to make any ip changes that may occur and I access a PC on my home LAN via a port forwarding rule

When the OpenVPN tunnel is up, all traffic goes through the tunnel by default. The rule above is correct, but pointless.
You need to change the route command to use the wan interface, rather than the vpngen, for the devices you want to use the regular internet connection.

You didn't answer me if the IP you have on VPN tunnel interface is public or private (10.x.y.z, 172.16-31.x.y, 192.168.x.y).

no-ip gives you a name that is bound to the dynamic public IP that your interface has, If you have private IP then it cannot work that simply.

I assume it is public as it currently is 82.x.y.z which will be the one set by the ISP

I have a hostname that I access remotely from which is xxxxx.noip.me and the service does the rest i.e. changes the ip when needed.

So are you saying that you have to live with all traffic going through the OpenVPN tunnel and you have to exclude devices from going through OpenVPN. I only want a couple of devices to go through the VPN and the rest (30+) normal gateway (non VPN).

Would I set up a new network range on top of my current 192.168.0.x, say 192.168.1.x and set up a rule that excludes everything in the 192.168.0.x/24 range form passing through the VPN but anything a set to a 192.168.1.x address would then go through the VPN? Is my logic right?

This is for the WAN interface and it works fine from what I understand. If your question is whether you can do the same in the OpenVPN tun interface, it depends from the IP that your tun has, private or public. Usually they give private IPs, hence there is no point for dyndns service there or no possibility of port forwarding.

No, you can manipulate that. There is an option in Luci
image
or edit directly the config file.
https://openwrt.org/docs/guide-user/services/vpn/openvpn/extra#disable_gateway_redirect

That won't be necessary in your case.

Just to note for syntax purpose I'm using 19.07 and Openwrt is configurable in luci via editing the ovpn contents within the gui. and the syntax is route-nopull (and not route_nopull). Just for reference.

So added it and OpenVPN is alive, so is the interface(no RX traffic of course) and I can still remote connect. Many many thanks for your patience trendy. It is appreciated.

And one last question. Now I am all up and running what is the syntax of the rule I would setup to say if I am a specific ip address then pass all my traffic through my VPN interface (VPNGEN)

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

Just like you have it here.

Trendy.

Thanks for all your help. Just quite get the syntax right to be able to filer only 192.168.0.x through the VPN but I will keep on trying over the coming days.

Problem is I have most the time when i am accessing it remotely and I keep on stopping my dynamic dns connection lol

I still not getting this. And it is starting to annoy, me as it must be a logical thing as Mt Spock said (or my age).

So my OpenVPN is all setup without traffic going through it I have three interfaces - LAN, WAN and VPN and three zones - lan (lan -> wan+VPNZone), wan and VPNZone. I also tried setting up a traffic rule within Luci that takes 192.168.0.3 ip address in lan and sends it to VPNZone.

What am I missing.

By the way invoking:

config rule
        option in 'lan'
        option src '192.168.0.3'
        option lookup '100'

config route
        option interface ''VPN"
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option metric '200'
        option table '100'

seems to send all traffic i.e. I lose remote connection

Try with 192.168.0.3/32

This is case sensitive, so make sure you have interface VPN and not vpn. Also use ' instead of " (although I've seen them both).

If you still have issues post here the following:
uci show network ; ip -4 addr ; ip -4 ro ; ip -4 ru ; iptables-save

1 Like

SORTED!

The following works

config rule
        option in 'lan'
        option src '192.168.0.13/32'
        option lookup '100'

config route
        option interface 'VPN'
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option metric '200'
        option table '100'

Many thanks. I have learnt a lot on the way

2 Likes

Just a little footnote (and which I suppose makes sense). I tidied all my config up including recreating the OpenVPN instance the same as the interface i.e. VPN.

This stopped the VPN working so I recreated then OpenVPN instance with another name and it was ok again.

Just posted for reference

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