Push route but ignore gateway
-
I have setup in which I want to route traffic for a subnet which includes the client's gateway.
Server: a.b.c.77
Gateway: a.b.c.1
Client: a.b.c.200I want to push "route a.b.c/24" but KEEP the previous routes for the gateway and server. For the server I can do this using
push "route remote_host 255.255.255.255 net_gateway"
How can I do it for the gateway?
-
If i understand you correctly you have the same subnet twice (once at your location and once at your clients location).
What exactly are you trying to accomplish?
Sure it's possible to force all traffic except the gateway into the vpn tunnel, but that's certainly not how things should work.What i would do:
- Renumber subnets
- If renumbering subnets is not possible, map a different subnet over your own and cleverly use NAT.
–> Essentially to the client your own subnet appears as if it were a different one.
-
My situation is on a university network where everyone has a publicly routable IP address. I want services behind a firewall that can only be accessed by VPN. The client and all servers, including pfSense, are on the same subnet and that can't be changed.
I'm not able to control what IPs my behind-the-firewall services get, so I wanted to route all traffic for our university's subnet through the VPN when it's connected. So I push a route rule to the client for the university subnet, and an exception for the firewall / VPN server (since it's on the university subnet). BUT the pushed route encompasses the gateway, so there is a loop:
a.b.c.77 is the VPN server
a.b.c.1 is the gateway
And push "route remote_host 255.255.255.255 net_gateway"Internet:
Destination Gateway Flags Refs Use Netif Expire
default a.b.64.1 UGSc 51 0 en0
5 link#8 UC 0 0 ham0
10.0.8.1/32 10.0.8.5 UGSc 0 0 tun0
[3] 10.0.8.5 10.0.8.6 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 5 4877 lo0
[2] a.b.64/24 10.0.8.5 UGSc 2 0 tun0
a.b.64/22 link#7 UCS 6 0 en0
[1] a.b.64.77/32 a.b.64.1 UGSc 1 0 tun0
a.b.64.118 127.0.0.1 UHS 0 0 lo0
a.b.67.159 0:30:67:4e:7d:b2 UHLWI 4 48 en0 1187
a.b.67.255 ff:ff:ff:ff:ff:ff UHLWbI 0 4 en0
169.254 link#7 UCS 0 0 en0I believe the loop is [1] -> [2] -> [3] -> Translation by OpenVPN -> [1]
-
I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.