All traffic going through VPN, even though option is off
-
I have an odd issue, that is affecting 2 sites.
First off, I have 2 groups of users in our company, 1 group needs access to our full network when connecting in via VPN, while the other only needs access to 2 subnets in one of our data centers.
The first group connects in through dual XG-7100 units in HA to our main office site. 500Mbps symmetrical with dual stack.
The second group also connects in through dual XG-7100 units in HA, hosted within one of our data centers. 100Mbps symmetrical with dual stack as well.
Both OpenVPN connections authenticate through our AD via LDAP.
The first group is configured for IPv4 to have access to all RFC1918 networks through the connection, and on IPv6 the option to route all traffic via the tunnel is on(might as well give road warriors IPv6 access out to the internet), the second group is the same, except they only have 2 subnets assigned to them.
The issue that I am having that is on IPv4, all traffic is still trying to go out through the tunnel. I happened upon this when a user complained that they couldn't access the internet when connected to the tunnel(I had no outbound NAT set for the OpenVPN network, as I shouldn't need it), this issue is happening on both sites.
Anyone have any thoughts on this?
- Marc
-
unless you checked the default gateway option in your vpn setup.. They would not go down the tunnels unless trying to go to the networks you setup in your vpn configuration.
-
Yes, that would be the expected behavior, however, it is not doing that. I am wondering if it's an issue where I have the box checked to do that for IPv6.
-
I am not aware of being able to configure those differently... If your client config has the option
redirect-gateway def1
I don't think its possible to say do that only for IPv6 and not IPv4
-
This is the tunnel settings, there are separate options for IPv4 redirect and IPv6. They are running OpenVPN client 2.4.7-lx03 which is the latest package available.
-
I am not saying that is not inter there with the gui, but I don't think its possible to distingush in openvpn option... And that could be misleading in the gui.
Better option would be to just push the IPv6 route 2000::/3
Is that what option sets in the gui? Let me set it an do an export and look at the config.
-
If it helps, from the manual:
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage--redirect-gateway flags...
ipv6 -- Redirect IPv6 routing into the tunnel. This works similar to the def1 flag, that is, more specific IPv6 routes are added (2000::/4, 3000::/4), covering the whole IPv6 unicast space.!ipv4 -- Do not redirect IPv4 traffic - typically used in the flag pair ipv6 !ipv4 to redirect IPv6-only.
-
Great info... So what is getting set in your config.. I tried clicking redirect IPv6, but nothing in the ovpn file when exported at all... This might have to do with no IPv6 actually setup ;)
Will have to resetup IPv6 on my openvpn... I never redid that after moving from vm pfsense to physical pfsense.. Didn't really ever have need of it.. If I need to do something with ipv6, I just rdp to box that has IPv6 on my home network and do it from there through ipv4 vpn connection ;)
-
Nothing goes into the .ovpn file on the client side, as those settings are pushed from the server once authenticated.
-
Ah - very true...
So what is getting sent.. Let see the connection log.
-
Check server config...
-
No actual IPv4 routes show in the status box, only the IPv6.....
Wed Apr 24 16:02:37 2019 open_tun
Wed Apr 24 16:02:37 2019 TAP-WIN32 device [Ethernet 2] opened: \.\Global{8F877A91-3C70-4377-B164-6DF91F045CEE}.tap
Wed Apr 24 16:02:37 2019 Set TAP-Windows TUN subnet mode network/local/netmask = 10.255.216.0/10.255.216.4/255.255.255.0 [SUCCEEDED]
Wed Apr 24 16:02:37 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.255.216.4/255.255.255.0 on interface {8F877A91-3C70-4377-B164-6DF91F045CEE} [DHCP-serv: 10.255.216.254, lease-time: 31536000]
Wed Apr 24 16:02:37 2019 Successful ARP Flush on interface [12] {8F877A91-3C70-4377-B164-6DF91F045CEE}
Wed Apr 24 16:02:37 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Wed Apr 24 16:02:38 2019 IPv6 dns servers set using service
Wed Apr 24 16:02:38 2019 add_route_ipv6(2001:4c0:3300:ff::/64 -> 2001:4c0:3300:ff::1002 metric 0) dev Ethernet 2
Wed Apr 24 16:02:38 2019 Blocking outside dns using service succeeded.
Wed Apr 24 16:02:43 2019 add_route_ipv6(::/3 -> 2001:4c0:3300:ff::1 metric -1) dev Ethernet 2
Wed Apr 24 16:02:43 2019 add_route_ipv6(2000::/4 -> 2001:4c0:3300:ff::1 metric -1) dev Ethernet 2
Wed Apr 24 16:02:43 2019 add_route_ipv6(3000::/4 -> 2001:4c0:3300:ff::1 metric -1) dev Ethernet 2
Wed Apr 24 16:02:43 2019 add_route_ipv6(fc00::/7 -> 2001:4c0:3300:ff::1 metric -1) dev Ethernet 2
Wed Apr 24 16:02:43 2019 Initialization Sequence Completed
Wed Apr 24 16:02:43 2019 Register_dns request sent to the serviceI ran a route print, and have the following routes created through the tunnel.
0.0.0.0 128.0.0.0 10.255.216.1 10.255.216.4 259 <--- should not be there 0.0.0.0/1 10.0.0.0 255.0.0.0 10.255.216.1 10.255.216.4 259 <--- assigned by tunnel properly to 10.0.0.0/8 128.0.0.0 128.0.0.0 10.255.216.1 10.255.216.4 259 <--- should not be there 128.0.0.0/1 172.16.0.0 255.240.0.0 10.255.216.1 10.255.216.4 259 <--- assigned by tunnel properly to 172.16.0.0/12 192.168.0.0 255.255.0.0 10.255.216.1 10.255.216.4 259 <--- assigned by tunnel properly to 192.168.0.0/16The 3 IPv4 routes that I defined on the server config are there, but it's also showing the 2 routes that are put there is the Redirect all IPv4 option is selected. I may try turning off the IPv6 redirect option, and just enter the routes manually.
- Marc
-
So your routing ALL rfc1918 space through the vpn.. What is the client using for its local network?
-
I see where you're going, but that won't matter because my local subnet(even though it falls within RFC1918) is still listed as on-link in the routing table, so traffic will not go through the tunnel.
I had to double check though, I just tried a traceroute to my internal gateway, while connected to the tunnel, and it was just a single hop.
-
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...:)
