Limiting incoming VPN client to the single local address

pila

I need to let someone connect to my LAN, using OpenVPN and connect them to Virtual machine at 192.168.1.5:5555. They must be strictly limited to be able to access only that VM and nothing else! My VPN server is running on Asus router. My VPNserver1 should keep working as before, and be separated from the above connection completely.

Basically everything works but I want to shield my existing network and devices from whoever uses this VPNserver2.

Here is my plan.

1. Create completely new set of certificates. At my router make a VPNServer2, changing its port to e.g. 1197 and VPN Subnet to e.g. 10.37.0.0. and allow Client <-> Client Push back to 192.168.3.7.

2. The remote WinXP PC will be 192.168.3.7, CN: ASD, and will be connecting using UltraVNC, having dynamic WAN IP

3. When they connect to VPNserver2, they must be allowed only to 192.168.1.5:5555

I do not know how to do point #3. Everything else should be under control. So how to let VPNserver2 be able to route only to this single one address at my network?

It is essential that I keep Client <-> Client Push back to 192.168.3.7 so that VM can print directly to their remote printer.

I seem to find examples for opposite direction only.

pila

So, nobody here can help me with a one or two lines of linux routing from 10.37.0.x to 192.168.1.5:5555

TinCanTech

Please read this:
HOWTO: Expanding the scope of the VPN to include additional machines

pila

I am reading that and many other things and am experimenting for days. But can not solve my simple problem. I have no problem doing "Including multiple machines on the client side when using a routed VPN (dev tun)".

That works perfectly, and I want to get rid of that feature and get "Including single machine on the client side when using a routed VPN (dev tun)".

I try to avoid "Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN." I want VPN 10.37.0.x with CN client2 to communicate exclusively with a single machie on the server LAN - 192.168.1.5:5555

I do not have problem using router's Allow Client <-> Client and setting machine 192.168.1.5 on the server side to talk with the client2. But, In my Asus router, If I select Push LAN to clients -> Yes, then client2 can see all the machines in server LAN and I need to change that behaviour. let VPN Client2 see only 192.168.1.5:5555 on the server LAN.

It is not like I am not trying. Plus, I am doing it at a router so i am limited by that fact. And my lack of knowledge as I do not understand the last two paragraphs of linked title at all. And my other VPNserver1 must remain unaffected.

TiTex

if you can't set up firewall rules on the router (openvpn server) i'm not sure how could you achieve what you want.
but if you can , then create client config for client2 (see man page about client configs) which will make client2 have a "reserved" IP assigned , then limit access to client2 IP address with a firewall rule.

TinCanTech

pila wroteBasically everything works but I want to shield my existing network and devices from whoever uses this VPNserver2.

TinCanTech wrotePlease read this:
HOWTO: Expanding the scope of the VPN to include additional machines

pila wroteThat works perfectly, and I want to get rid of that feature and get "Including single machine on the client side when using a routed VPN (dev tun)".

OK.

OpenVPN does not filter, if it is configured correctly it will route everything.

You need to filter what is routed.

I can offer Four possibilities:

Only provide the client with the --route/--iroute you want.
iptables: use iptables to drop packets you don't want.
Client packet filer
All of the above

Ahh .. router .. you probably cannot use the client packet filter.

pila

I think I can add server configuration directly into the box on the GUI. I know I can add various iptables ruzles with no problems, but this is not my field of expertise. Another problem si that I have 2 servers running, and my regular server should remain unafected.

1. I did try

iptables -I FORWARD -s 10.37.0.0/24 -j DROP
iptables -I FORWARD -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5900 -j ACCEPT

but the OpenVPN server remains connectable to the router itself. If I could put VPN server at jail, that would solve it, but I do not know how. I am also not clear as why this above drop does not apply to the router (192.168.1.1) itself

2. I tried also preprouting:

iptables -t nat -I PREROUTING -i tun22 -p tcp -j DNAT --to-destination 192.168.1.5:5900

but that blocks my Server1 also.

I have some minimall skills here. Unfortunatelly, it will take some time for me to learn routing. And this I need to lend a helping hand to a local medical facility to provide temporarily a virtual machine access they need for one seldom used function of their work. For my own use, I have OpenVPN setup very well.

I am off to checking your suggestions and how to make sense of them 🙂

pila

TinCanTech wroteOpenVPN does not filter, if it is configured correctly it will route everything.

You need to filter what is routed.

I can offer Four possibilities:

Only provide the client with the --route/--iroute you want.

iptables: use iptables to drop packets you don't want.

Client packet filer

All of the above

1) I am currently reading about --route/--iroute, trying to undersntand. But, the way I understand them currently, they are general rules, and would influenece my VPNserver1 too.

2) I described in my previous mail what I tried and how it is not working well for me.

