IPCop and VMWare

I have the following virtual domain set up; IPCop 1.4.15 and 4 Windows 2003 servers, 1 with Exchange 2003, installed in VMWare Server. The “Extra Interfaces” add-on is installed in IPCop allowing the use of a Gray interface that has more flexibility than the IPCop Blue interface. SNAT is also installed in IPCop.

The purpose of this setup is for a Disaster Recovery study. All of the hosting site servers and computers would be behind the remote site firewall with specific rules allowing only access to VPN, webmail and web site in the VMware instance. The clients on LAN2 would have access to the virtual domain as any normal domain with user and group rights, group policy, domain resources, etc...

As shown in this diagram ( dlr.gcfa.googlepages.com/ipcopdiagram.jpg ), everything except Client1 is running within a Virtual Server, for now, on a Vista machine. Red interface (external IP) connected to one of the Vista NICs, Client1 connected directly with a crossover cable to the other NIC and set up with a static IP for now.

Red: eth1 – yyy.yyy.yyy.210 – SN 255.255.255.0
- DNS1 zzz.zzz.zzz.37 – DNS1 zzz.zzz.zzz.144 – GW yyy.yyy.yyy.1
- Bridged with LAN1
Green: eth0 – IP 10.165.21.2/25 – SN 255.255.255.128
- Server1: IP 10.165.21.6 – SN 255.255.255.128 – GW 10.165.21.2
IP 10.165.21.12 – SN 255.255.255.128 – GW 10.165.21.2
- Server2: IP 10.165.21.7 – SN 255.255.255.128 – GW 10.165.21.2
Orange: eth2 – IP 10.165.20.2/24 – SN 255.255.255.0
- Server3: IP 10.165.20.6 – SN 255.255.255.0 – GW 10.165.20.2
- Server4: IP 10.165.20.3 – SN 255.255.255.0 – GW 10.165.20.2
Gray: eth3 – IP10.165.21.129/25 – SN 255.255.255.128
- Bridged with LAN2
- Allow access to IPCop DNS
- Allow access to Red HTTP
- Allow access to Red DNS
- Allow access to Red TCP, UDP and ICMP
- Client1: IP 10.165.21.141 (st) – SN 255.255.255.128 – GW 10.165.21.129

Server1 on Green
- can ping eth2 – server3 – server4 – eth3
- cannot ping anything else on Gray
- resolves nslookup query through server1 and can surf the net

Server3 on Orange
- can ping eth0 – server1 – server2 – eth3
- cannot ping anything else on Gray or anything on the outside
- can resolve nslookup query through server3 and can surf the net

Client1 on Gray:
- can ping eth0 – server1 – server2 – eth2
- can ping Server1 by its NetBIOS name
- can map and access shares on Server1
- cannot ping anything on the outside
- resolves nslookup query through server1 and cannot surf the net
- cannot join the virtual domain
- cannot receive DHCP info from Server1

SNAT is installed on IPCop and configured for VPN, WEB and WEBMAIL access. Access to Webmail, the VPN connection and surfing on the website work just fine from an outside computer.

The implemented port forwarding rules are:
1,0,gre,GRE,10.165.21.12,GRE,on,0.0.0.0,0.0.0.0/0,
2,0,udp,500,10.165.21.12,500,on,0.0.0.0,0.0.0.0/0,
3,0,tcp,80,10.165.20.3,80,on,0.0.0.0,0.0.0.0/0,
4,0,tcp,25,10.165.20.6,25,on,0.0.0.0,0.0.0.0/0,
6,0,tcp,1723,10.165.21.12,1723,on,yyy.yyy.yyy.212, 0.0.0.0/0,
7,0,tcp,80,10.165.20.3,80,on,yyy.yyy.yyy.203,0.0.0 .0/0,
8,0,tcp,25,10.165.20.6,25,on,yyy.yyy.yyy.206,0.0.0 .0/0,
9,0,tcp,80,10.165.20.6,80,on,yyy.yyy.yyy.206,0.0.0 .0/0,
10,0,tcp,1:65535,10.165.21.6,1:65535,on,10.165.21. 129,0.0.0.0/0,
11,0,udp,1:65535,10.165.21.6,1:65535,on,10.165.21. 129,0.0.0.0/0,
12,0,tcp,1:65535,10.165.21.129,1:65535,on,10.165.2 1.6,0.0.0.0/0,
13,0,udp,1:65535,10.165.21.129,1:65535,on,10.165.2 1.6,0.0.0.0/0,

