All traffic going through VPN, even though option is off
-
Still not very good design.
What does the client have in their config... If server is not handing out that default route... Then its not possible for it to be setup by openvpn, unless the clients local config has it in there.
-
You should not enforce the ability to connect to things using routes. You should enforce it using firewall rules.
-
This is all that goes into the config file:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-disable
auth SHA256
tls-client
client
resolv-retry infinite
remote <remoteserver> 443 udp
setenv opt block-outside-dns
lport 0
auth-user-pass
ca vpn-UDP4-443-ca.crt
tls-auth vpn-UDP4-443-tls.key 1
remote-cert-tls serverIn an ideal world, everyone, everywhere would use the same local network, so that we never have this type of problem, however, I know for a fact our local ISP, some CPE has 192.168.1.0/24 as a local network, while other CPE of theirs uses 192.168.2.0/24, and some even use 192.168.10.0/24. Another regional ISP uses 10.x.y.0/24 where the second and third octets are random numbers. Whether I tell the tunnel to pass ALL RCF1918 traffic, or the 20 so subnets we have for various dev environments/ isolated services etc, the same issue with potential overlap exists where local subnet will always take precedence over the VPN.
-
My point to being a bad design.. Is your stepping on any other local networks they might need to get to because your tunnel network would take precedence over just their default route that would allow them to go to their other local networks.
Its one thing if you "happen" overlap - its another to say ALL rfc1918 come to me.
-
That's the same effect you get when you turn on the Route All IPv4 traffic option, it adds 2 routes:
0.0.0.0/1 > VPN and 128.0.0.0/1 > VPNInstead, I just want 3 routes:
10.0.0.0/8 > VPN, 172.16.0.0/12, and 192.168.0.0/16Which then force ALL traffic out as well. All I want to do is grab all RFC1918 destinations, and route them through the tunnel, not forcing public internet bound traffic through the tunnel.
-
Which is all bad design ;) I never have that option on.. Unless It was for some mobile device like a phone and some hotspot, etc. And yeah it stops them from split tunnel to any other networks that might be local to them with them having to create the routes, etc.
So your saying those routes go away when you disconnect from the vpn?
Here the thing - clearly openvpn server is NOT handing those routes out.. You can see from the connection log... Its not in the local clients config from what you shown..
So where and the F is coming from?
-
edited ;
Basically new ordered nat rules and new ordered fw rules to force the gateways for the rfc and non-tunnel clients.
On the wan adapter in the nat window config area you can then select lan aliases of the road warriors as a new nat rules via the gateway you want them to exit on.
These nat rules would precede the nat rules for the tunnel clients.Add firewall rules for road warrior subnet clients above the tunnel subnet clients,with each i.e "http rule" specifying the non-vpn gateway.
I think someone else mentioned this type of setup.
hth :)
-
If you require two nat scenarios on the same lan/wan (vpn) it doesnt work on pfsense very well without scripts
WHAT??
-
@m8ee said in All traffic going through VPN, even though option is off:
If you require two nat scenarios on the same lan/wan (vpn) it doesnt work on pfsense very well without scripts as the vpn fallback is the gateway you dont want the specified traffic to route through the bonded gateway but it will,which is what appears to be happening.
Search for NO_WAN_EGRESS and simply block the traffic you want to only go out the VPN if it tries to go out the clear WAN.
-
Yes i know ,i was talking about my own extra wan adapter,was wrong there,it does vpn and allow non vpn traffic on the same adapter,its not linux...:)
