All traffic going through VPN, even though option is off

MMapplebeck

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.

johnpoz

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

MMapplebeck

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.

johnpoz

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.

Pippin

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.

https://community.openvpn.net/openvpn/wiki/IPv6

johnpoz

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 ;)

MMapplebeck

Nothing goes into the .ovpn file on the client side, as those settings are pushed from the server once authenticated.

johnpoz

Ah - very true...

So what is getting sent.. Let see the connection log.

Pippin

Check server config...

MMapplebeck

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 service

I 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/16

The 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

johnpoz

So your routing ALL rfc1918 space through the vpn.. What is the client using for its local network?

MMapplebeck

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.

johnpoz

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.

Derelict

You should not enforce the ability to connect to things using routes. You should enforce it using firewall rules.

MMapplebeck

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 server

In 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.

johnpoz

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.

MMapplebeck

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 > VPN

Instead, I just want 3 routes:
10.0.0.0/8 > VPN, 172.16.0.0/12, and 192.168.0.0/16

Which 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.

johnpoz

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?

fiddlybytes

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 :)

johnpoz

If you require two nat scenarios on the same lan/wan (vpn) it doesnt work on pfsense very well without scripts

WHAT??