Need config and architecture help please

tombodet

I really could use a little help. While I can follow guides and have a simple grasp of what's going on, I need a little hand holding.

We have a development network we are currently using openvpn on an old clark connect instance and I'm trying to update things.

I've got a Cent 6 VM built off of most of the NSA guidelines and am now configuring openvpn.

My core question is what config do I really want?

The current one has a single interface that forwards traffic back out with the client IP. As in:

INTERNET
     |
FIREWALL  -  DMZ
     |         |
   LAN      PROXY
     |         |
OPENVPN  <----

So the proxy forwards VPN traffic to the server. LAN is on 192.168.10.0 the VPN clients are 192.168.50.0. When the traffic comes out of the VPN box, the IP is of the client, not the server.

What I'm looking to do is:

INTERNET
     |
FIREWALL  -  DMZ
     |         |
   LAN     OPENVPN

The part I'm not sure about is how to connect VPN to the LAN. Do I put a second interface on the VPN box connected to the LAN or do I use a similar concept as I have now where the traffic of the clients coming out of the VPN is different and I route it through the firewall from the DMZ to LAN?

Right now what I have working is with the new layout with a single interface but traffic coming out is still from the server's IP, not the client so the firewall is blocking it.

Sever config (minus key locations and such)

local 192.168.90.9
port 1194
proto udp
dev tun
server 192.168.50.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.10.6"
push "route 192.168.10.0 255.255.255.0"
#client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
status openvpn-status.log
log-append  /var/log/openvpn.log
verb 6
mute 10
script-security 3
auth-user-pass-verify /etc/openvpn/auth/openvpn-super.pl via-env
client-connect /etc/openvpn/auth/openvpn-super.pl
auth-nocache
cipher AES-256-CBC
auth SHA512
opt-verify

I've set /proc/sys/net/ipv4/ip_forward to 1 and with an iptables rule forwarding tun0 to eth0 I get traffic trying to hit a test server for an ssh session but again the traffic to the firewall looks like the VPN server, not the client itself.

 iptables -I FORWARD -i eth0 -o tun0 -j ACCEPT
 iptables -I FORWARD -i tun0 -o eth0 -j ACCEPT

I realize this is a 2 part question but I'm stuck and am not sure what is the best way to proceed. I don't really care which is easier, I want the better solution. Do I stick with what I've got above and we figure out my forwarding problem or do we add a new interface and then fix forwarding and/or switch to bridged mode?

One thing that is nice about having the client IPs coming out of the server is if I can create a custom connection script to set specific IPs and to push routes to say the management network and then allow only those IPs through at the firewall.

Thanks for your time.

tombodet

Anyone?

What I've come to realize I want is no NAT on the clients, just treat them like another network segment.

So take traffic coming in on tun0 and forward it to eth0 without NAT.

My iptables rule above is the only thing that has gotten me anything traffic passing but again, it comes out NAT'ed. A tcpdump on tun0 shows it comes in as the client IP but when the firewall see's it, it's got the VPN server's IP.

With the current VPN setup, if I ping something that traverses the firewall, it has the client IP. However my server configs are similar, there's nothing in the FORWARD chain and nothing odd in the local routes. Only the ipv4 forwarding is set to 1. I cannot find how we got it to work that way unless something fundamentally changed in networking since Cent 4.

I'm just looking for the proper solution and a hint as to where I'm missing the obvious.

dropje

Altough I can see you made an effort in explaining your goal it's not quite clear to me.
What I've understood so far is that your VPN server is currently located in your LAN and you want to move it to your DMZ?

You're stating that traffic hitting a test box has a source address of your VPN server and is therefor being dropped by your firewall? Are you masquerading or SNAT-ing? Post the output of your NAT table:

iptables -t nat -L -n

If you're indeed trying to put your VPN server in your DMZ that shouldn't be a problem. There are 2 things to consider in a setup like that:
- Hosts in your LAN should know how to reach the client (either by a static route on that host or on your default gateway)
- If you're going to connect to hosts in your DMZ and use a static route for your VPN network on the default gateway you might run into the problem of "out of state packets"

Client sends request to host in DMZ with address: 192.168.50.20 ->192.168.99.120 (host in DMZ)
Host in DMZ doesn't know how to reach client so sends packets to its gateway
Gateway did not see initial client request and will mark the packet as out of state (drops it)

tombodet

THANK YOU THANK YOU

I use a script do to my iptables changes so when I need something new I just mod it then re-run it. At the top is an iptables -F.

However I was not aware that -L didn't show you everything so when I ran what you asked I got a boatload of MASQUERADE entries on POSTROUTING.

iptables -t nat -F

Now it does exactly what I wanted, no NAT for client traffic.

I've been going nuts all week on this.

So as the follow up question to this, is there any 'right' way to do a VPN setup? Meaning, you're going to poke a hole in your firewall somewhere to let clients in and the server is the weak point. So no matter where you put it or what you do, if the server is compromised, that's it. Other than "that's how I do it" is there any advantage to putting the server in the DMZ like I have now or on the LAN with a proxy like the one I'm replacing?

dropje

The advantage of putting the VPN server in a DMZ could be that *if* it's compromised the attacker is still stuck in the DMZ. The disadvantage is that you have to control what kind of traffic you want to pass to your LAN.
If it's just a website it's not a problem, but i'd imagine you would want to be able to have full access.

The way we do it is allow all traffic from VPN clients to our LAN but limit access on the host itself using a learn-address script. This way we can specify which client (based on common_name) has access to what host.
If your user base is small and static you could also take a look at ccd for this (assign static address and use iptables to limit access)..

If you're just running OpenVPN as a service and use tls-auth the chances of it being exploited are low. Furthermore make sure you lock it down further by allowing (for example) just SSH from your LAN, no root logins, and only pubkeyauthentication. Disallow access to any other service using iptables.

If you are paranoid about security you could take a look at for example chroot and or OpenVZ linux container.