OpenVPN is using default gateway and ignoring options.
-
I tested this before Wednesday's snapshot and it was working. I shouldn't have been update happy but I am.
Previously in my OpenVPN client, I have the options
route-nopull;
route 10.1.1.0 vpn_gateway;This is to redirect that subnet through the vpn and leave the rest of my network on the default gateway. It was working great but now, in the syslog - OpenVPN, one of the lines shows "route-gateway x.x.x.x" where x.x.x.x is my default gateway so it's ignoring my options. Anyone have a fix?
-
That wouldn't have changed by upgrading. Something else made it work before rebooting. That's not right in general. Remove the "route 10.1.1.0 …" and fill in "10.1.1.0/24" in the "remote network" field.
-
I found the problem. That route 10.1.1.0, is a subnet for a vlan on my network.
When I have squid 2.7 on transparent proxy for that vlan interface, the route options for openvpn don't work. As soon as I remove transparent proxy for that interface, everything goes back to normal.
Now my only problem is how to I get squid to work with vpn.
Edit: I set the transparent proxy to my VPN interface, not my vlan interface and now everything works!
Thanks cmb! Your post really got this going!
-
I'd still recommend changing the route as I described, as if that works, it's only by coincidence. Put it in the "remote network" and our code makes sure it's handled correctly on the back end now and in the future.
The difference between Squid and direct is probably only the source IP. Squid makes the requests out, and initiating traffic from the firewall itself makes the source IP the interface IP that's closest (by the routing table) from the destination, which is the tun interface IP rather than an IP on your LAN subnet. The remote end blocking that IP (or not having proper routing for it or something) but allowing your LAN subnet is the most likely cause.
-
@cmb:
I'd still recommend changing the route as I described, as if that works, it's only by coincidence. Put it in the "remote network" and our code makes sure it's handled correctly on the back end now and in the future.
The difference between Squid and direct is probably only the source IP. Squid makes the requests out, and initiating traffic from the firewall itself makes the source IP the interface IP that's closest (by the routing table) from the destination, which is the tun interface IP rather than an IP on your LAN subnet. The remote end blocking that IP (or not having proper routing for it or something) but allowing your LAN subnet is the most likely cause.
I made the change you suggested by using remote network. In addition, I am using the redirect-gateway def1 flag in the advanced section of the openvpn client. Here are the results:
When I have squid set for transparent proxy, the entire network is routed through the VPN.
If I leave out the redirect-gateway def1 flag, then the entire network is routed out the WAN.
I didn't fully understand what you wrote. I'm still new at this. So you are saying the remote end is blocking the LAN subnet IP? How do I fix this?
-
Oh, I misunderstood what you were saying about that 10.1.1.0/24, you don't want that specified anywhere in the OpenVPN config since that's a local network. I thought that was the network you were wanting to reach via the VPN.
What do you want to route over the VPN?
-
@cmb:
Oh, I misunderstood what you were saying about that 10.1.1.0/24, you don't want that specified anywhere in the OpenVPN config since that's a local network. I thought that was the network you were wanting to reach via the VPN.
What do you want to route over the VPN?
Yes 10.1.1.0/28 is a local vlan I created.
My goal:
I'm trying to split my network into different vlans and route the vlan subnet 10.1.1.0/28 over the StrongVPN and leave 192.168.1.1/28 default vlan, my LAN, off the VPN and put both on squid.
Without squid installed at all, here are more details:
In the OpenVPN config,
1. If I put 10.1.1.0/28 into the remote tunnel section and no 'redirect-gateway def1' and no 'route 10.1.1.0 255.255.255.240 vpn_gateway, then the default ISP gateway is used on the 10.1.1.0 vlan.
2. If I put 10.1.1.0/28 into the remote tunnel section and 'redirect-gateway def1' in the advanced section, the 10.1.1.0 vlan is getting pushed through the VPN. However, I can't access my default ISP WAN with the 192.168.1.0 network.
3. Regardless of if I put or leave out 10.1.1.0/28 into the remote tunnel section but put route 10.1.1.0 255.255.255.240 vpn_gateway in the advanced section, then the 10.1.1.0 vlan is getting pushed through the VPN and the 192.168.1.0 can access the WAN.
TL;DR option 3 is the only one that routes everything correctly as per my original post. However, this is without considering squid.
Once I install squid (I select vlan3 and LAN interface and check transparent proxy) and here are the results:
With 1, all traffic goes through the WAN gateway, VPN not routing anything.
With 2, all traffic goes through the VPN gateway, no selective routing.
With 3, I get an http invalid request on every device on my network (10.1.1.0 and 192.168.1.0) when I first install squid. If I reinstall squid, something resets and the internet is accessible once again but everything goes through the WAN gateway, VPN not routing anything.
TL;DR everything breaks with OpenVPN and squid and I'm not sure how to fix it.
-
Never put any local networks in your OpenVPN config like that, routes are for destination networks to be reached via that path, not source networks. You'll want to assign your OpenVPN interface and configure policy routing accordingly to send traffic sourced from those IPs out the VPN. You can more or less follow the interface and rules part of this.
https://forum.pfsense.org/index.php?topic=29944.0