3) Client packet filter. I like obscure ideas 🙂 - I checked, but there is not $pf_file generated when a client connects. I believe I can not use that idea. Also, I need to limit access not only to 192.168.1.5, but to a single specific port on that machine. I do not want them to be able to connet e.g. to my own VM which I am using currently to write this message.

At the moment I am checking the "Configuring client-specific rules and access policies" in the above linked document, as it sounds usable, If I can understand it and make my router doing it.

pila

TiTex wroteif you can't set up firewall rules on the router (openvpn server) i'm not sure how could you achieve what you want.
but if you can , then create client config for client2 (see man page about client configs) which will make client2 have a "reserved" IP assigned , then limit access to client2 IP address with a firewall rule.

I can set firewale rules, but I am missing something or am doing it wrong. As for Client config, for now I am not sure I can do it at my Asus router.

TinCanTech

pila wrote1. I did try

iptables -I FORWARD -s 10.37.0.0/24 -j DROP
iptables -I FORWARD -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5900 -j ACCEPT

This looks like the rules should be reversed ..
(1) Allow that specific IP:Port
(2) Drop everything else

TiTex

10.37.0.0/24 is the subnet allocated to VPN clients conneting to VPNServer2 ?
If that's the case you could do something like this for a firewall rule

iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 -j DROP

which translates to drop the connection if the source is 10.37.0.0/24 and the destination is not 192.168.1.5 and add it as the first rule in the FORWARD chain, i have not specified the port ... it's better to take small steps in solving an issue

pila

TinCanTech wrote

pila wrote1. I did try

iptables -I FORWARD -s 10.37.0.0/24 -j DROP
iptables -I FORWARD -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5900 -j ACCEPT

This looks like the rules should be reversed ..
(1) Allow that specific IP:Port
(2) Drop everything else

I am applying rules throught a script that is run on a router startup. Order of things in that script seems important, as you said. I do not know how is this normally working, but on my router, when I list existing rules, they are listed in the oposite order from my rules defining script. So, my first drop rule ends up as a last line in that segment.

pila

TiTex wrote10.37.0.0/24 is the subnet allocated to VPN clients conneting to VPNServer2 ?
If that's the case you could do something like this for a firewall rule
iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 -j DROP
which translates to drop the connection if the source is 10.37.0.0/24 and the destination is not 192.168.1.5 and add it as the first rule in the FORWARD chain, i have not specified the port ... it's better to take small steps in solving an issue

Your initial statement is true. I have now finalised that VM at port 5902. My problem is that I do not know what am I doing, so adding ports is a problem 🙁 I will learn iptables in detail as my next task but that can not be a quick job.

So, to replace my two rules which seem to work acceptably toward my VM server (only the router where the VPN2server is actually located can be accessed from VPN but that is not an issue)

iptables -I FORWARD -s 10.37.0.0/24 -j DROP
iptables -I FORWARD -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5902 -j ACCEPT

Help shows negations are acceptable. If I enter, this is accepted by my router:

iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 -j DROP

But, when I try adding the port which is crucial (as I am using port 5900 for my own VM as the PC):

iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5:5902 -j DROP

it is wrong and the router complains:

iptables v1.4.14: host/network `192.168.1.5:5902' not found

Or should it be like:

iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 ! -p tcp --dport 5902 -j DROP

Should that line be correct? Help on my router does not even mention --dport arg but it looks I can not use it without -p prior to it. When I run this last rule, I get response:

# iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 ! -p tcp --dport 5902 -j DROP
iptables: Invalid argument. Run `dmesg' for more information.
# dmesg | tail -n1
x_tables: ip_tables: tcp match: only valid for protocol 6

Just curious: Is it better if I use -i tun22 instead of -s 10.37.0.0/24 or is that not relevant? Both are the same VPNserver2. Shorter is better and more readable. So, if I can improve and learn, I am all for it 🙂

Problem is I can not fully test setup at my convenience but theirs.

TiTex

when it comes to firewalls i would say , the more specific the better , but it also adds complexity to the matter.
iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5:5902 -j DROP - this is not the right syntax

try this , however i'm not sure if it will work ...this inverse policy is tricky 🙂)
but the syntax is right

iptables -I FORWARD 1 -s 10.37.0.0/24 ! -d 192.168.1.5 -p tcp ! --dport 5902 -j DROP

TiTex

(can't edit previous message)
probably this is simpler to understand and most likely to work

iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5902 -j ACCEPT
iptables -I FORWARD 3  -j DROP

pila

TiTex wrote(can't edit previous message)
probably this is simpler to understand and most likely to work

iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -s 10.37.0.0/24 -d 192.168.1.5 -p tcp --dport 5902 -j ACCEPT
iptables -I FORWARD 3  -j DROP

Wow! Yo have just reset my simple knowledge to zero 🙂 I will have to try this out and understand what is it and how is it doing. Great opportunity to learn! Thanks.

As to negation, it is not crucal, but would make rules shoriter if I manage to get it right (on my router).

pila

I have some extra rules involved from before, I will have to work them in.