VPN to LAN but can't access DMZ

drummrman85

So I have a bit of a problem in that I can remotely access my VPN server on the LAN (192.168.x.x) but I can't access the DMZ through the VPN (176.16.x.x). Can't ping it, can't access the webhost that I need to access, etc. My question is more of a conceptual one, but if need be I can post my server/client conf.

Basically is there something I need to do (beyond the default configuration I already have) to allow remote clients to access the DMZ webhost? As I said, I can connect to the OpenVPN server on the LAN, but unlike the local machines, any remote client can't access the DMZ.

This is probably a noob question, but...well...I'm a noob, so...

Oh, all machines are running Ubuntu 14.04.

SomeGuy

Make sure the VPN server itself can reach the DMZ.

Use a network tool that allows you to specify a source IP you have bound to an interface and use that source IP address for connections to a service, then specify the IP Address on your VPN Hub's tunnel interface, when trying to connect to DMZ resources. If that does not work fix it for the host. Maybe routing updates, maybe filter rules; it is your setup and outside the config of OpenVPN

One example of a tool is some copies of "telnet" with some linux distros support a "-b" option to specify a source IP you have bound to an Interface. Example:

telnet -b Tun.Nel.IP.Address IP.ADDRESS.ON.DMZ 80

That might try to connect the whatever IP address would replace IP.ADDRESS.ON.DMZ as an IP address on you DMZ, and a web server. if that is able to connect, and whatever IP address you had on your tunnel interface on your vpn server would replace Tun.Nel.IP.Address , and you can talk to a web server with your tunnel interface as a source IP, you confirm routing and firewall rules permit that connection.

The router(s) between the OpenVPN Server and the VPN need to be able to know how to get replies from the VPN back to the source IP address of the packet that was sent to the DMZ.

Any network filters between the OpenVPN server and the DMZ host need to allow those source, destination and protocols to communicate.

If the above does not work, there is little value in continuing to the rest of the content below. Without confirmation routing from the tunnel network range works round-trip to/from DMZ, and network filters allow for the same round-trip, there is no "magic" in OpenVPN to fix that for you.

Once the above works, then move on to OpenVPN config:

As for openVPN, on questions of routing, review the documentation for server config on '--route' and '--push "route IP.Add.re.ss Sub.net.mas.k" on the server conf, and then review the documentation of use of "ccd" and "--iroute" option of openvpn in the ccd config files per client.

(An actual IP Address would replace the name "IP.Add.re.ss" , and a real subnet mask would replace the name "Sub.net.mas.k")

Once these are working, then restart your openvpn server to load these settings, and restart your client. Verify your client did get the "push"ed routes for the DMZ, and they updates the clients routing table.

Review your OpenVPN server logs with VERB enabled high enough (somewhere between 1 and 4 , inclusively) and look for an indication that on the client connection, the client's CCD file was loaded and used by the server.

If not, do not proceed. Fix that first. no iroute load from ccd for the client, no point in continuing.

Then, from the client try to use the same telnet command you tried before, but drop the request to bind to any specific IP address, so emulating above without binding:

telnet IP.ADDRESS.ON.DMZ 80

If all the parts are working (routing from the vpn server tunnel network range to the DMZ, network filtering to allow the tunnel network to reach the DMZ, client connection triggers ccd conf and iroute, and client gets pushed route) I would expect access to the DMZ through the VPN server to work.

If this works, please confirm it did. If you had to complete extra steps beyond what was included here, please followup with what they were. Other people can benefit from what it took you to make your configuration work.

If details above are not clear, please suggest how to make them more clear and understandable.

drummrman85

Thanks for the reply. I will try these steps (skipping telnet because that already worked for me) and let you know if it works. Might be after the holiday, but we'll see!

drummrman85

[quote="SomeGuy"]Make sure the VPN server itself can reach the DMZ.

One example of a tool is some copies of "telnet" with some linux distros support a "-b" option to specify a source IP you have bound to an Interface. Example:

telnet -b Tun.Nel.IP.Address IP.ADDRESS.ON.DMZ 80

After reading your post more thoroughly, I stand corrected. I had not tried telnet with the -b argument. When I try:

telnet -b 10.8.0.1 176.16.2.102 80

the connection times out.

SomeGuy

drummrman85 wrote
SomeGuy wroteMake sure the VPN server itself can reach the DMZ.

One example of a tool is some copies of "telnet" with some linux distros support a "-b" option to specify a source IP you have bound to an Interface. Example:
telnet -b Tun.Nel.IP.Address IP.ADDRESS.ON.DMZ 80
After reading your post more thoroughly, I stand corrected. I had not tried telnet with the -b argument. When I try:
telnet -b 10.8.0.1 176.16.2.102 80
the connection times out.

So, some considerations:
* the router(s) that are between your OpenVPN server and your DMZ (including hosts) may not know any route on where to send their responses to get to 10.8.0.1
* There may be filters/rules on devices that are denying packets to/from 10.8.0.1 .

Some options:
* You can visit the routers and add support for getting to 10.8.0.1/? network by going through the OpenVPN server.
* You can verify that the network filter rules on hosts between you and the DMZ host(s) allow traffic from 10.8.0.1/?
* You can enable "NAT" on the OpenVPN Linux box, for IP addresses on the tunnel interface to be NAT-ed through your OpenVPN server's LAN connection and interface that is able to communicate to hosts on the DMZ. (With this, hosts on the DMZ would see the source IP of hosts from the tun as being the IP address on the LAN interface, and any network rules in place would rely on that source IP address not the real source behind the NAT.

NAT has risks for abuse, and is probably not the "right" answer if you are going to have many users share the same OpenVPN server.
Routing support for the VPN Tunnel network/subnet is probably more work, but makes diagnosing network issues easier, if many users will be using the OpenVPN server, as the IP addresses you see in the DMZ from the tunnel match specific clients, making audit trails easier to understand.

NAT is often used when it is just one user of the OpenVPN server, or "small" operations.
Real routing without NAT is more often used in medium to large organizations or when multiple users will share the VPN server.
Medium/large orgs may still choose to use NAT, so they can avoid collisions in reserved address space with other uses.

There may be other choices, but those two are pretty common. You could choose one, and implement it.

Item of note: I do not think the telnet test will work to test when binding to an IP address on the tunnel if NAT is used, as iptables/NAT rules tend to rely on packets coming into the interface, and a telnet from the server may not exercise the rules to cause NAT to work. The telnet test will probably work if routing to and from your DMZ supports your tunnel network.

I forgot to mention, you will also need to enable "ip_forward" in linux to make the OpenVPN server act as a router. (See sysctl and /proc/sys/net/ipv4/ip_forward for testing, and then when you want to make any sysctl rule permanent , then check your local "sysctl" config for linux, often found in /etc/*sysctl* as a file or directory or both.)

Also, you may find "mtr --bind tun.nel-ip-address" as a better alternative to "telnet -b ..."

SomeGuy

It looks like some copies of "mtr" use "--address" or "-a" instead of "--bind" and there may be other variations on this, so check the man page of mtr before using this feature.