Port forwarding into remote VPN Network

allen4444

Dear pfSense Users,

I have two different pfSense Boxes connected via a OpenVPN Site-To-Site Tunnel:

< WAN 111.x.x.x> < WAN 222.x.x.x>
< pfSense 1 VPN Client> –------- VPN Site-To-Site Tunnel --------< pfSense 2 VPN Server>
< LAN Network 192.168.10.x> < LAN Network 192.168.11.x>

Every pfSense is configured as transparent bridge meaning that WAN and LAN are joined as a bridge.

The VPN Network does work and I can reach a 192.168.10.x address from the 192.168.11.x network.
Also it works to make a port forward from WAN 111.x.x.x address to 192.168.10.x address

What I try to achieve is to make a port forwarding from WAN 111.x.x.x (pfSense1) address to a 192.168.11.x (pfSense2) address.
If I add a Port Forwarding rule, my request will be blocked.

I thought a solution would be to make the VPN to an interface on pfSense 1 and join it also into the bridge, but does also not working.

Has anybody an idea to solve this problem?

Best regards,
allen

Derelict

What kind of VPN? OpenVPN is much more flexible in this regard.

allen4444

Its a OpenVPN Site-To-Site Connection.

If I make a port forward vom the pfSense 1 WAN IP to the pfSense1 LAN IP it does work.
But if I try to make a port forward from pfSense 1 WAN IP (Virtual IP Alias) to the pfSense 2 LAN over the VPN it does not work and
will be blocked.

Derelict

You need to assign an interface to the openvpn instance at the server side (the target of the port forward) and be sure the traffic into that firewall is NOT passed by rules on the OpenVPN tab but ARE passed by rules on the assigned interface tab.

Then you will have reply-to there.

allen4444

Thanks, that didi work!

Why should the traffic NOT passed by rules on the OpenVPN tab?
If I do not add this rules, it does still work.

Derelict

Because the OpenVPN tab is really an interface group consisting of all OpenVPN servers and clients on the firewall. Traffic passed by rules on an interface group tab cannot be flagged with reply-to because pf does not know which interface the traffic arrived on (it could be any interface in the group).

The firewall processes interface group rules before interface rules so the traffic must not match any rules on the group because there will be no reply-to so replies don't get directed back out the way they came in but are instead routed according to the routing table. When dealing with connections from arbitrary internet sources, this usually means they go out to the default gateway. There would be no matching state on that interface so that traffic is usually dropped. Even if it wasn't dropped and made it back to the originating host, the firewall there would probably drop the traffic because it would be sourced from a different IP address than the connection was originated to.