OpenVPN client - Routing from LAN?
-
Hi all,
For some reason I can't find the right search terms to locate what to do here, but I bet it's been answered before. I have a remote OpenVPN server running, and I would like PFSense to connect to said OpenVPN server and route any traffic from the local LAN (
192.168.10.0)/24destined for192.168.11.0/24through the VPN.The VPN connects great and I can ping hosts from PFSense. However, I can't ping hosts from any machine on the local LAN.
I've tried:
- Setting "IPv4 Remote network(s)" in the OpenVPN client settings to
192.168.11.0/24 - Adding
route 192.168.11.0 255.255.255.0to the "Custom options" in the client settings - Creating firewall rules in LAN for the two networks
- Creating firewall rules in OpenVPN for the two networks
I must be doing something just flat out wrong, and hoping someone here can help.
Once I've got the VPN client working, what are the next steps to route LAN traffic to a specific subnet through it?
Thanks!
- Setting "IPv4 Remote network(s)" in the OpenVPN client settings to
-
If it helps, the following is in the status for OpenVPN:
Local address: 192.168.87.253:40531
Virtual address: 192.168.255.6The virtual address is being provided by the OpenVPN server, and I can ping that from my LAN clients.
-
With that virtual address I'd guess the other site is configured for a RAS/Client style network as in a tunnel settings normally you only have 2 IPs (.1 and .2) on either end of the tunnel. But perhaps I'm wrong and you have 192.168.255.4/30 as your tunnel network? What you seem to achieve is a Site2Site VPN that has to be configured in another setup. That's what those different server settings of OVPN are all about. A client-style VPN server doesn't need information about the networks "behind" the dialed in client so has no clue about them and won't send packets that way. That's why you need a tunnel style site2site setup where you define (on both ends) what local and remote network you want to connect. Otherwise those hosts aren't accessible.
If that's a tunnel network setup, check that you correctly configure the local and remote networks on both side. Also check under Diagnostics/Routes if those routes are there. Then check your firewall filter rules on both ends if you permit incoming traffic via OpenVPN interface so you won't get blocked. :)
But for better guesses/help we'd need screens from the config of both ends as well as the rules.
-
Ok.. my post is getting flagged as spam, so I'm going to try to break it up and figure out what's causing it:
Thanks for the help! The server side is an OpenVPN docker container. It's not configured to be a tunnel per-se, just a server, but I have used it as such when I was using DD-WRT instead of PFSense. DD-WRT basically handled all the firewall rules for me, so I'm guessing it's something to do with me messing that up. Your routing comment got me a bit closer bit still no luck. I've switched up the address space since starting, so here's how everything looks now (but with the same results):
Relevant parts of server config:
server 192.168.255.0 255.255.255.0 ... proto udp port 1194 dev tun0 .. route 192.168.254.0 255.255.255.0Routes on server (172.18 is the Docker address space, running on a machine in 192.168.6.x):
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.18.0.1 0.0.0.0 UG 0 0 0 eth0 172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.254.0 192.168.255.2 255.255.255.0 UG 0 0 0 tun0 192.168.255.0 192.168.255.2 255.255.255.0 UG 0 0 0 tun0 192.168.255.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Ping from OpenVPN server to PFsense client:
# ping 192.168.255.10 PING 192.168.255.10 (192.168.255.10): 56 data bytes 64 bytes from 192.168.255.10: seq=0 ttl=64 time=40.523 ms 64 bytes from 192.168.255.10: seq=1 ttl=64 time=42.446 ms ^C --- 192.168.255.10 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 40.523/41.484/42.446 ms bash-5.0#Ping from PFSense to network behind OpenVPN server:
: ping 192.168.6.1 PING 192.168.6.1 (192.168.6.1): 56 data bytes 64 bytes from 192.168.6.1: icmp_seq=0 ttl=62 time=42.249 ms 64 bytes from 192.168.6.1: icmp_seq=1 ttl=62 time=40.428 ms 64 bytes from 192.168.6.1: icmp_seq=2 ttl=62 time=99.519 ms ^C --- 192.168.6.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 40.428/60.732/99.519/27.437 msPing from machine on LAN behind PFSense to network behind OpenVPN server:
$ ping 192.168.6.1 PING 192.168.6.1 (192.168.6.1) 56(84) bytes of data. ^C --- 192.168.6.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1009ms
-
And now it thinks I'm a new user even though I've been around for years and years so I have to wait 120s ;)
Turns out it was pasting XML causing the spam error.
PFSense OpenVPN client config (minus security/host info):
PFSense routes:
Interface assignments (I've tried this since the first post):
Firewall:
As you can see the firewall setup is pretty permissive as I try to figure this out.
-
@Fmstrat said in OpenVPN client - Routing from LAN?:
Ping from PFSense to network behind OpenVPN server:
That works, because your VPN Server has - as per your routing table - the VPN transfer network available and as pfSense always pings from the network interface that is nearest to the destination - in that case it's the ovpn interface itself - that gets answered correctly. But your Docker OVPN is missing the route back to the 192.168.10/11.0 network as I don't see that in your routing table at all. Without that, not traffic will flow back to pfSense through the tunnel.
As pfSense itself is acting as a client rather then a real site2site connection it's on you:
Do you want a site2site VPN? Then I'd change the docker container OVPN instance and either add another OVPN server for that or switch the available one to site2site config with shared key. That's the easiest setup available.
If you only want to have clients on the Docker site available to access FROM your pfSense/LAN and you don't care if anything on that side wants to access your pfSense LAN - then you can simply add a Outbound NAT rule on the OVPN interface to NAT anything from your LAN network range (source) to your target destination network gets NATted to the OVPN interface address.
I don't know exactly what where the 192.168.6.x or 192.168.254.x networks are, you didn't mention them in your original post so it's quite hard ATM to guess what is what :) But just as an example:
That would NAT your local LAN only when leaving through your OVPN interface to a certain destination IP Range and NAT it to your OVPN GW Address that should be accessible to your target server so it can route back your packets to you. That's no solution if you want equal access from Site A <-> Site B though!
-
Got it!
NAT was the key, vs modifying rules manually. I have now deleted the extra interface and all firewall rules and all is good. The .10 network no longer exists, I changed up the scheme (mentioned that above but probably wasn't clear). Thanks!
