Skip to content
I tried
Address translation possible?
Got a problem with Viscosity or need help? Ask here!
-
DominikHoffmann
- Posts: 14
- Joined: Wed May 30, 2018 3:49 pm
Post
by DominikHoffmann » Tue Jun 25, 2024 12:08 pm
My router, a pfSense system, runs a tap OpenVPN server. The OpenVPN server is at 192.168.1.1. Once I am connected to it via Viscosity, I can contact the pfSense system at 192.168.1.1.
I am currently connected to a different Wi-Fi system, which itself has is a 192.168.1.0/24 network. I cannot connect to any of the hosts on my pfSense’s 192.168.1.0/24.
Is there a way to configure the connection in Viscosity, so that the remote network is made available to the system running Viscosity as, let’s say 192.168.2.0/24?
I am currently connected to a different Wi-Fi system, which itself has is a 192.168.1.0/24 network. I cannot connect to any of the hosts on my pfSense’s 192.168.1.0/24.
Is there a way to configure the connection in Viscosity, so that the remote network is made available to the system running Viscosity as, let’s say 192.168.2.0/24?
-
James
- Posts: 2376
- Joined: Thu Sep 04, 2008 9:27 pm
Post
by James » Tue Jun 25, 2024 10:40 pm
Hi DominikHoffmann,
OpenVPN supports "client side NAT" remapping, however this is only for TUN/routed networks, it won't work for TAP/bridged:
https://www.sparklabs.com/support/kb/ar ... client-nat
Your best bet is to use more explicit routes so that they override the local range. If you just need to access a handful of IP addresses then I recommend adding each IP address as a route to the VPN connection (make sure the mask is 32 or 255.255.255.255):
https://www.sparklabs.com/support/kb/ar ... connection
If you need to access a much larger part of the subnet, you could set the routes 192.168.1.0/25 and 192.168.1.128/25 instead (which will cover the full 192.168.1.0/24 range), however you may also need to add an exception for your local router/gateway to avoid breaking the VPN connection:
https://www.sparklabs.com/support/kb/ar ... al-network
Cheers,
James
OpenVPN supports "client side NAT" remapping, however this is only for TUN/routed networks, it won't work for TAP/bridged:
https://www.sparklabs.com/support/kb/ar ... client-nat
Your best bet is to use more explicit routes so that they override the local range. If you just need to access a handful of IP addresses then I recommend adding each IP address as a route to the VPN connection (make sure the mask is 32 or 255.255.255.255):
https://www.sparklabs.com/support/kb/ar ... connection
If you need to access a much larger part of the subnet, you could set the routes 192.168.1.0/25 and 192.168.1.128/25 instead (which will cover the full 192.168.1.0/24 range), however you may also need to add an exception for your local router/gateway to avoid breaking the VPN connection:
https://www.sparklabs.com/support/kb/ar ... al-network
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
-
DominikHoffmann
- Posts: 14
- Joined: Wed May 30, 2018 3:49 pm
Post
by DominikHoffmann » Thu Jun 27, 2024 1:58 am
Tue Jun 25, 2024 10:40 pmJames wrote: OpenVPN supports "client side NAT" remapping, however this is only for TUN/routed networks, it won't work for TAP/bridged:Thanks very much, James!
https://www.sparklabs.com/support/kb/ar ... client-nat
I tried
Code: Select all
and got this in my Viscosity log file:client-nat snat 192.168.101.0/255.255.255.0
Code: Select all
I was hoping that that command would remap the entire remote 192.168.1.0/24 network to a 192.168.101.0/24 network accessible through my tun connection. Does my server not support that command?2024-06-26 11:53:33: Viscosity Mac 1.11.2 (1691)
2024-06-26 11:53:33: Viscosity OpenVPN Engine Started
2024-06-26 11:53:33: Running on macOS 14.5
2024-06-26 11:53:33: ---------
2024-06-26 11:53:33: State changed to Connecting
2024-06-26 11:53:33: Checking reachability status of connection...
2024-06-26 11:53:33: Connection is reachable. Starting connection attempt.
2024-06-26 11:53:33: Options error: The command "client-nat" or one of its parameters is invalid for this version of OpenVPN (2.6.10). Please edit the connection, make sure the command is valid, and try again.
2024-06-26 11:53:33: Full command: client-nat snat 192.168.101.0/255.255.255.0
2024-06-26 11:53:34: The OpenVPN subsystem could not be started.
2024-06-26 11:53:34: State changed to Disconnected (OpenVPN System Failure)
-
James
- Posts: 2376
- Joined: Thu Sep 04, 2008 9:27 pm
Post
by James » Wed Jul 10, 2024 1:12 pm
Interesting, it appears OpenVPN's documentation for "client-nat" is wrong. It looks like the format was changed at one point, and the documentation was never updated. Looking at the source code instead, the correct format for the "client-nat" command is:
James
Code: Select all
So using the same IP ranges listed in the documentation example, you'd instead need something like the following (adjust to use the appropriate type and IP ranges for your setup):client-nat type network netmask foreign_network
Code: Select all
Cheers,client-nat snat 192.168.0.0 255.255.0.0 10.64.0.0
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
4 posts
Page 1 of 1