Route WAN traffic to a remote site via tunnel

depam

@steveits Thank you. Is there an equivalent one for OpenVPN? It seems the doc is more on outbound not inbound.

SteveITS

@depam https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-route-internet-traffic.html

From
https://docs.netgate.com/pfsense/en/latest/recipes/index.html#openvpn

depam

@steveits Strange that i can't make it work

I tried Port Forward the port it will listen to from WAN and from Firewall rules, added a destination IP on remote host with gateway set to the OpenVPN tunnel. With this, it looks like it is still not passing the traffic to remote.

from the doc,

Port Forwarding or 1:1 NAT to hosts at the Remote Office
It is possible to forward traffic initiated by hosts on the Internet to a server at the remote office in a couple different ways. This can be useful, for example, if a server was relocated but there are still outdated DNS records or links pointing to the old location.

This can work in one of two ways:

If the client gateway is redirected using the OpenVPN server option, there is no need for additional configuration. Add the port forwards or 1:1 NAT and it will work as-is.

If the OpenVPN interfaces are assigned, this can work by allowing the reply-to keyword in pf to handle return routing. The remainder of this section covers this process.

For some reason i do not want to force client gateway but was wondering for the second instance of reply-to where to set it

viragomann

@depam
Which device is the VPN endpoint at site B?
And is it the default gateway?

depam

@viragomann Its another PFSense SG-3100. I am trying to route traffic from PFSense AWS to a remote appliance. Yes. It is a gateway of the clients behind it.

viragomann

@depam
I have noticed, I'd explained all the steps already in your other thread. So look over there.
If it doesn't work, come back with details.

depam

@viragomann Thanks. That topic is already done and I already succeeded on it. I am now able to route client side traffic to remote site WAN via tunnel. This use case is something like this.

The Site B (acting as OpenVPN client) does not have public IP address.
Site B have some services that needs to be exposed publicly from the internet

Current setup:

1.) Site A (PFsense on AWS acting as OpenVPN Server) with elastic IP assigned
2.) Site B (PFSense appliance acting as OpenVPN client) no IP

Goal is to expose a port on Site A which has a public IP and routing it to Site B routing it to the already established OpenVPN tunnel so that it could be accessible from the internet. The external client will only hit Site A at this point from WAN to be able to access resources in Site B. Thanks in advance.

viragomann

@depam
That is exactly the use case which I described there. Maybe I understood you intention wrong.
So you can apply these suggestions here. I copy them into this thread.

Assuming you have a site to site OpenVPN without DCO enabled to this:

On the server

Give the tunnel network a /30 mask.
Enter the client side LAN or even the subnet of the destination server into the "Remote Networks" box.
Forward the traffic you want normally by stating the IP of the destination host on clients side as redirect target.

On the client

Enter the server side LANs into the "Remote Networks" box.
Assign an interface to the OpenVPN client instance (e.g. ovpnc1) and enable it if you didn't this already.
Ensure that there is no pass rule on the OpenVPN tab and also no floating pass rule matching the forwarded traffic from the remote site. Remove the default pass any to any rule.
Add a pass rule for this to the clients VPN interface instead.
If you're running multiple OpenVPN instances on the client site, it would be easier to assign an interface to each for the respective rule and leave the OpenVPN tab blank.

If you obey all these points you should be able to successfully forward traffic from A to B.

depam

@viragomann Thanks. Yes this is exactly what i did but didn't work for me.
i have tried with and without setting a gateway. This is exactly what I am trying to do

client (outside infrastructure) (FQDN:443) --> Internet --> Site A (PFSense port forward 443 to Client B x.x.x.x:4443 using VPN gateway --> Site B (some client application x.x.x.x:4443)

The above already got the pass rules and NAT configured.

Out of curiousity, for port forward, do you know if it works if its limited to TCP connection? How about UDP?

viragomann

@depam said in Route WAN traffic to a remote site via tunnel:

Out of curiousity, for port forward, do you know if it works if its limited to TCP connection? How about UDP?

No, you can forward any protocol you want.

Maybe your destination server at B which is listening on 4443 is blocking access from outside by its own firewall?
Consider that this is the default behavior on devices with Windows or Linux or similar.

depam

@viragomann Software firewall is disabled and i can access it from other VLANs when a proper rule is set.
Just to confirm, in the above example when you say forward it means port forward on WAN side right?

It's something like this
Source: any
Destination: IP of the client B address
GW: OpenVPN tunnel GW

I tried with both with and without gateway and didn't work although rules area already in place for both ends. Was thinking now if its worth to do a double NAT one with local address/virtual and do policy routing to Site B.

viragomann

@depam
The destination in the forwarding rule has to be the WAN address of A course.
At redirect target state the IP of the server at site B and its port.

This presumes that the site-to-site is already working. Means that you can access site A LAN devices from site B LAN.

depam

@viragomann So it is a bit confusing now cause there's two things

1.) Port forward via NAT. (Firewalls --> NAT). When I do this the setting looks fine and destination is WAN and redirect IP is the IP of Client B
2.) Firewall --> Rules --> WAN. In here the destination is IP of client B and i just really put gateway of the tunnel

depam

@viragomann Thanks. It works now.
My mistake is that on Client B, i restricted the source to the VPN tunnel address. Since this is NAT i guess its really just a pass thru and setting the source to any fixed all the issues.

Thank you very much for the help and the patience. Cheers!