It is possible.
You would need:
- Ports opened to pass VPN traffic through to the Debian boxes
- IPSEC configuration on each machine
- IPSEC userspace tools installed (ipsec-tools (and a kernel with it supported, so > 2.5.7))
- A guide like http://lartc.org/howto/lartc.ipsec.html
- Lots of fiddling with config files
Then, on your router/default gateway, add static routes for the remote subnets pointing to the Debian boxes.
The configuration isn't that bad, but if you've never dealt with IPSEC VPNs before it may be a confusing mess (but then, it is Linux, so everything is ;) )
On the last (and only) server I got it working on, there were six files involved, which I include below, in a censored fashion. Where I've put local_ip was the ip address of the local server, and where I've put remote_ip was the ip address of the remote server, and this config was for secure communication between two machines on the same network, so the config isn't going to be right for you with NAT and multiple machines involved.
You will need to mirror the config on either side (so, swapping the local_ip and remote_ip bits on one server), and also find where you need to put public IPs to get it working over the internet.
Anyway, if you want to get it working, be prepared to spend some hours faffing with it, because it might well take that. VPNs are not really click and drag, unless you buy expensive firewall kit.
/etc/sysconfig/network-scripts/ifcfg-ipsec0
DST=remote_ip
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
/etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK="passphrase"
/etc/racoon/psk
remote_ip passphrase
/etc/racoon/racoon.conf
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk";
path certificate "/etc/racoon/certs";
# log debug2;
listen
{
isakmp local_ip;
}
include "/etc/racoon/remote_ip.conf";
/etc/racoon/setkey.conf
#!/sbin/setkey -f
flush;
spdflush;
#Add the policy
#This policy applies to inbound traffic from remote
spdadd remote_ip/32 local_ip/32 any -P in ipsec esp/transport//require;
spdadd remote_ip/32 local_ip/32 any -P in ipsec ah/transport//require;
#This policy applies to outbound traffic to remote
spdadd local_ip/32 remote_ip/32 any -P out ipsec esp/transport//require;
spdadd local_ip/32 remote_ip/32 any -P out ipsec ah/transport//require;
/etc/racoon/remote_ip.conf
remote remote_ip
{
exchange_mode main;
my_identifier address local_ip;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
lifetime time 8 hours;
}
}
sainfo address local_ip any address remote_ip any
{
authentication_algorithm hmac_sha1;
encryption_algorithm 3des;
compression_algorithm deflate;
}
sainfo address remote_ip any address local_ip any
{
authentication_algorithm hmac_sha1;
encryption_algorithm 3des;
compression_algorithm deflate;
}
This is kind of an old post, but it still comes up in search results, so I'm going to add to it.
First: having two DHCP servers in a subnet is not going to cause problems no matter what, that's a very misleading statement. What will cause issues is two DHCP servers which are offering the same pool of addresses. You can have two servers offering different ranges of IP addresses (like 192.168.1.1-100 on one and .101-200 on a second) within the same subnet without causing any issues at all. In fact, if you want to have redundant DHCP in your network, this is a recommended/best practice way to do it.
Second, here's some instructions from Microsoft which may get someone a little closer if they happen to have a similar issue:
http://technet.microsoft.com/en-us/library/ee405264(v=ws.10).aspx
Best Answer
DHCP is based on using layer 2 broadcasts to allow clients to locate DHCP servers. A bridge would forward these layer 2 broadcasts between the networks. Plugging the switches from each respective network into the other would accomplish this. An Ethernet switch is, in effect, nothing more than a multi-port bridge. This isn't what you want to do.
Since you want to keep the DHCP configuration intact you're looking for a router to connect the two networks. A router doesn't forward layer 2 broadcasts between the networks it's attached to (in any sane default configuration). Adding a router, however will require you to make modifications to your existing routers' routing tables.
Your current edge router in "network 2", if it had a second Ethernet interface, would do just fine. You'd just give that port a "network 1" IP address and attach it to the "network 1" switch. Then you'd add a static route on the Linux router / DHCP server in "network 1" specifying that the "network 2" subnet is accessible via the "network 1" IP address that your assigned to the "network 2" edge router's Ethernet interface that you attached to "network 1".
If your edge router in "network 2" doesn't have an extra Ethernet port your could add another Ethernet port to the Linux router / DHCP server to accomplish the same thing.
Finally, you could also get a freestanding router to connect the two networks together. A lot of consumer grade routers expect that you're going to want to to Network Address Translation (NAT) and, as you say in your question, you're not going to want yet another DHCP server (which many consumer-grade routers have enabled out-of-the-box). In the case of using a freestanding router (which will have two physical interfaces connected to the two separate networks, each with IP addresses assigned in the respective networks to which it is attached) you'll need to add a static route on both networks' edge routers back to this freestanding router.
We don't do product recommendations here, but there are a number of small, inexpensive routers that could do what you're looking for if your existing gear can't handle it.
Edit:
If you have no access to router in "network 2" then you're going to have to get more creative.
If you could just add a second NIC to the Linux machine, and give that NIC a "network 2" IP address you could have clients in "network 2" access the Linux machine via that IP and you'd be done.
If you can't add a second NIC to the Linux machine then you could add a freestanding router device with both "network 1" and "network 2" IP addresses. You'd need to use NAT in order to avoid having to change routing tables in "network 2". A consumer grade router meant for home Internet access would probably do.
Connect the "LAN" port to the "network 1" network and give it a static IP address in the "network 1" subnet.
Disable any DHCP server on the router.
Connect the router's "Internet" port to the "network 2" network and give it a static IP address in the "network 2" subnet.
Add a static route on the Linux machine for the "network 2" subnet accessible via the "network 1" IP address you assigned to the router. (This allows the Linux machine to respond back to hosts in the "network 2" subnet.)
Configure "port forwarding" or "DMZ host" functionality on the router to forward either individual ports, or all traffic, from the "Internet" port to the Linux machine. (This allows "network 2" computers to access the Linux machine via a "network 2" IP address, preventing the need for any routing table modification on the "network 2" edge router.)
From "network 2" computers, access the Linux machine via the "network 2" IP address you assigned to the router. The router's NAT / port-forwarding (or DMZ host) functionality will forward the traffic to the Linux machine.
(I feel a little dirty giving you this answer... >smile< It's a bit of a hack, but it will work.)