Connect to network through another network using OpenVPN
-
Using your diagram I am trying to connect from "OpenVPN Remote Access" (172.29.6.1/24) to pfSense C (in this case a Juniper router), through pfSense A.
The IPsec tunnels in the office pfSense firewall for 10.0.1.0/24 show yellow Xs.
-
So it's OpenVPN remote access and IPsec?
In that case you would need to configure your OpenVPN Remote Access server to push a route for 172.28.4.0/24 to all its clients.
You need to be sure that the firewall rules on OVPNS3 (Remote Access) on pfSense A pass traffic from 172.29.6.0/24 to 172.28.4.0/24.
You would need a second phase2 entry on the IPsec tunnel between pfSense A and router C for traffic from 172.29.6.0/24 <-> 172.28.4.0/24. This would need to be set correctly on both sides, of course.
And that should just about do it.
-
Here are the phase 2 entries in pfSense:
Here is the IPsec status:
Open VPN rules:
Router C is a little different because its a Juniper but I have similar rules setup there.
-
So are you trying to run IPsec over OpenVPN? I'm still unclear on exactly what you're trying to do.
I also have to apologize. I'm running out of anything other than 2.2 to refer to when evaluating your screen shots.
-
Going back to your diagram:
Right now, host A1 (172.26.0.100) can access local network resources on the LAN of router C (172.28.4.1/24) using IPsec.
Unlike in your diagram though, pfSense A and C do not share a WAN. Two separate WANs, two separate ISPs.
The Open VPN Remote Access computer can access the LAN of pfSense A (172.26.0.1/24), but cannot access the LAN of router C.
-
Going back to your diagram:
Right now, host A1 (172.26.0.100) can access local network resources on the LAN of router C (172.28.4.1/24) using IPsec.
Ok
Unlike in your diagram though, pfSense A and C do not share a WAN. Two separate WANs, two separate ISPs.
Okay. That doesn't matter.
The Open VPN Remote Access computer can access the LAN of pfSense A (172.26.0.1/24), but cannot access the LAN of router C.
Like I said, you have to trace everything. We're in sort of a bind because there's a juniper in the mix. I have no personal experience with them.
But in order for one of the OpenVPN Remote Access clients on 172.29.6.0/24 to open a connection to 172.28.0.100 certain, predictable things have to happen.
There have to be routes in both directions and there have to be firewall rules permitting the traffic. I believe I have already said what has to happen on the pfSense side of things above.
I feel like I have to apologize, but I really don't feel like spending an hour detailing what has to happen hop by hop in both directions.
Every time a packet has to be forwarded on its way, there has to be a route for it.
Every time a packet enters a (pfSense) interface, there has to be a firewall rule permitting it.
-
The thing I don't understand is that as far as I can see, there is a rule for everything. Everywhere that there is a connection between 10.0.0.0 and 10.1.0.0, there is also a connection for 10.0.1.0 and 10.1.0.0.
If you don't have time to help that's fine, I'm just stumped.
-
Look at the routes, look at the rules, at each hop. If everything is in place it will work, juniper element notwithstanding.
If it's outbound there has to be a route. Inbound, a rule.
-
And use traceroute, ping with logging of block rules and/or packet capture at each hop to see where and how far packets get - that can help you concentrate on the hop/router that has the configuration typo, when your brain has gone fuzzy looking over the settings.
-
Good catch on the trace route. I tried a trace route to a machine on 10.1.0.0/24 on the open vpn remote access and instead of trying to go through the 10.0.1.1 gateway it tried to go through my local router at home (the way it would for an external IP).
So pfSense is not pushing the 10.1.0.0/24 network to the OpenVPN clients. Now I need to figure out why.
10.1.0.0/24 IS being pushed to 10.0.0.0/24 via IPsec. When I do a trace route here it hits pfSense first, then the external IP of the remote network (Juniper router "C"), and then the computer on the remote network.
-
OK I managed to get it working by checking the "Force all client generated traffic through the tunnel." option.
