0

First and foremost I am not a strong networking person but we do not have a network tech here in the office so I got charged with getting this setup and running. Here is the network topology:

Internet --> Cisco Router --> Internal Network (192.168.1.0/24)

On this internal network is a box that is running pfSense and has dual NICs (LAN and WAN) and it's sole purpose in life is to be an OpenVPN box; no other traffic moves through it. Now I have configured the ACL in the Cisco Router properly and am able to connect to the pfSense box with an OpenVPN client without a problem but that is as far as a client gets. The client can not see any of the boxes on the internal network.

Our internal network, as stated, is a 192.168.1.0/24 network and the address pool that I am using for the VPN is 10.10.11.0/24 (although, for some reason, the VPN Server is setting the mask to 255.255.255.252) I setup a 1:1 NAT so that requests from 10.10.11.0/24 go to 192.168.1.0/24 but things still aren't functioning. It seems to me like I need to do additional things to the Cisco to make this work but I am unsure as to what those things are.

Does anyone have any thoughts?

dparsons
  • 187
  • 4
  • 12

4 Answers4

1

OpenVPN does some odd stuff with routing (as compared to other VPN solutions) - the connection the clients get is on a /30 network for each individual client for easier compatability with windows, so thats why youre seeing the 252 netmask. you can change this behavior if all your clients use linux.

does that cisco router know about these routes, and whats the default route for all the boxes on the internal network? i had a similar issue where our core router was getting all the traffic and then dropping it because a) it was non-routable addresses and b) it didnt know what the proper route was.

what i suspect you need to do is create a static route for this whole 10.10.11.0/24 subnet in your cisco router with the gateway as the 192.168.1.X address of the openvpn server.

ensure packet forwarding (ie routing) is enabled in the openvpn box, and you should be good.

TL;DR: Routing requires definition in both directions (either static or dynamic), and it sounds like you need to add a route to your cisco box telling it where to find 10.10.11.0/24

Devnull
  • 951
  • 1
  • 7
  • 23
  • Upon reading your post I added a static route to the Cisco router of 10.10.11.0 255.255.255.0 192.168.1.203 but am still getting time outs when I attempt to ping anything on the 10 network. On the pfSense box I have a 1:1 NAT rule defined for 10.10.11.0/24 to 192.168.1.0/24 but I have no static routes defined. – dparsons Aug 17 '10 at 12:22
  • you probably want to cut out the NAT rule - adding the static routes will make NATting unnecessary. – Devnull Aug 17 '10 at 12:37
  • Hmm. Won't NAT be necessary for accessing computers on the business network? For example, one of the servers that a VPN client will need to access is 192.168.1.200 if there is no NAT, and the client tries to go to this IP it will try and resolve on their local network and not the business network. Right? – dparsons Aug 17 '10 at 13:15
  • thats the point of the routing - youre giving the gateways on each network knowledge of the routes necessary to get from one network to the other. wolfgang (below) is also correct that you need to push the local net routing out to the clients – Devnull Aug 17 '10 at 14:47
0

An explanation on how OpenVPN connections work can be found here. Because of the fact that your OpenVPN server hands out addresses in the 10.10.11.0/24 subnet, and your internal LAN is on 192.168.1.0/24, there is no default routing that will allow connected clients to "see" IP addresses on the other side of the tunnel.

In order for this to work, you need to "push" routes to the client. In your particular case this means your server configuration has to include a statement like this:

push route 192.168.1.0/24

Now, having said this: this will only work if your clients are NOT themselves on the same subnet. If they are on the same subnet, then they will effectively lose that entire subnet, as now (with the new route) all traffic to any addresses in that subnet goes through the tunnel. It is for that reason (and for the fact that most people choose 192.168.1.0/24 as a private LAN) that I personally have stopped using this particular subnet. I would recommend that you consider changing your office LAN to 192.168.x.0/24 where x is any number between 2 and 253.

You should also consider whether you want VPN clients to forward all their traffic for public IP addresses through the VPN or only traffic for the office LAN. Read the OpenVPN documentation for more details on this.

Community
  • 1
wolfgangsz
  • 8,767
  • 3
  • 29
  • 34
  • pushing out the route to the 10 network was exactly the trick I needed to get the clients to talk to the internal network. Thanks! – dparsons Aug 18 '10 at 11:15
0

You probably already have a route to the 192.168.1.0/24 network as the "local network" in the OpenVPN GUI config. You're probably missing a route on the Cisco to point the OpenVPN tunnel network back to the LAN IP on pfSense.

Chris Buechler
  • 2,938
  • 14
  • 18
  • I have 1:1 NAT setup on the tunnel for 10.10.11.0 to 192.168.1.0 and then I added a static route of 10.10.11.0 255.255.255.0 192.168.1.203 to the cisco router and still no dice. – dparsons Aug 17 '10 at 12:17
-1

A more simple setup would be to just enable layer 2 tunneling. No need for further setup, your clients will just appear to be in the same physical network and will get their IP from the DHCP server in the office. You will find it in the open-vpn web-interface: "Configuration -> VPN Mode"

Hope this helps.

Karst Lok
  • 119
  • 3