@chitchat said in OpenVPN wizard WAN rule allows outside access to the administrative WebGUI:

The only pass rule for WAN is one created by the OpenVPN wizard

The pfSense+ OpenVPN Wizard created this rule, or what wizard? That's more a "let's get hacked" rule.

The "OpenVPN OVPN WAN Remote Access for Cos wizard" rule allows access from any outside IP, any protocol to the pfSense+ address.

What you want is to follow Netgate docs: OpenVPN Firewall Rules.

Basically: change protocol to UDP, destination port 1194 (if the OpenVPN port left as standard).

@pietsnot56 said in Endpoint address family (IPv6) is incompatible with transport protocol (udp4):

Any idea what's wrong?

Many cell networks are now IPv6 only. On Android devices, 464XLAT is used to connect to IPv4 only sites over an IPv6 only network. iPhones use something similar, but I don't know the details. Perhaps there's some issue there. My phone gets the IPv4 address 192.0.0.4, which is reserved for 464XLAT, as well as a global IPv6 address.

I have pfSense configured to allow openVPN to use either IPv4 or IPv6 to connect. Do you have IPv6 available from Telenet?

BTW, Telenet used to be an X.25 packet switched network back in the dark ages. The company I used to work for provided Telenet in Canada and I maintained part of that system.

@rajukarthik Outbound or inbound?

@stephenw10 Yes you are correct, I misunderstood myself. After my box crashed doing the 2.6.0 to 2.7.0 upgrade and eventually after getting 2.7.0 to work, I compared both xml backup files and only saw differences in time stamps, but now realise it's the import of updated packages that caused my problem.

I'm running ZFS and will look at taking an image snap once I work out how to get from Pfsense to FreeBSD, out and back via a USB3 port. That suggests I need an external monitor, keyboard, and mouse on the box, unless it can be done through Pfsense GUI, but that won't work for recovery if the GUI has crashed. I've met these situations before and an image snap can only be trusted to work if you've actually used it successfully to recover. In the PC world I've trusted and used Acronis for years. Thanks for the link. I've always created bootable flash sticks and created matching config XMLs. Once the box crashes, I'm offline with no internet access to download anything or get help asking questions. I still keep an ISP Thomson box handy just in case.

Thanks for your help - regards - Vox

Solved, since i'm using azure vm i'd to add route on azure portal.

Thanks to all

Update:

I had the same issue today, configuring another client with the same topology.
This time i had another pfsense 2.7.2 needed the extra routing on CSO when i created a remote access open VPN Server on the same pfSense.

I lost access suddenly during configuration, and then i had to use again Client specific override for the VPN Tunnel in order to communicate again. Based on above, it seems that Open VPN inter-routing acting strangely.

Is this a miss-configuration from my side, and i should always have that extra routing for the remote access tunnel ? or is a bug in the OpenVPN implementation on pfSense ?? Still i'm wondering why some instances working and some not.

Please, awaiting for any comments and if someone faced that again in the past.

@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 ;-)