Gray will need to:
- Join the virtual domain
- Use DHCP on Server1
- Surf the net

Any ideas are welcome! Thanks

wow

Here's a simplified diagram pertaining to my problem ( dlr.gcfa.googlepages.com/dhcp.jpg )...

So my problem boils down to:
- What needs to be done for Client1 to be able to join the virtual domain?
- Once on the virtual domain, can Client1 get DHCP settings?
- Why can't Client1 surf the net?

I've messed around with lots of stuff, but no go... I'm not a routing guru!

If needed, Gray clients could get an IP from the IPCop DHCP server. Could
that IP then be NATed to the Green subnet, thus allowing the client to join
the domain and get a DHCP address? Would Iptable entries be the way to go?

A revised network diagram can be found here ( dlr.gcfa.googlepages.com/ipcopdiagram2.jpg ). Everything works great EXCEPT the shared folder mapping from a remote VPN client.

The VPN client uses MS VPN to connect to Routing and Remote access that is running on Server4 in the DMZ. The web server has 2 network cards:
- DMZ: IP 10.168.20.3 & 10.168.20.12 – SN 255.255.255.0 – GW 10.168.20.2
- LAN: IP 10.165.21.12 – SN 255.255.255.0 – No GW

RRAS has a pool of DHCP addresses: 10.165.21.200 – 10.165.21.229. RADIUS authentication is set up with Server1.

Server4 can ping Server1 through the LAN interface. Server1 can access the net through the DMZ interface.

The client connects and authenticates without a problem. It can surf the net and do everything it needs to BUT it cannot ping Server1 or access any shares on that server.

I have the same sort of setup on our production network (minus the VMware server and VPN server on its own box in the DMZ). When connecting by VPN, I can access the equivalent of Server1. The above configuration replicates the production environment.

Any help would be appreciated!
Thanks

Ok, got it working now... Whew!! Latest network diagram is here ( dlr.gcfa.googlepages.com/ipcopdiagram3.jpg ).
What I've done:

- Installed RRAS on Server4 with 1 NIC configured with 2 IPs : 10.165.20.3/255.255.255.0 and 10.165.20.12/255.0.0.0
- Configured RRAS with DHCP scope 10.165.20.200 - 10.165.20.229 and static route dst 10.165.21.0/255.255.255.0 10.165.20.2 NIC
- RRAS configured for client Windows Authentication. Server3 holds the user accounts.
- Added all RRAS DHCP IPs to the IPCop DMZ pinholes rules: TCP src 10.165.20.2xx dst 10.165.21.0/24 port 445

The LAN servers on Green could no longer surf the net if there wasn't a Green to Red 1:1 natting using SNATGUI. I had read in one of the IPCop forums that that was an issue. I uninstalled SNATGUI and added the entries manually in rc.firewall.local.

VPN client authenticates and connects fine. It cannot ping 10.165.21.6 and tracert 10.165.21.6 does 2 hops: 10.165.20.200 and 10.165.20.2 then times out. Typical IPCop behavior blocking ICMP from Orange to Green.

Mapping \\10.165.21.6\c$ or any other shared folder finally works. VPN clients can now access all LAN (Green) shared folders on the 10.165.21.0/24 range. If needed, any LAN or DMZ servers can map \\10.165.21.2xx\c$ or any other shared folder on the VPN clients.

Using RADIUS authentication with Server1 will not allow folders on Server1 to be mapped.

Connecting from the Blue interface works too, wired or wireless. IPCop is configured to hand out IPs on the Blue interface. That IP range is also added to the IPCop DMZ pinholes rules: TCP src 10.165.22.xx dst 10.165.21.0/24 port 445. Blue clients can map anything on the 10.165.21.0/24 network. Blue clients can also connect to the VPN server, if needed (but I don't see why they would).

So, now everything on the virtual domain works correctly, just like a real domain...