Configuring iptables for VPN to pentesting labs

User Support General
1

Hello, first time poster here.

My situation is that I am a pentesting student, and I have a Kali app qube (from unman: Index of /Templates_4.1).

I connect via VPN to various lab environments full of lab machines to learn pentesting. Either my own homelab, or places like HackTheBox, TryHackMe, etc.

I experience the common problem where, because of how networking works in Qubes, I do not have the network connectivity I would like between my Kali VM and machines in the lab environment on the VPN. I would like my Kali VM to be able to receive incoming connections from other machines on the VPN/in the lab, for example if I am running a netcat listener trying to catch a reverse shell.

At first I was using a ProxyVM (based on debian-11-minimal with openvpn installed):

sys-net → sys-firewall → ProxyVM (with openvpn) → Kali VM

And that was working for most things, except for incoming connections to my Kali VM from machines on the VPN network (like a reverse shell). Tinkering with the iptables was beyond my ability. The default iptables that appear in my Kali VM, and in my ProxyVM are as follows:

$ sudo iptables -L            
Chain INPUT (policy DROP)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere             state INVALID
DROP       udp  --  anywhere             anywhere             udp dpt:bootpc
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
QBS-FORWARD  all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain QBS-FORWARD (1 references)
target     prot opt source               destination

Just to troubleshoot, I tried tinkering with iptables in both my ProxyVM and Kali VM and got nowhere.

Instead I now have openvpn running directly in my Kali VM:

sys-net → sys-firewall → Kali VM (with openvpn running)

and I crudely wiped the iptables in the Kali VM:

iptables -F
iptables -P INPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P INPUT ACCEPT

Success. That works. But it feels far from ideal.

My ideal would be to use a ProxyVM handling the openvpn connection to whatever lab i’m working in, and I would have some easy way of configuring my iptables/Qubes networking such that the Kali VM is more exposed only to the VPN network as would be appropriate for pentesting - it should receive incoming connections, respond to pings, etc, basically like i am using a regular Kali installation connected to the VPN. This could be persistent and/or general, but I also wouldn’t mind writing a simple bash script to modify iptables on startup, or to open up specific ports on my Kali VM when I need it - however, my knowledge of iptables is really not sufficient to figure this out on my own.

Notably, the VPN set up is such connections from the Kali VM going to IPs outside of the lab network are routed to the regular internet. So I’m also not looking for a solution where there Kali VM is “wide open” on the VPN and completely locked down otherwise.

I am aware of some of the dom0 script out there to automatically forward a port to a specific VM. I don’t think they are applicable in my situation, since they don’t account for a ProxyVM, or that I’m dealing with a VPN network specifically/only where I want to open up ports.

My current solution works, but I think I would greatly benefit from some advice on setting up the iptables in my Kali VM at least, or possibly a way to make it work with a ProxyVM. Searching the forums (and elsewhere) I do know that this is an issue pentesting students come up against regularly, but I havn’t seen a good solution and I think a good solution would benefit people besides me! Also if the best solution is to just tell me to learn iptables, feel free although I would appreciate some guidance/advice/starting points too!

Thanks for reading and any help you have.

1 Like
2

Welcome.
iptables rules in qubes always give me a headache, with that weird DNS and DHCP setup and considering there’s also nftables and you don’t know which takes priority… so you end up duplicating your efforts in both iptables and nftables just to be sure…
After some searching found some clarification about the whole iptables-nftables business

Still doesn’t answer what happens when you set contradictory rules using both commands.
Also even after trying reading docs multiple times still can’t wrap my head around that PR-QBS DNS propagation business. In general my confusion stems from DHCP server sitting somewhere (as I understand it) in the back of qubes infrastructure and communicating with vms in mysterious (to me) ways (qrexec?), and the whole DNS business communication being facilitated by interacting with something in the back of qubes using qubes specific mechanisms but wrapping them in the standard network protocol clothes, ergo the whole PR-QBS chain in the table…

anyway… for what you want you would need to route from your vpn vm tun interface to your kali
you could try instructions here in the section Port forwarding to a qube from the outside world

for openvpn setup I recommend using qubes-tunnel

3

I have learned a little bit more about iptables. For example, with a setup like this:

sys-net → sys-firewall → Kali VM (running openvpn to a lab network)

I can add an iptable rule like this:

iptables -I INPUT 1 -j ACCEPT -i tun0

To allow in traffic coming from the VPN (on the tun0 interface). Great! I would still take suggestions on how to tune the iptables in a Kali VM here.

I’m still at a loss getting it to work with a ProxyVM handling the VPN, as in:

sys-net → sys-firewall → ProxyVM (running openvpn to a lab network) → Kali VM

In this case, i’ve tried troubleshooting by flushing all iptables, and setting all chains to ACCEPT in the ProxyVM and KaliVM, still without success. I suspect it may not be a firewall issue then, but something about the routing in the ProxyVM i have to modify… but I’m at a loss here.

Thanks for this suggestion, I had looked at that, but it does not seem applicable here. As I understand it, in my situation, I shouldn’t actually need to muck around in sys-net nor sys-firewall, because the traffic I’m concerned with is going through a VPN. It’s all inside the VPN “tunnel” as it passes through sys-net and sys-firewall, so firewall rules or routing there have no effect. And besides, it is working fine without a ProxyVM.

Thanks for this as well, but also not helpful i believe. I did try the project on which it is based, and those projects seek to lock down the VPN connection to avoid leaks - in my case this is actually undesirable.

4

In the settings on the ProxyVM you can set it as “provinding network”, if you do that you can in the KaliVM set ProxyVM as the netvm, than KaliVM with use ProxyVM as the gateway.

5

@renehoj
sorry, perhaps I wasn’t clear enough in my posts. I know how to set up a ProxyVM. my question is about getting that arrangement to allow the type of incoming connections to my Kali VM necessary to pentesting lab work. it requires modifying firewall rules, which is really what I’m looking for advice on!

6

Look at the documentation
BUT, as you are using VPN you will need to handle inbound traffic at the
VPN level so that it is directed down the tunnel to your sys-net, and
then down to the proxy. You may not be able to do this.

1 Like