Route a Fake subnet to Clients with same LAN subnet
-
Hi Guys,
I have this situation.
OpenVPN Server 1 - tunnel 10.10.1.0 - Client Subnet (Other Pfsense - 192.168.0.0/24)
OpenVPN Server 2 - tunnel 10.10.2.0 - Client Subnet (Other Pfsense - 192.168.0.0/24)
I cannot push the default routes to server because the both clients have the same subnet.Idea: how i can convert another subnet (ex. 10.100.0.0/24 to 192.168.0.0/24 on Client1), when i try to access 10.100.0.10 for example, the server converts this to 192.168.0.10.
And same with Client2, 10.101.0.0/24 to 192.168.0.0/24, when trying to access the address 10.101.0.15 for example, the server route the access to 192.168.0.15 on Client2.
I remember to do this with a linux server in a remote past, but really dont remember how i did this. (Obvius with routes)How i can do this in Pfsense?
regards. -
The proper way is to change one of the client subnets.
-
Hi @JKnott thanks for your reply.
If i cant change the subnet for some reason?
Is there anyway to do that on pfsense? -
Idea: how i can convert another subnet (ex. 10.100.0.0/24 to 192.168.0.0/24 on Client1), when i try to access 10.100.0.10 for example, the server converts this to 192.168.0.10.
You can do that only at the clients site. You can tell the server to route whatever to the client, but on the clients site there has to be a device listen to that IP.
So you may route 10.100.0.0/24 to client 1 and translate it on the client to 192.168.0.0/24. -
That NAT must be done on the client side, as others have stated, but since you are using OpenVPN there is a chance you can pull it off.
I have not tried this but OpenVPN also has built-in NAT:
--client-nat snat|dnat network netmask alias This pushable client option sets up a stateless one-to-one NAT rule on packet addresses (not ports), and is useful in cases where routes or ifconfig settings pushed to the client would create an IP numbering conflict. network/netmask (for example 192.168.0.0/255.255.0.0) defines the local view of a resource from the client perspective, while alias/netmask (for example 10.64.0.0/255.255.0.0) defines the remote view from the server perspective. Use snat (source NAT) for resources owned by the client and dnat (destination NAT) for remote resources.
So you could try this in the client config:
client-nat dnat 10.100.0.0/255.255.255.0 192.168.0.0/255.255.255.0
That could be pushed in a client-specific override as well.