OpenVPN routing problems

gelcom

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 -L

Chain 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

stephenw10

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

gelcom

@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

viragomann

@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.

stephenw10

Yup, exactly that. To get the required reply-to tags traffic must be passed on the assigned interface tabs.

Steve

gelcom

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

stephenw10

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.

viragomann

@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?

gelcom

@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.

gelcom

@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.

viragomann

@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.

gelcom

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/24

kind regards

viragomann

@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.

stephenw10

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

gelcom

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