Connect to network through another network using OpenVPN
-
I am trying to setup a VPN connection to one network through another network.
Home: Varies depending on employee
Office: 10.0.0.0/24
Remote: 10.1.0.0/24
I have a VPN tunnel between 10.0.0.x and 10.1.0.x. This functions as expected. I can access local network resources on 10.1.0.x from a machine on 10.0.0.x.
When a computer connects to 10.0.0.x using OpenVPN, they are assigned an IP address of 10.0.1.x (where x is any number between 2 and 254). Connecting to 10.0.0.x works as expected and I have access to local network resources.
I have a VPN tunnel between 10.0.1.x and 10.1.0.x with the exact same settings, but when connecting first to 10.0.0.x and then attempting to access local resources on 10.1.0.x, it doesn't work.
Open VPN server settings in pfSense:
General information
Server Mode Remote Access (User Auth)
Backend for authentication RADIUS for VPN
Protocol UDP
Device Mode tun
Interface WAN
Local port 1194Cryptographic Settings
TLS authentication Enable authentication of TLS packets
Peer Certifcate Authority pfSense CA
Server Certificate vpnuser (CA: pfSense CA) *In Use
DH Parameters Length 1024
Encryption algorithm AES-256-CBC (256-bit)
Hardware Crypto VIA Padlock (no-RNG, ACE)Tunnel Settings
Tunnel Network 10.0.1.0/24
Local Network 10.0.0.0/24
Concurrent connections 5
Compresson Compress tunnel packets using the LZO algorithm.Client Settings
Dynamic IP Allow connected clients to retain their connections if their IP address changes.
Address Pool Provide a virtual adapter IP address to clients (see Tunnel Network)
DNS Servers Provide a DNS server list to clients
Server #1: 10.0.0.8Nothing on the 10.1.0.0 network has changed for at least a year, but about 6 months ago our DC/DNS/RADIUS server on the 10.0.0.0 network died on us and I had to rebuild it. So I'm sure the problem is on that end somewhere, but I can't for the life of me figure out what.
The only reason I don't have OpenVPN configured on the "remote" location is because the router there doesn't have out of the box support for it like pfSense.
Any additional info I can provide, let me know.
-
One thing that caught my attention, when I download the config file for pfSense I see this under dhcpd right under the "lan" entry:
- <opt1>- <range><from>10.0.1.50</from>
<to>10.0.1.99</to></range>
<defaultleasetime><maxleasetime><netmask><failover_peerip><gateway>10.0.1.1</gateway>
<domainsearchlist><ddnsdomain><tftp><ldap><next-server><filename><rootpath><numberoptions><winsserver>10.0.0.5</winsserver>
<dnsserver>10.0.0.5</dnsserver>
<enable></enable></numberoptions></rootpath></filename></next-server></ldap></tftp></ddnsdomain></domainsearchlist></failover_peerip></netmask></maxleasetime></defaultleasetime></opt1>
I think that could maybe have an affect on this, but I have no idea where this is in the web console.
-
I am trying to setup a VPN connection to one network through another network.
..
I have a VPN tunnel between 10.0.1.x and 10.1.0.x with the exact same settings
Are you trying to pass traffic from 10.0.1.X to 10.1.0.X through the existing tunnels or are you actually trying to bring up another tunnel through the existing tunnels? The latter would be quite unorthodox.
Look at the diagram in my sig. It sounds like you want Remote Access clients of pfSense A (172.29.6.X) to be able to access LAN assets on pfSense B (172.26.2.X). Is that correct?
-
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.