All traffic going through VPN, even though option is off

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

Derelict

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

fiddlybytes

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