Using OpenVPN & Socks Proxy

Installing and Using OpenWrt
1

I would like to chain openVPN with a socks proxy, all on the OpenWrt device (which has a LAN and WAN port).

I.e.: RJ45 LAN port -> redirect to locally running openVPN -> openVPN uses locally running socks proxy -> socks Proxy accesses Internet via RJ45 WAN port.

This means: all traffic from the LAN interface should go to the tun interface of openVPN .. except for ssh to the OpenWrt box's IP, since of course I still need to access that from LAN.
No routing between LAN and WAN, all LAN traffic should go through the VPN.
And of course I need to make sure the OpenVPN routes don't mess up the outgoing requests of the socks proxy. Also the OpenWRT box will run an NTP, this one also should access the internet directly.
So: processes running on OpenWRT -> direct connection to WAN.
External requests via LAN -> OpenVPN tunnel.

How do I approach this best?

I found a very basic example here
https://openwrt.org/docs/guide-user/services/vpn/openvpn/client
but of course there are no explanations, so it's a bit difficult to extend.

(I've worked with ipfwadm, ipchains, iptables in the past, but have a bit of a hard time adapting to the OpenWRT way.)

Any help, suggestions, pointers are welcome.

2

What about setting up 2 separate subnets with distinct access spec?
https://openwrt.org/docs/guide-user/network/wifi/guestwifi/start

3

Connection should be via LAN, not via WiFi.

4

replace wifi with physical port in the guides.

The traffic originating from router (like socks proxy) as opposed to forwarded from LAN can be controlled with PBR package.

5

The pointer to pbr was helpful. But there are still some unclear details.

My plan and understanding so far is: following https://openwrt.org/docs/guide-user/network/routing/pbr_app, I would set up pbr and VPN:

opkg update
opkg install pbr 
# Enable PBR
uci set pbr.config.enabled="1"
uci commit pbr
service pbr restart
# Support unmanaged protocols like OpenVPN. 
uci add_list pbr.config.supported_interface="tun*"
uci commit pbr
service pbr restart
# Disable gateway redirection in the VPN client configuration
# To unset an OpenVPN tunnel as default route, set the following to the appropriate section of your /etc/config/openvpn:
#      list pull_filter 'ignore "redirect-gateway"'
# Also add the socks pointer to the VPN config in /etc/config/openvpn:
#      add "socks-proxy 127.0.0.1 6876"

Then I would need to add a routing rule from LAN to VPN tun interface:

# Route LAN 192.168.1.0/24 to VPN. 
uci add pbr policy
uci set pbr.@policy[-1].src_addr="192.168.1.0/24"
uci set pbr.@policy[-1].interface="vpn"	# destination for route?
uci commit pbr
service pbr restart

So far all fine and logical?
Socks proxy still should be able to talk to the internet via WAN,
VPN talks to socks proxy via localhost,
LAN is forwarded to VPN.

Open questions:

How to ensure ssh into the OpenWrt box still works?

I found several potential ways, but I don't understand yet which ones to use single/in combination etc:

One way could be to modify the PBR route policy from above, to include something like dst_addr="!192.168.1.0/32", but I did not find any mentioning of logical (boolean) invert operators in the docu.
Another way could be to add an extra RBR policy before the LAN to tun PBR policy. Something like this.

uci add pbr policy
uci set pbr.@policy[-1].dst_addr="192.168.1.1"
uci set pbr.@policy[-1].dst_port="22"
uci set pbr.@policy[-1].proto="tcp"
uci set pbr.@policy[-1].interface="lan"	# source? destination? 
uci reorder pbr.@policy[-1]="1"
uci commit pbr
service pbr restart

But as you see from the comment, it's unclear to me what I should choose as the destination, when it should be "no routing, keep on this host".

Do I need any additonal firewall rules?
It seems forwarding can also be done using the firewall rule set.
My understanding is, when solving the issue by using PBR, I do not need additional firewall rules to support that (as long as the FW does not block anything by default, i.e. is left as is in original fw image).
Otherwise I'd be included to add something like this in /etc/config/firewall:

config rule
	option name 'Allow-ssh-Inbound'
	option target 'ACCEPT'
	option src '192.168.1.0/24'
	option src '192.168.1.1/32'
	option proto 'tcp'
	option dest_port '22'

But this only tells the FW to accept ssh connections to openWRT, not how to route these... right?

What happens if the tun device is not up at system boot time?
This only will come up after OpenVPN has established the tunnel. Will the routing then start automatically, or will PBN give up on the tun interface if it is not there at boot time? Will I need to add some kind of if-up scrips?

6

Just run tests between steps you do to confirm that what is ought to be blocked does not pass and vice versa.

7

I would like to avoid the try-and-error-method, as I would like to understand what is going on and how things actually work. (This also helps with future issues that might come up, I don't want to bother you guys for every single command I need to type into the console.)

So if anyone could shed some light here on my blind spots or misunderstandings, that'd be awesome. :sweat_smile:

8

I fail to understand anachronism called Socks.

9

What if you set up wireguard nat-ing your internet connection from inside openvpn buble, or from anywhere in the world?

10

Socks can be quite useful, and sometimes it can even be the only (practical) way to go.

Concerning the "What if you set up wireguard nat-ing your internet connection from inside openvpn buble, or from anywhere in the world?" ... do you mean "this won't work for that use case, for example", or is this a suggested way to solve my problem?
So far I have no plans of chaining Wireguard and OpenVPN.

(btw, no need to try-and-error right know, because I know it won't work at the moment, as there are still routes missing. It's just that I don't know how to properly set these routings.)

11

You divert LAN to OpenVPN, then add wireguard server on your router that permits you to make next "guest" network that has your internet.

12

Sorry, I don't get it.
By "divert" you mean "set a default route", right? So far all clear.
I don't need a wireguard server. Or was this your suggestion to (kind of ab-)use Wireguard to be able to establish an ssh connection from LAN to OpenWRT?

1 Like
13

Wireguard to access free internet via your router.

14

I think there's a misunderstanding between us. I don't need free (?) (do you mean: a direct route to the internet, without the VPN?) access to the internet from outside the OpenWRT box.
The plan is to route everything from the LAN port to the OpenVPN tunnel device, except for ssh connections to 192.168.1.1 (the OpenWRT device). OpenVPN in turn accesses the socks port. All other connections originating on OpenWRT (such as NTP running there) should go to WAN port directly.

15

192.168.1.1 will be always accessible unless you block it.
I doubt there is configuration ready made for openvpn to go via proxy

16

There is the OpenVPN config setting 'socks-proxy', as described here
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/