pfsense boxes unable to reach each other over openvpn tunnel
-
@KOM said in pfsense boxes unable to reach each other over openvpn tunnel:
@jt Traffic from your LAN might be routed over the tunnel, but that doesn't mean all of pfSense internal traffic also goes that way. Localhost is still routed out WAN by default.
What is the actual problem you are trying to solve? Being able to reach each others DNS Resolver is pointless unless you have them running in forwarding mode.
they're supposed to be conditional forwarders. I have setup domain overrides which works OK with another site connected over IPsec. there was a similar problem, resolved by https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/accessing-firewall-services-over-ipsec-vpns.html but I didn't find anything similar for OpenVPN, so I assumed this type of VPN connection doesn't suffer such problem.
-
I don't profess to be an Unbound resolver expert (that would be user @johnpoz), but I seem to recall some posts elsewhere on the forum where Unbound has a default access control list that prohibits access to the resolver from an IP address that is not part of the local firewall's setup. That could be blocking the DNS lookups from clients on the "other" pfSense box. I think you can modify that characteristic using the Advanced Settings option.
-
Yup you hit the nail on the head @bmeeks, out of the box pfsense will auto create ACLs for the user for networks its connected to, but it doesn't do this for some remote network. You would need to open up your ACLs on unbound to allow the remote networks you want to be able to query unbound from.
I personally disable the creation of the auto ACLs - and just create my own.
-
You could still use domain overrides, but you would need to allow each one to get to the other's DNS via WAN, or perhaps you could add an outbound NAT rule to redirect all DNS out the OpenVPN tunnel.
I'm not exactly sure as I haven't tried it before.
-
this thread helped a lot, so now I can ping/nslookup from ovpn server side to ovpn client (no NAT needed, just a gateway + static route).
however, it doesn't work from the other direction. tried to configure the client the same way as the server, but it doesn't seem to be doing the same thing as on the server side (or I'm missing something..). -
So you set these boxes up with a site to site?? You wouldn't be creating routes and gateways if you setup a s2s connection... So I am a bit confused on how you have this setup..
-
yeah, sorry - S2S. so far it's been working fine with routes pulled. didn't create any GW's, just this one, as per the guide.
-
With a s2s setup... On your server side you would setup the remote networks that are on your client side, and on the client side you would setup the remote networks that are on the server side..
That is all that is too it.. Which guide are you looking at? Are you doing a PKI (ssl one) or a static key one?
-
i am doing static key.
as for your advice, that's exactly how I got it set up, and it works fine for all the clients on each network - they can communicate all fine.
my issue is with the firewall boxes themselves - they can't reach each other. currently (after creating a GW from the OVPN iface and assigned a static route to the other site's network) it works from ovpn tunnel's server side. the client is the last remaining piece that needs to be somehow forced to route all traffic originating from the box, destined to the other firewall, through the tunnel. -
@jt said in pfsense boxes unable to reach each other over openvpn tunnel:
they can't reach each other.
Well clearly that is not true - since if they could not talk to each other the vpn wouldn't be up.. Please be clear on what your trying to do exactly that is not working.
Your trying to ping the pfsense lan IP from the client site, your trying to ping the client side lan IP from the server side pfsense box? Your trying to do a dns query? What exactly?
-
they CAN reach each other's WAN address.
they CAN'T reach each other's LAN address. purpose is, I believe irrelevant, but the intention is to point the firewalls to each other for conditional DNS resolution, so the clients behind firewall1 can resolve hosts behind the firewall2, and vice versa.i'm checking the connectivity by SSHing to firewall1 and pinging the firewall2's LAN address. this currently (after adding the GW and static route) works from ovpn server side, but not from opvn client side.
thx for your help, guys.
-
What exactly do you want the other unbound to resolve for the other side, are you using different domains?
-
yes, different domains. i wanna be able to resolve host2.site2.domain.com from host1.site1.domain.com (site1.domain.com and site2.domain.com obviously being the domains at the two sites connected via ovpn tunnel).
edit for some more context: these are two different organizations, somewhat cooperating with each other, managed by a single IT team. therefore, it makes sense to us to have both sites reachable from each other, while not merging their domains.
-
yeah just setup domain overrides in the unbound so they know to go ask the other unbound. And then need to make sure the acls allow the queries, etc.
You will also need to make sure you setup private domains, because since your doing a forward for that other domain if it comes back as rfc1918 it would be a rebind. And you need to make sure the unbound is setup so it can use the interface it needs do the query down the vpn connection.
-
i made it work over IPsec and this guide: https://www.slideshare.net/NetgateUSA/routed-ipsec-on-pfsense-244-pfsense-hangout-june-2018
-
I'm surprised you didn't use the Netgate guides. They're the only ones I really trust.
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-a-site-to-site-ipsec-vpn.html
or
https://docs.netgate.com/pfsense/en/latest/book/ipsec/site-to-site.html
-
Its a hangout from netgate he was using.
-
Ah I didn't see that.
I prefer the docs. The videos are nice but too much blah blah blah. I can watch an hour-long video and try to hunt down the meat by skipping around, or blast through a text guide in 10 minutes. That's not to say that I don't like or appreciate the videos. On topics that I have little knowledge in, they're extremely helpful and I watch the whole thing. But when I just need the quick & dirty particular steps, the guide is best for me.