The following problem I am facing. I have too pf-Sense and between them I have a site to site OpenVPN connection wich works when I want to go from lan A to lan B. But now pf-Sense A has a static public IP und B does not have a static IP. My domains point to A but some of the servers are located on the lan of B. My problem now is that packets reach the servers on the B lan but because there source IPs have not changed pf-Sense B routes them to the default gateway instead of going back through the site to site VPN. Is their a way to solve this problem in pf-Sense?
What problem you describe is what dynamic DNS solves - then the endpoint becomes a DNS address and not an IP. This is trivial with IPSec, unsure about OpenVPN.
I’m not sure what all the answers here are going on about, but this is called asymmetric routing. It’s unlikely a simple static route alone will fix this since the return address is an external public IP.
You will need a firewall rule in site B to force return traffic back over the VPN, as opposed to the default route. (aka policy based routing.) This would be at site B, configured on the LAN rules, and have a source of the internal NAT’d IP at site B with a destination of any. Specifically, it needs to have a gateway specified (under advanced options) and set this to your OpenVPN interface. This will force all traffic from the NAT’d IP over the VPN, the rule could be further refined to only return NAT’d traffic if desired. (Also, you may need an outbound NAT policy at site A to allow this traffic to go back out, depending on if this is manual or auto/hybrid at site A.)
Use IPsec for site to site instead. Is there a specific reason for OpenVPN?
IPsec has better performance. Handles remote subnets better and is more stable.
It also handles the other side having dynamic IP perfectly with some minor tweaks.
if I understand you correctly it sounds like you want to send all lan B traffic out lan A? so client ingress → static ip for site A → s2s tunnel to lan b → server on lan b → egress site A ?? Add a fw rule to site b’s pfsense lan b to send all traffic sourced from lan b to site A via s2s tunnel ovpn gateway. you need to specify the ovpn gateway in the firewall rule. you also might need an outbound NAT rule on site A’s side to get traffic sourced from lan b out. sorry if I misunderstood.
I think you need to add a static route on pfSense in site B for the subnets in LAN A using the OpenVPN server IP (pfSense in LAN A) as a gateway. I believe that the OpenVPN client creates a gateway for you but you can always create it manually if it didn’t.
First thanks for the answers. So if I understand you correctly would a IPSec tunnel between A and B solve my problem by properly translating the packets? Meaning packets exiting the IPsec tunnel have it as it source?
Thanks for this this helpful and detailed answer. How would I go about it to refine this rule to only send traffic through the VPN that came through it in the first place. And second question, what would be the NAT´d IP on the B site. Is it the WAN address? First time doing this kind of networking
Wow thanks for this reply Im learning networking topics and this is the first use case ive come across that’s a Use Case for policy based, since seems majority use route based.
Thanks for the answer but not all traffic should go through. Only the traffic that’s coming in through the A site and gets routed to the B site LAN should go through the VPN in both directions.
First thanks for the answer. The route and the gateway are created by pf-Sense automatically and the connection between lan A and lan B works already. My problem is with traffic entering the A site from WAN wich is meant for a Server on the B site. That traffic doesn’t make it back through the pf-Sense on the B site because the source ip of those packets is internet traffic. So it gets in through WAN on the A site and leaves it on the WAN B site.
First, I’d start with a broad rule to make sure it’s working as desired. You can prove this via traceroute or a “whatismyip” type thing, both which should be site A. To further refine it from here, you’d have to ascertain the source or destination port of the return traffic. (I’d use a packet capture.) Hopefully it’s a consistent protocol with a consistent port in at least one direction. In which case you’d have to refine either the source (or destination) port of site B’s firewall rule to only capture the NAT return traffic. If it’s entirely ephemeral (random) for both source and destination ports, you have no choice but to force ALL traffic out site A.
When I reference the NAT’d IP at site B, I’m saying the internal LAN address at site B. (Not the WAN address) Be it a VM, server IP, etc. It’s the IP address you’re sending the NAT to via site A. This rule basically says, “server at site B, send all traffic over the VPN” and then site A takes over for internet access, etc. The above paragraph talks about further refining that to say, “server at site B, I know this is traffic that came to me from site A (because of the port number) send THAT and ONLY that traffic to site A. All other traffic, use the default gateway at site B.” (All other traffic is handled by the default outbound policy. The firewall rule is an exception to that rule, aka policy based routing.) It’s way easier to just send all traffic to site A, but you CAN dial it in further if needed.
Source based routing is much more common to see at enterprise network levels, but really, it can be applicable any time you have multiple possible routes. You can also go even deeper down the rabbit hole with things like BGP/OSPF and conditionally advertise preferred gateways based on network source.
Ah, I missed that, apologies. I realize it’s been a few days, did you get this sorted out? If not my next suggestion would be to use HAProxy in site A and that way the server in site B sees the source address as a box in site A and therefore no extra NAT or policy based routing would be required.
