OpenVPN routing problems
-
Yup, exactly that. To get the required reply-to tags traffic must be passed on the assigned interface tabs.
Steve
-
I don't seem to get it.
My setup is exactly what you guys suggest:On OpenVPN general interface tag I have no rule assigned
On specific OpenVPN interface I have a allow all rule but this does not work.
As soon as I delete that NAT rule from remote client website stop showing.what am I missing?
kind regars
-
There are no states/matches shown on that rule on VPN_SP1_IN, are there ever any?
It needs to pass there to get the required reply-to tags on the states. Without that replies go via the default route rather than back over the tunnel. A packet capture will show that.
-
@gelcom said in OpenVPN routing problems:
As soon as I delete that NAT rule from remote client website stop showing.
Are you talking about the masquerading rule?
-
@viragomann said in OpenVPN routing problems:
@gelcom said in OpenVPN routing problems:
As soon as I delete that NAT rule from remote client website stop showing.
Are you talking about the masquerading rule?
Yes. As soon as I delete this POSTROUTING MASQUERADE rule on client side the website stop working.
-
@stephenw10 said in OpenVPN routing problems:
There are no states/matches shown on that rule on VPN_SP1_IN, are there ever any?
There were states before when postrouting masquerade iptables rule was active on client vpn (vps).
I reset all states prior to taking this screenshot. Sorry for not mention that.
-
@gelcom said in OpenVPN routing problems:
Yes. As soon as I delete this POSTROUTING MASQUERADE rule on client side the website stop working.
From the view of pfSense I cannot see any reason which would affect this.
Maybe it's rather on the backend server. However, the pfSense rule should show a state though.To narrow down run a packet capture on the VPN interface, while triggering packets from outside. You should see requests and responses, from and to the public IP.
If you can see requests only sniff the traffic on the internal interface to check if the server responses properly. -
When I NAT at client side source IPs are in the same network of WG interface and all works ok.
When I don't NAT at client side source IPs are not in the same network as WG interface.
How can pfSense know where to send the return package to?
Maybe this is the missing part of my config?
pfSense WG "server" is 10.168.16.1/24
VPS WG "client" is 10.168.16.2/24kind regards
-
@gelcom said in OpenVPN routing problems:
When I don't NAT at client side source IPs are not in the same network as WG interface.
WG?? You topic states OpenVPN.
Again, please run a packet capture to get a step closer.
The rule log says nothing at all!How can pfSense know where to send the return package to?
That's what @stephenw10 and me explained in posts 4 and 5.
If you have assigned an interface to the VPN connection and define the firewall rule, which is passing the access from the remote site on this interface, pfSense tags the connection with the reply-to. According to this pfSense directs response packets back to the respective gateway.This requires that a gateway is defined on that interface. This is done automatically on an OpenVPN instance. However, it might also require that the gateway is determined as online.
-
Those firewall logs show traffic being passed both with and without NAT at the client. But they are passing on the interface VPN_SP_BOTH which is not where you have set the rules.
What is that? Is it an interface group? That would break the reply to if so, it _must be passed on the assigned VPN interface directly.Steve
-
Hi all thanks for the support so far but I was sick for the last days and in this meantime the VPS deleted my inactive VM instance so I have to setup my VM and tunnel all over again...
I'll try again later and if I don't succed I'll try ipsec or wg tunnel later.
thanks for the support
kind regards
