OpenVPN routing problems
-
Hi all, sorry for the noob question and poor English...
My local ISP block ports 80/443 and I need to host a website locally.
As a way to do this I setup a remote VPN with ports 80/443 open.
Then I setup a OpenVPN tunnel to connect this remote VPS with my local pfSense.
On this remote machine I setup some iptables rules to forward all incoming inbound requests on port 80 and 443 to my local pfSense through OpenVPN tunnel.
So far so good: my webpage is correctly shown.
I then tryied to implement GeoIP blocks on my webserver and it didn't work.
I found out by looking at pfSense logs that all connections to my webserver show as source address the ip adresss of OpenVPN client and not "original" IP.
Actual remote iptable rules are:
sudo iptables -t nat -v -LChain PREROUTING (policy ACCEPT 8 packets, 416 bytes) pkts bytes target prot opt in out source destination 6 384 DNAT tcp -- enp0s3 any anywhere anywhere tcp dpt:https to:10.168.11.1:443 2 88 DNAT tcp -- enp0s3 any anywhere anywhere tcp dpt:http to:10.168.11.1:80 Chain INPUT (policy ACCEPT 8 packets, 416 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 54 packets, 4320 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 26 packets, 1724 bytes) pkts bytes target prot opt in out source destination 36 3068 MASQUERADE all -- any tun0 anywhere anywhere
route:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default _gateway 0.0.0.0 UG 100 0 0 enp0s3 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3 10.168.11.0 10.168.11.1 255.255.255.0 UG 0 0 0 tun0 link-local 0.0.0.0 255.255.0.0 U 100 0 0 enp0s3
What am I doing wrong?
Maybe the MASQUERADE rule I don't understand?
kind regards
-
pfSense is the OpenVPN server end of the tunnel?
If so then, yes, the client end at the VPS is NATing the traffic leaving incorrectly.
That NAT rule may be allowing the replies if you have not assigned the OpenVPN server interface in pfSense to enable reply-to. So if you remove it and all traffic stops do that.
Steve
-
@stephenw10 said in OpenVPN routing problems:
pfSense is the OpenVPN server end of the tunnel?
yes, pfSense is OpenVPN server
@stephenw10 said in OpenVPN routing problems:
That NAT rule may be allowing the replies if you have not assigned the OpenVPN server interface in pfSense to enable reply-to. So if you remove it and all traffic stops do that.
OpenVPN server interface is assigned on pfSense.
If I remove this NAT rule from remote VPS my setup breaks and I can't see my webpage anymore.
Is there a correct way to accomplish that?
Thanks for the prompt reply.
kind regards
-
@gelcom
Yes, you have to remove the masquerading from tun interface to get the origin source IP.On pfSense you have to care that no firewall pass rule on the OpenVPN tab is applied to the forwarded traffic from the VPS. If this is your only one VPN it's best to remove all rules from this tab.
You have to define the pass rule on the interface tab of the VPN instance.
Also there must no floating pass rule match the traffic. -
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