Is there a place to add a deny ACL. I have a few employees that are out of the country that need all of their traffic routed through our vpn, however I need to prevent them from accessing specific internal networks. I could spin up a sperate Pritunl instance just for them to use and have the firewall control access. If there was a place to put a deny ACL then that would solve the issue I believe.
Mat
There is no option for this. There is a net gateway option in the route settings that will instruct the client to route the network through the default gateway but this is not enforced and the client will still be able to access the network by adjusting the routing table.
I was also requesting this here
Zach what is the reason behind the decision to not implement this?
There isn’t a lot of usage of 0.0.0.0/0 on most cloud providers or corporate networks due to the bandwidth costs and performance limitations with a lot of concurrent connections. The feature wouldn’t be used by many users and these security features require a significant amount of testing to verify nothing unintended happens.
I was lucky to be a part of network team in several corporate and cloud environments and having a default route which is then filtered through proxies was our typical scenario. These deny acl’s are very typical for cisco anyconnect or openconnect VPNs.
With AWS cloud env where you don’t have a transit gateway setup, you have to deal with SNAT because of non-transitive VPC peerings and this makes writing ACL’s at destination end impossible.
Given the fact that pritunl creates iptables rules to only allow access to subnets advertised to clients, what is the significant challenge to add an extra statement denying specific destination?
Code has been added that will enforce the net gateway routes. This option will be relabeled to Block Route and Net Gateway. This will block the route on the server with iptables and instruct the client to route that subnet through the clients default gateway. This will be included in the next release.
Configure a VPN (such as Pritunl) to route specific employees’ traffic through the VPN tunnel. Ensure that these employees are assigned IP addresses from a specific range. Enforce firewall rules on your network to control access based on the source IP addresses of the employees. Here you can deny access to specific internal networks. Allow traffic from the VPN IP address range to the required resources on the internal network. Add rules to deny traffic from the VPN IP range to specific internal networks that you want to restrict. Well, if the VPN doesn’t work, buy proxies and setting things up yourself will be much more reliable. The order of the rules is crucial, so make sure that the deny rules are placed before the allow rules. The exact steps for configuring firewall rules depend on the specific firewall or router you are using on your network. Common devices include Cisco ASA, pfSense, iptables, etc.
Hi @zach
I’ve just checked it on v1.32.3732.84 c5d79a
I don’t see any iptalbes rules when adding a route with Block Route and Net Gateway.
Adding a manual static route through tunnel interface allows reaching resource within subnet which was supposed to be blocked.
The option requires an enterprise subscription.
I do have enterprise subscription activated
Run sudo iptables-save find the deny ipsets ending in od for OpenVPN and wd for WireGuard. Run sudo ipset list with the names of the sets to verify the subnet is in the list.
As I already mentioned in my message above, there are no deny statements in the iptables rules:
root@xxx:~# iptables-save
# Generated by iptables-save v1.6.1 on Thu Jan 25 19:17:59 2024
*nat
:PREROUTING ACCEPT [15098:1092451]
:INPUT ACCEPT [1013:61070]
:OUTPUT ACCEPT [267:22058]
:POSTROUTING ACCEPT [267:22058]
-A POSTROUTING -s 172.16.48.0/20 -d 10.160.0.0/17 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j MASQUERADE
-A POSTROUTING -s 172.16.48.0/20 -o ens5 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j MASQUERADE
COMMIT
# Completed on Thu Jan 25 19:17:59 2024
# Generated by iptables-save v1.6.1 on Thu Jan 25 19:17:59 2024
*filter
:INPUT ACCEPT [798583:193442579]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1818603:1837786643]
-A INPUT -i tun4 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j ACCEPT
-A FORWARD -o tun4 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j ACCEPT
-A FORWARD -i tun4 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j ACCEPT
-A OUTPUT -o tun4 -m comment --comment pritunl-5fdd0ecaf338c04a337547ee -j ACCEPT
COMMIT
# Completed on Thu Jan 25 19:17:59 2024
While Block Route and Net Gateway is checked:
Having 0.0.0.0/0 in the routes overrides that option, all routing restriction is skipped when that is added.
This makes this feature useless for the very common scenario described in the first message of this topic.
Please change this behaviour, default route is not anything different from any other route to skip security features advertised by the product.
I also tried splitting default route into two so that I don’t fall into the limitation with default route you mentioned:
0.0.0.0/1
128.0.0.0/1
This doesn’t work at all - I can’t reach any of the resources behind Pritunl
netstat -rn | grep utun4
0/1 192.168.238.1 UGScg utun4
128.0/1 192.168.238.1 UGSc utun4
192.168.238 192.168.238.2 UGSc utun4
192.168.238.1 192.168.238.2 UHr utun4
Adding 0.0.0.0/0 to above mentioned routes or replacing them with a single default route make traffic traverse successfully.
I will update the tooltip in the next release to document the limitation. It’s difficult to fix because the entire route restriction code is skipped when route all is enabled. Attempting to add all traffic with 0.0.0.0/1 and 128.0.0.0/1 will break the connection. It’s rare to have 0.0.0.0/0 configured in the enterprise use cases, routing all the internet traffic will only scale to a few users per server and datacenters typically have very high bandwidth costs.
It’s rare to have 0.0.0.0/0 configured in the enterprise use cases,
I don’t know where did you get this info, this a very common case for enterprises to route all traffic through VPN
What about splitting default into four subnets?
Subnet 1: 0.0.0.0/2
Subnet 2: 64.0.0.0/2
Subnet 3: 128.0.0.0/2
Subnet 4: 192.0.0.0/2
This didn’t work as well. Weird.
Attempting to route the traffic that way will result in the public IP address of the Pritunl server being routed through the VPN and break the connection. OpenVPN will automatically route the server IP as a net gateway when the default gateway is enabled with 0.0.0.0/0. You can add that IP address to the server routes as a net gateway to replicate that option with the /1 routes.