OpenVPN on a stick - how to route traffic from branch to headquarters
-
I am following the design indicated here:
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-route-internet-traffic.htmlI have a VSP hosting a pfSense VM (no other LANs behind it, i.e., on-a-stick) and am connecting up my branch office device to it. I have the policy-routing setup that should take my traffic over the VPN and out over the internet - but it doesn't.
Key points:
- There are no other networks at my 'headquarters' pfSense firewall - just a public IP
- The tunnel establishes - from the diagnostics of each device, I can ping both the server and client IPs, on both devices (10.0.8.1 for the server and 10.0.8.2 for my one client)
- I am unable to ping devices in my branch office from my headquarters
- When the policy route firewall rule is enabled, my branch office devices are unable to get out to the internet.
What am I missing and what else can I provide to help figure out what is going on?
-
@laserguidedcake said in OpenVPN on a stick - how to route traffic from branch to headquarters:
I have a VSP hosting a pfSense VM
A VPS?
Did you add the branch LAN to the servers "remote networks'?
Is the branch VPN endpoint the default gateway?
Did you add a firewall rule to allow the access? -
VSP
Virtual Server Provider - think DigitalOcean or Vultr
branch LAN to the servers "remote networks'?
Indeed I have, the one LAN I am trying to send over this vpn connection is hanging off my OPT2, and is a 10.10.12.0/24 - that is exactly how I have it defined on the server for OpenVPN:
Is the branch VPN endpoint the default gateway?
I thinnk I understand what you are asking, and yes - in the policy, I do have the gateway configured (the opt2 interface, and the policy setup for the 1 IP I am using for testing):
add a firewall rule to allow the access?
Indeed - At my 'branch' under the OpenVPN and opt3 firewall rules, and at the headquarters on the OpenVPN, I have any/any/all rules set.
-
@laserguidedcake
So the routing should work already.There are some things to care of and they differ for inbound and outbound.
For outbound ensure that there is an outbound NAT rule on the VSP for the branch LAN.
Also consider that the policy routing rule directs any traffic to the remote site. Hence you"re not able to acccess a local DNS. So If you use the DNS on pfSense you need an additional rule above of this to allow it.For inbound, ensure that the LAN device doesn"t block the access from outside of it"s subnet.
I suspect that you want to forward internet traffic on the VSP. In this case you have to remove the pass rule from the OpenVPN on the branch. The traffic has to be passed by a rule on the OPT interface. -
outbound ensure that there is an outbound NAT rule on the VSP for the branch LAN.
Indeed, per the instructions, this is what I have in-place:
DNS on pfSense you need an additional rule above of this to allow it.
Great consideration, but, for testing at the moment, just using public DNS
I suspect that you want to forward internet traffic on the VSP. In this case you have to remove the pass rule from the OpenVPN on the branch. The traffic has to be passed by a rule on the OPT interface.
You are correct in your suspicion and I did have this rule in-place; it has since been removed, and I can see the rule on my OPT3 interface now passing traffic.
Unfortuantel, I am still unable to egress to the internet...
A recent point of interest; when performing a live packet capture from the "ovpnc1" interface at the branch - I can see my traffic; ICMP requests as an example. But when attempting the same capture from the headquarters, I do not see the traffic coming through (I only see the ICMP keep-alives from both firewalls).
-
Another slight development:
After following more of the instructions located in this section of the recepie - https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-route-internet-traffic.html#configure-outbound-nat
I stripped the NAT setting from the headquarters, and moved it to the branch - my clients in the branch can now egress to the internet (although double-nat'ed).
This is just half the issue, as trying the last part of the recepie to get inbound NET working:
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-route-internet-traffic.html#port-forwarding-or-1-1-nat-to-hosts-at-the-remote-officedoes not work...
At this point I believe I don't have NAT configured correctly, or there is some other issue preventing it from working correctly at the headquarters.
-
@laserguidedcake
Is the VPN Tunnel Mask a /30?You said, you cannot access the LAN device from remote. Regarding this I mentioned to check it"s firewall. Did you do that?
If the device blocks access from outside its subnet it will block Internet access as well, naturally.
You can do a Packet capture on the branch on the VPN and LAN interface to investigate if the NAT works and If the device is responding. -
@viragomann
Looks like we have something here!At this pointI changed my tunnel subnet to a /30 - after doing so, everything appears to be working; I can ping clients from headquarters, and clients can egress to the internet through the headquarters firewall
you cannot access the LAN device from remote. Regarding this I mentioned to check it"s firewall. Did you do that?
I did - I a have any/any/all's in place to allow this traffic, but, this didnt seem to be the issue.
do a Packet capture on the branch
I will probably do this in a but, just to see hwo the traffic itself looks.
I am abit miffed - it would appear that shrinking the tunnel to a /30 resolved the issue; what is going on here? I have NO other overplapping network spaces, so I am at a loss as to why this would cause the issue I was seeing...
-
@laserguidedcake
A site to site should have a /30 tunnel, otherwise the server doesn"t know, where to Route the packets for the client side LAN.You can use a wider tunnel though if you want to connect multiple clients, but in this case you need to configure client specific overrides on the server to enable iroute in OpenVPN.
Egress from the branch should also work without NAT nö.