Push route but ignore gateway

[cyounkins]

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

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

[GruensFroeschli]

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.

[cyounkins]

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    en0

I believe the loop is [1] -> [2] -> [3] -> Translation by OpenVPN -> [1]

[cyounkins]

I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.