pfSense HA with OpenVPN behind NAT
-
Hi all,
I have a private network of 192.168.100.0/24. My public IP is 78.83.163.141.
I have two VMs running pfSense Community Edition 2.6.0 and respectively OpenVPN Server 2.5.4.
Both VMs have a single network interface set as WAN with addresses from the private network: 192.168.100.10 and 192.168.100.11.
I've configured a HA between them with CARP IP 192.168.100.12.The OpenVPN server is set to UDP 61194 with tunnel network of 192.168.104/24.
I've added an outbound NAT for 192.168.104/24 to the CARP IP 192.168.100.12 (so all OpenVPN packets to be routed through the CARP).I've added a NAT on my public IP, port 61194 to 192.168.100.12, port 61194 (public to CARP).
The whole thing works except:
-
list itemI see as client IP the IP of the router, not the real public IP address of the client
-
list itemI receive the following error when connecting
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1683797029) 2023-05-11 12:23:49 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings TLS Error: incoming packet authentication failed
and in the server logs I see
MULTI: bad source address from client , packet dropped
After a lot of the messages above, the client connects, but sometimes the process times out and it retries.
I'd appreciate any help so I can clear those errors. If you need more information, I'd be glad to share it.
-
-
@parushev said in pfSense HA with OpenVPN behind NAT:
list itemI see as client IP the IP of the router, not the real public IP address of the client
So your router does masquerading on inbound traffic.
Possibly you can change that.list itemI receive the following error when connecting
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1683797029) 2023-05-11 12:23:49 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
TLS Error: incoming packet authentication failed
and in the server logs I see
MULTI: bad source address from client , packet dropped
Does the client address change?
-
@viragomann thank you for taking your time answering.
I'll try the masquerading thing. Read about it but wanted to make sure by asking.
What do you mean by "does the client address change"?
The client is a friend's PC (OpenVPN client 2.6.0), behind a home router which has public static IPv4. -
@parushev said in pfSense HA with OpenVPN behind NAT:
What do you mean by "does the client address change"?
Masquerading is what your router does if you see the internal router IP instead of the public IP of the client.
Some consumer router do this by default, so the access is normally accepted by the destination device. Because access from outside of the local subnet is usually blocked by the devices system firewall by default.But there should be an option to disable it on the router.
The client is a friend's PC (OpenVPN client 2.6.0), behind a home router which has public static IPv4.
When the client sends a packet to you, the source address is translated into his public address by his router. This must not be disabled, otherwise routing won't be possible. And the public IP is what you want to see.
On your router it shouldn't be translated again, but as mentioned above, some consumer router do this with default settings. -
@viragomann thank you for your information.
Without touching anything else, by changing the NAT to the direct IP of the MASTER node and reconfiguring the OpenVPN server to listen on the WAN, not the WAN CARP, the VPN works without any error message. Of course, I again see the private IP of my router as a connected client since I haven't changed anything.
-
@parushev
Is CARP working well? Check the system log for regarding entries.Is the OpenVPN server down on the secondary?
Do you have a single router or is it an HA system as well?
How are your pfSense boxes connected to it? Is there a switch or another device in between?
Are they installed on bare metal or virtualized?
Note: When a device is talking to the CARP VIP, it resolves the VIP and get the CARP MAC address and send the packet to this. However, pfSense uses its real interface address (WAN in your case), when replying.
Some devices don't love this behavior. Maybe you're affected of this.