@Martek said in NAT from internet host through WAN to VPN connected host on specific tcp port:

My posibility is to use "Client Specific Overrides" to adjust that end of the VPN tunnel.

Yeah, the CSO is needed on the server to route the traffic to the proper client. But it doesn't do anything on the client side.

However using "Client Specific Overrides" with "Redirect Gateway: Force all client generated traffic through the tunnel" to be set, doesn't change the result.

I'd expect, that it would work with this option, presumed the route on the client is really added.
This would route any upstream traffic from the client over the VPN, however, but not only responses on the forwarded requests. Is this, what you want?

If so the outbound NAT rule on WAN for LAN2, you mentioned above, is needed to get internet access.

For testing the routing, on pfSense try to ping the host in LAN2 from the LAN1 IP. Ensure that the firewall of the host itself doesn't block access from outside.
Also check if the upstream traffic is routed over the VPN by accessing whatismyipaddress.com or something else showing you source IP.

@pfsblah said in Can connect to OVPN Server and that's about it:

I can't give thumbs up

Gave you one 👍

It sounds like your VPN is successfully connecting, but it’s only routing traffic for internal access—not tunneling all internet traffic through the VPN server. To make sure all traffic, including public browsing, uses the VPN’s location/IP, you need to enable full tunnel routing.

Here’s what you should check and configure:

Server Configuration (server.conf or openvpn.conf)
Add this line:

push "redirect-gateway def1 bypass-dhcp"

This tells the client to route all internet traffic through the VPN.

Enable IP Forwarding on the VPN Server
On Linux:

echo 1 > /proc/sys/net/ipv4/ip_forward

Or permanently in /etc/sysctl.conf:

net.ipv4.ip_forward = 1

Configure NAT on the Server (iptables example)

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Replace 10.8.0.0/24 with your VPN subnet and eth0 with your actual network interface.

Client Configuration
Make sure the client doesn’t override the redirect:

Remove any pull-filter ignore "redirect-gateway" line

Allow the server-pushed route

If you're planning to serve multiple clients or rotate egress IPs, consider integrating proxy rotation on the VPN server side. This can be done with tools like a rotating outbound proxy pool or IPtables-based policy routing, especially useful for web scraping, testing, or anonymization scenarios.

The CSC seems to work when assigning a specific tunnel IP to the client.

But it seems not to work for setting (all) the routes, and for limiting the access:

The wish would be to set only one IP for the client to be routed etc

I solved it for now by adding fw-rules on the OpenVPN-interface on the server side:

allow traffic from tunnel-IP x.y to server-VM a.b.c reject traffic from tunnel-subnet to rest of server-LAN

Seems to work right now, suggestions welcome ;-)

@JKnott
Yes your are right
I am on vacation and it is not possible to change the local network.
Changing my local network I will do it (but when I will be back at home)

So I was trying to find a temporary bypass :-)

@viragomann
Thanks for help
yes I set :

DNS Default Domain "check valid" Provide a default domain name to clients
DNS Default Domain "with" mydomain.net

@VioletDragon
How did you configure the WAN IPs?

I cannot think of any reason, why a OpenVPN server should not work on localhost with port 1194 forwarded from the WAN IP.

Still waiting on the logs to see, what's the server complaining.

I either throw the subnet or IP, just depends on how you want to do it and as long as the firewall can route them.

On mine, Under IPv4 Local network(s):
10.250.2.0/24,10.10.10.8/32,192.168.100.0/24,192.168.101.0/24,10.10.10.7/32,10.10.15.90/32,10.250.10.0/24

Just a follow-up, since there's been no reply. I've concluded that it's related to or at least severely exacerbated by this issue in 24.11 with the dashboard impacting the system load: https://redmine.pfsense.org/issues/15969

It's kind of like the observer effect--it seems most prone to happening when I'm investigating it happening, or more particularly, when I've accidentally left a tab running the dashboard open. Earlier this week I logged in to get some info on a DHCP lease, forgot to log out and went on my merry way, came back a couple hours later to find that most of the OpenVPN connections had gone down again, plus there were a bunch of entries in system.log relating to php-fpm and connections being refused for loading the dashboard widgets. I restarted php-fpm and the gui from the console menu, and the VPN connections all came back online within a short period of time.

I'll be glad when 25.03 comes out so this problem is fixed!

@viragomann Thanks!!! It works!

@phil80

It works, syntax is wrong.
You have to specify time that token is valid for:
auth-gen-token 86400;
auth-gen-token 0; --->>Set to 0 never expires

For me it works on both Android clients and on windows also.

We use duo push mfa and when we change networks, we see in log that session token is used for reauth...

Also, if reneg-sec on server is 36000 and this option is not set on client it will still renegotiate after 3600 seconds because this is hard coded to 3600 if not set. And SMALLER number is used, so if server has 3600000 seconds set, and client has nothing specified, 3600 applies.

My settings:

reneg-sec 7200;
push "reneg-sec 7200";
auth-gen-token 86400;
status /var/log/openvpn-status.log;

Works like charm for 400 openvpn clients.

This is a config.

client setenv SERVER_POLL_TIMEOUT 4 nobind remote IP 1194 tcp dev tun dev-type tun ns-cert-type server reneg-sec 604800 sndbuf 100000 rcvbuf 100000 auth-retry nointeract verb 3 cipher AES-256-GCM ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM auth SHA256 ca /config/openvpn/keys/ca.crt cert /config/openvpn/keys/phone1.crt key /config/openvpn/keys/phone1.key