You're work and home networks are setup on the same subnet (192.168.1.0/24) You are going to need to switch one of them to another subnet otherwise the machines will never be able to route out to the machines on the other network, as they think they are local.
If you still can't talk after you switch the subnet at one location, post back here and we can work with you from there.
To clarify a little on how VPN works based on your comment.
You don't assign the VPN clients to the same subnet as you office. They need to be on a unique subnet. For my example lets assume the following:
- Home subnet is
192.168.1.0/24
- Office subnet is
10.0.0.0/24
- VPN subnet is
10.2.0.0./24
What a connection to the office would look like is this:
- Home computer: NIC1:
192.168.1.50; vNIC1-VPN: 10.2.0.50
- pfSense: PublicNIC:
1.1.1.1; PrivateNIC: 10.0.0.10; vNIC1-VPN: 10.2.0.1
- office server: NIC1:
10.0.0.100
The vNICx-VPN nics will be setup by your vpn client/server
After the user has established a VPN connection to the office, the traffic flow will look like:
The Home Computer connects to 10.0.0.100 it will:
- Look up the route in the routing table
- see a route that specifies the VPN adapter as the gateway
- The VPN Client subsystem will encapsulate the packets
- The machine will then send them over the public internet to the pfSense router.
Once the router gets a VPN encapsulated packet it:
- sends it to the VPN Daemon subsystem
- The VPN subsystem will decode the packet
- The host will look up the unencrypted destination
- The machine will then route it out the proper interface to be sent to the Server.
The response from the server will be sent to the pfSense router (since the subnet is not directly connected and the machine doesn't have any routes to that machine)
The pfSense router will:
- look up the Home computer VPN IP as that is what the server will see the packet as comming from.
- The routing table will tell it to send it through the VPN virtual adapter.
- The packet will be sent to the vpn Subsystem encapsulated, and sent over the internet to the client machine.
Once at the client machine the VPN subsystem will decrypt the packet and send it up the networking stack to the application.
Wash, rinse, repeat.
Your default route metric value is lower than the 10.22.0.0/16 route and it gets routed to the default route. In resolving routes, if more than one route matches destination, the lower metric value route takes precedence.
Either push a default route through VPN or lower metric for 10.22.0.0/16 (increase metric for default route).
It should look like this:
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.23 1000
10.22.0.0 255.255.0.0 10.22.8.1 10.22.8.10 30
10.22.8.0 255.255.255.0 On-link 10.22.8.10 286
10.22.8.10 255.255.255.255 On-link 10.22.8.10 286
10.22.8.255 255.255.255.255 On-link 10.22.8.10 286
Best Answer
I'm afraid not. If you were able to route somewhere else traffic directed to (what appears to be) your local subnet, you wouldn't be able to reach your gateway which is sitting exactly in that subnet, so routing would just cease to work.
Your only option here is to change the subnet you're using on your home network to something a little more unusual, hoping you'll never find a network which uses the same one.
Luckily, network administrators really don't have a lot of imagination when it comes to defining subnets: there are some of them which are by far the most common ones and 192.168.0.0/24 is a prime example of that (alongside with 192.168.1., 192.168.42. and various subnettings of 10.), but you can safely bet 192.168.247.0/24 will not be used on 99% of the networks you encounter (unless someone else reads this answer, of course). For some reasons, also 172.16-based subnets seem to be quite unpopular.